資料保護：KMS、ACM、Secrets Manager 與安全發現

AWS data protection is the umbrella that covers every operational task a SysOps engineer performs to keep data confidential, intact, and available — managing KMS keys, renewing TLS certificates through ACM, rotating secrets in Secrets Manager, and triaging security findings from GuardDuty, Security Hub, and Inspector. SOA-C02 Task Statement 4.2, "Implement data and infrastructure protection strategies", is the home of this topic, and the exam framing is decidedly operational: not which encryption strategy to design, but how to operate the keys, certificates, secrets, and findings pipeline that already exists. SAA-C03 asks "should we use SSE-S3 or SSE-KMS?"; SOA-C02 asks "the ACM certificate failed to auto-renew last night, what do you check first?" — and the answer touches DNS validation records, alternate names, the renewal window, and CloudWatch Events.

This guide walks through data protection on AWS from the SysOps angle. You will see how KMS customer managed keys are created, how automatic rotation works (and what it does not do), why grants exist alongside key policies, how envelope encryption keeps the per-object data key cheap, how to enable encryption at rest on S3, EBS, RDS, and EFS without rebuilding infrastructure, how ACM certificates auto-renew 60 days before expiry and the troubleshooting steps when renewal fails, the differences between Secrets Manager and Parameter Store SecureString, the rotation Lambda mechanics for RDS credentials, and the canonical remediation playbooks for GuardDuty and Inspector findings aggregated through Security Hub. Every section ends with the recurring SOA-C02 scenario shapes that turn a long study list into a small set of repeating patterns.

Why Data Protection Sits at the Heart of SOA-C02 Domain 4.2

The official SOA-C02 Exam Guide v2.3 lists six skills under Task Statement 4.2: enforce a data classification scheme, create and protect encryption keys, implement encryption at rest with KMS, implement encryption in transit with ACM and VPN, securely store secrets with Secrets Manager and Parameter Store, and review reports or findings from Security Hub, GuardDuty, Config, and Inspector. Every skill in that list is operational — create, implement, securely store, review — so every data protection question has a "what button do you push, what command do you run, what setting do you flip" answer.

At the SysOps tier the data protection lens is hands-on. A SysOps engineer is the person rotating the KMS key alias when a customer triggers re-key, the person attaching a new ACM certificate to the ALB after the auto-renewal failure was caught, the person flipping a Secrets Manager secret from manual to automatic rotation, and the person on the receiving end of a GuardDuty UnauthorizedAccess:EC2/MaliciousIPCaller.Custom finding at 3am. Because data protection threads through every domain — VPC encryption in transit (Domain 5), Backup encryption keys (Domain 2), CloudTrail trail encryption (Domain 1), Config Rule remediation for unencrypted resources (Domain 1) — the data protection topic is the connective tissue that makes the rest of SOA-C02 cohere.

白話文解釋 Data Protection on AWS

Data protection jargon stacks fast — keys, grants, envelope encryption, validation records, rotation Lambdas. Three analogies make the constructs stick.

Analogy 1: The Office Locker Hierarchy

KMS is an office locker hierarchy. The AWS-owned key is the landlord's master key — you never see it, AWS uses it to encrypt the building's invisible plumbing, and you cannot interact with it. The AWS-managed key is the floor manager's key — AWS created it and gave it your account's name (aws/s3), it lives in your floor's key cabinet, and the floor manager (the AWS service) automatically rotates it every year. The customer-managed key (CMK) is the key you cut yourself at the locksmith — you choose who is on the access list (the key policy), you decide whether to enable annual auto-rotation, and you pay one dollar a month for the privilege of holding it. Grants are temporary visitor passes the front desk hands out on your behalf — limited scope, expire automatically, easier to revoke than rewriting the key policy. Envelope encryption is the two-key safe in your locker: the safe inside (the data key) is fast and unlocks the documents, but the safe itself is locked by the master CMK so a thief who steals the inner safe still cannot open it without the master.

Analogy 2: The Postal Certified Envelope

ACM and TLS in transit are the postal certified envelope system. A public ACM certificate is the post office stamp that proves the sender is who they claim — anyone can verify it because the post office (a public certificate authority) signed it. DNS validation is the act of publishing your address on the public registry so the post office can confirm you actually live there before issuing the stamp. The private CA (ACM Private CA) is your company's internal mail room — it issues stamps that only your buildings recognize, perfect for internal services that should never be reachable from the public internet. Auto-renewal at 60 days before expiry is the post office's standing reminder to renew your stamp early, but the reminder only works if your address is still on the public registry — if you removed the DNS validation record after the first issuance, auto-renewal fails silently and the certificate expires.

Analogy 3: The Hospital Wristband and Patient Chart

Security Hub, GuardDuty, and Inspector are the hospital intake and triage system. GuardDuty is the vital-signs monitor that watches each patient (account) continuously and beeps when something looks abnormal — irregular heart rhythm (network anomaly), fever spike (suspicious DNS query), unusual visitor list (unauthorized access). Amazon Inspector is the scheduled health screening that runs through every existing patient and flags pre-existing conditions — software vulnerabilities, exposed network paths, container image CVEs — even when the patient is currently asymptomatic. Security Hub is the central nurse station that collects every alert from every monitor and every screening across every patient, normalizes them onto one chart format (ASFF), and ranks them by severity so the on-call doctor can triage in priority order. Findings workflow status (NEW → NOTIFIED → SUPPRESSED → RESOLVED) is the wristband color the staff updates as the case moves through assessment.

Data Classification: The Operational Reminder

Before keys and certificates make sense, a SysOps engineer needs to know which data is being protected. AWS does not impose a classification scheme — your organization does — but the SOA-C02 Exam Guide explicitly lists "Enforce a data classification scheme" as a skill, so the operational tasks must be visible.

Classification tiers in practice

Most organizations use three to four data protection tiers:

• Public — marketing pages, public documentation, open data sets. No encryption requirement, but TLS in transit is still standard hygiene.
• Internal — operational logs, internal dashboards, non-sensitive metrics. Encryption at rest with AWS-managed keys; TLS in transit with ACM public certificates.
• Confidential — customer PII, employee records, vendor contracts. Encryption at rest with customer-managed KMS keys; TLS in transit; Secrets Manager for credentials.
• Restricted — payment card data, health records, authentication secrets. Customer-managed KMS keys with strict key policies, automatic rotation, CloudTrail logging of every key use, and dedicated grants per workload.

Operational tagging

Tag every resource with a DataClassification tag (Public, Internal, Confidential, Restricted). AWS Config rules then enforce that:

• Confidential and Restricted resources have encryption at rest enabled.
• Restricted resources use customer-managed KMS keys (not AWS-managed).
• Restricted resources are not in publicly accessible subnets.

This is the operational backbone of data protection on AWS — classification drives encryption choice, encryption choice drives key management work, and key management work is what SOA-C02 actually tests.

KMS Customer Managed Keys: Types, Creation, and Operational Tasks

The KMS data protection model rests on three key types and a careful separation of who owns what.

KMS key type matrix

Creating a customer-managed key

A customer-managed key is created via console, CLI, or CloudFormation. Operational checkpoints:

• Key spec: symmetric (AES-256) is the default and covers 95 percent of data protection needs. Asymmetric KMS keys (RSA, ECC) are for digital signing and asymmetric encryption use cases — rarely tested operationally on SOA-C02.
• Key usage: ENCRYPT_DECRYPT for data encryption, SIGN_VERIFY for asymmetric signing, GENERATE_VERIFY_MAC for HMAC.
• Key policy: the resource policy attached to the key. Must include the account root principal at minimum, plus specific principals authorized to administer or use the key.
• Alias: a friendly name like alias/prod-rds-data-protection that abstracts the underlying key ID. Aliases can be retargeted to a new key without changing application code — the operational lever for re-keying.
• Tags: at least DataClassification, Environment, Owner for cost allocation and auditing.

Key policies vs IAM policies

KMS uses both. The key policy is the resource policy on the KMS key; the IAM policy is the identity policy on the user or role. For a principal to use a KMS key:

• The key policy must allow access (or delegate to IAM via the standard "Enable IAM User Permissions" statement).
• AND the IAM policy must allow the action (if the key policy delegates).

This is more restrictive than other AWS services. A bare IAM policy alone is not sufficient unless the key policy explicitly delegates to IAM. SOA-C02 routinely tests this trap: an admin with kms:* IAM permission still cannot use the key if the key policy does not delegate to IAM.

Grants: the flexible alternative

A grant is a programmatic permission attached to a KMS key for a specific principal and a specific set of operations, without modifying the key policy. Grants:

• Are created via CreateGrant API and identified by a grant ID and grant token.
• Specify a grantee principal, allowed operations (Encrypt, Decrypt, GenerateDataKey, etc.), and optional constraints (encryption context).
• Are eventually consistent — the grant token returned at creation time is usable immediately even before the grant is fully propagated.
• Can be retired (by the grantee or grantor) or revoked (by the grantor only).
• Are the AWS-recommended pattern for short-lived, programmatic access — for example, an EBS volume creation that needs temporary access to the CMK to encrypt the volume.

KMS Key Rotation: Automatic, Manual, and What It Does NOT Do

Key rotation is the single most-tested KMS operational topic on SOA-C02 and the one most often misunderstood.

Automatic rotation for customer-managed keys

When you enable automatic rotation on a customer-managed symmetric key, KMS rotates the backing key material every 365 days. After rotation:

• The key ID stays the same.
• The alias stays the same.
• The old backing key material is retained so existing ciphertexts remain decryptable.
• New encryption operations use the new backing material; new ciphertexts carry an internal key version identifier.
• KMS handles the version selection during decryption transparently — applications never see the rotation.

What automatic rotation does NOT do:

• It does not re-encrypt existing data. The old ciphertext stays as it is, decryptable with the retained old material.
• It does not rotate the key ID, ARN, or alias.
• It is not available for asymmetric keys or imported key material — those must be rotated manually.

Manual rotation via aliases

For asymmetric keys, imported key material, or organizational policy that requires fresh ARNs, the manual rotation pattern is:

1. Create a new KMS key with the same key spec.
2. Update the alias (alias/prod-rds-data-protection) to point at the new key.
3. New encryptions use the new key; existing ciphertexts continue to decrypt against the old key (still active, just no longer aliased).
4. Optionally re-encrypt existing data by reading and writing through the alias (now pointing at the new key) — this is the only way to actually retire the old key material.
5. After re-encryption is verified complete, schedule the old key for deletion.

Key rotation in AWS-managed keys

AWS-managed keys (aws/s3, aws/ebs, aws/rds) rotate automatically every year, controlled by AWS, not by you. You cannot disable this. Rotation timing on AWS-managed keys is not exam-tested in detail; only that it happens automatically.

KMS key deletion: the 7–30-day waiting period

When you schedule a customer-managed key for deletion, KMS enforces a mandatory waiting period between 7 and 30 days (default 30). During the waiting period:

• The key is in PendingDeletion state.
• All encryption and decryption operations on the key fail — applications cannot use it.
• You can cancel deletion at any time during the window and restore the key.
• After the waiting period ends, the key is irreversibly deleted along with all its key material; data encrypted with it becomes unrecoverable.

The waiting period exists precisely because a deleted KMS key permanently destroys access to all data encrypted with it. This is the most consequential single operation in AWS data protection, and SOA-C02 expects you to know the 7-to-30-day window.

Envelope Encryption: How AWS Services Use KMS Without Slowing Down

Calling KMS for every byte of data would be impossibly slow and expensive. AWS solves this with envelope encryption: the data itself is encrypted with a per-object data key (fast symmetric encryption), and the data key itself is encrypted with the KMS customer master key (a single small KMS API call).

How envelope encryption works step by step

The flow when S3 (or EBS, RDS, EFS) encrypts an object with SSE-KMS:

1. The service calls kms:GenerateDataKey once per object (or per chunk).
2. KMS returns two pieces: a plaintext data key (256-bit AES key) and an encrypted data key (the same key encrypted under your CMK).
3. The service uses the plaintext data key to encrypt the object locally with AES-256.
4. The service stores the encrypted data key alongside the object (in the S3 object metadata, the EBS volume metadata, etc.).
5. The service immediately discards the plaintext data key from memory.

To decrypt:

1. The service reads the encrypted data key from the object's metadata.
2. The service calls kms:Decrypt on the encrypted data key, which returns the plaintext data key.
3. The service uses the plaintext data key to decrypt the object.

This means one KMS API call per object (not per byte). For S3 buckets with high request rates, the bucket can use S3 Bucket Keys to amortize KMS calls across many objects — one data key for an entire bucket-key time slice instead of one per object. This dramatically reduces KMS API costs.

Encryption context

Every KMS encryption call can include an encryption context — a key/value map that is logged in CloudTrail and required at decryption time. The context is not encrypted; it is bound to the ciphertext as additional authenticated data. Common SOA-C02 use:

• AWS services automatically attach context like aws:s3:arn for S3 objects or aws:ebs:id for EBS volumes.
• Custom applications can require their own context (tenant_id, purpose) so a leaked ciphertext from one tenant cannot be decrypted in the context of another.

Encryption at Rest: Enabling Per AWS Service

Encryption at rest is the data protection foundation for stored data. SOA-C02 tests how to enable, verify, and troubleshoot encryption per service.

S3 — three encryption modes

• SSE-S3 — S3-managed keys, AES-256, free. Default for new buckets since 2023.
• SSE-KMS — KMS-managed keys (AWS-managed aws/s3 or your CMK). Adds CloudTrail log entries for every object access. Costs per KMS API call (use Bucket Keys to amortize).
• SSE-C — customer-provided keys passed in each request. AWS does not store the key. Rare on SOA-C02 because key management is outside AWS.

Enable bucket-level default encryption so every PUT inherits the chosen mode without per-request headers. Verify with aws s3api get-bucket-encryption. Use the AWS Config managed rule s3-bucket-server-side-encryption-enabled for continuous compliance.

EBS — encryption is per-volume, set at creation

EBS volumes are encrypted at creation time using either the AWS-managed aws/ebs key or a customer-managed key. Once created, an unencrypted volume cannot be encrypted in place — you must snapshot, copy the snapshot with encryption enabled, and create a new volume from the encrypted snapshot. Operational levers:

• Account-level default encryption: EnableEbsEncryptionByDefault so every new volume is encrypted automatically.
• Cross-account snapshot sharing of an encrypted snapshot requires the destination account to have kms:Decrypt permission via a key policy or grant on your CMK.
• AMI sharing of an encrypted AMI follows the same KMS permission model.

RDS — transparent encryption, set at instance creation

RDS encryption is configured at DB instance creation. Once the instance is created without encryption you cannot enable it in place — the operational migration is: take a snapshot, copy the snapshot with encryption enabled, restore the snapshot to a new encrypted instance. This is a SOA-C02 favorite scenario because the migration involves a brief outage and CNAME flip.

EFS — encryption at rest and in transit

EFS encrypts at rest using KMS (always) and supports encryption in transit using TLS via the EFS mount helper. Both must be enabled at file system creation. Encryption in transit on EFS requires the efs-utils mount helper, not the standard NFS client.

Encryption in Transit: ACM Certificate Provisioning and Renewal

ACM is the AWS service that issues, deploys, and renews TLS/SSL certificates for ALB, NLB, CloudFront, API Gateway, AppSync, and integrated services. The data protection use case is HTTPS termination — ensuring data in transit is encrypted between the client and AWS edge.

Public certificate provisioning

A public ACM certificate is requested by:

1. Submitting domain names (one or more, including wildcards like *.example.com).
2. Choosing a validation method — DNS validation (recommended) or email validation (legacy).
3. For DNS validation, ACM gives you a CNAME record per domain to publish in the authoritative DNS. Once ACM detects the CNAME, it issues the certificate (typically within minutes).
4. Attaching the certificate to ALB, NLB, CloudFront, or API Gateway.

Public ACM certificates are free and AWS handles issuance, deployment, and automatic renewal.

ACM auto-renewal: the 60-day window

ACM begins auto-renewal 60 days before the certificate's expiration. The auto-renewal process:

1. ACM checks that the validation method is still valid — for DNS validation, the CNAME record must still be present in the authoritative DNS.
2. If valid, ACM issues a new certificate and quietly replaces the old one on attached resources (ALB, CloudFront, etc.) without disruption.
3. CloudWatch Events / EventBridge emits an event for the renewal — successful or failed.

Common reasons auto-renewal fails:

• The DNS validation CNAME was removed after the initial issuance (the most common cause).
• The certificate has alternate names whose CNAME records were never added.
• The certificate is not attached to any AWS service for a long period — ACM eventually stops renewing certs that are not in use.
• For email validation, the domain WHOIS contact is stale or unreachable.

The fix for renewal failure is almost always to restore the missing DNS validation record and trigger reissuance. SOA-C02 expects you to know the 60-day renewal window and the role of the DNS CNAME record.

Private CA certificates

For internal services that should not be reachable from the public internet, AWS Private Certificate Authority (Private CA) issues certificates from a CA you operate inside AWS. Private CA certificates are not free (the CA itself has a monthly cost and per-certificate cost). They are appropriate when:

• Services are internal-only and must trust a corporate CA.
• Compliance requires certificates from a controlled CA chain.
• Mutual TLS (mTLS) authentication uses client certificates issued from your CA.

Private CA certificates also auto-renew if managed by ACM Private CA integration, but the operational model differs slightly — the CA itself must be active and the renewal permission policy must be in place.

Monitoring certificate expiry

Even with auto-renewal, you should alarm on impending expiry as a defense in depth:

• ACM emits a CloudWatch metric DaysToExpiry per certificate.
• Build a CloudWatch alarm at 45 days and 30 days remaining — if you see those firing, auto-renewal is failing and you have a bug.
• Wire the alarm to SNS for the SysOps on-call.

A SysOps team requests an ACM certificate with DNS validation, ACM issues it, the team attaches the cert to an ALB, then someone "cleans up" the validation CNAME records during a Route 53 housekeeping pass because the certificate is already issued. Sixty days before expiration, ACM tries to revalidate via the same CNAME, finds it gone, and silently fails to renew. The certificate expires, the ALB serves an expired cert, and customers see browser warnings. The fix is to never remove the DNS validation CNAMEs and to alarm on the DaysToExpiry CloudWatch metric. Reference: https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html ::

Secrets Manager: Storing Credentials with Automatic Rotation

Secrets Manager is the AWS data protection service for storing credentials, API keys, and OAuth tokens — anything that is sensitive, structured, and may need to rotate.

Secret structure and KMS encryption

A Secrets Manager secret stores a JSON object ({"username":"db_user","password":"..."}) and a list of versions. Each version has a unique version ID and a list of staging labels (AWSCURRENT, AWSPENDING, AWSPREVIOUS). The secret is encrypted at rest with a KMS key — by default aws/secretsmanager (the AWS-managed key for Secrets Manager) or a customer-managed key for stricter data protection requirements.

Reading a secret in an application

The application calls secretsmanager:GetSecretValue with the secret ID. AWS returns the current version. Best practices:

• Use IAM role-based access (instance profile, Lambda execution role).
• Cache the secret in memory for a short TTL to reduce API calls.
• For RDS, use the AWS SDK's RDS-Secrets Manager integration that auto-refreshes credentials when the secret rotates.

Automatic rotation via Lambda

Secrets Manager supports automatic rotation by invoking a Lambda function on a schedule. The rotation window is configurable from 1 to 365 days. AWS provides pre-built rotation Lambda templates for:

• RDS MySQL, PostgreSQL, MariaDB, Oracle, SQL Server.
• Amazon DocumentDB.
• Amazon Redshift.

The four-stage rotation Lambda flow:

1. createSecret — generate a new password, store it as the AWSPENDING version of the secret.
2. setSecret — update the database with the new password (the actual change to the production system).
3. testSecret — verify the new password works by attempting a connection with AWSPENDING.
4. finishSecret — promote AWSPENDING to AWSCURRENT, demote the previous AWSCURRENT to AWSPREVIOUS.

For non-RDS secrets (third-party APIs, SSH keys), you write a custom rotation Lambda that follows the same four-stage contract.

Common rotation Lambda failures

• Network path missing: the Lambda must reach both the secret (Secrets Manager VPC endpoint or public NAT path) and the database (security group ingress for the Lambda's ENI). The most common single failure is missing security group access from Lambda subnets to the RDS instance.
• IAM permissions missing: the Lambda execution role needs secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, secretsmanager:UpdateSecretVersionStage, and the relevant database modify permission.
• Rotation timeout: the Lambda must finish all four stages within its execution timeout. For large databases or slow networks, increase the Lambda timeout to 5 minutes.
• Cross-account secret: a cross-account Secrets Manager rotation requires resource policy on the secret allowing the rotating principal.

Parameter Store SecureString vs Secrets Manager: When to Use Each

Both services offer encrypted storage of sensitive values. The data protection decision matrix:

The clean SOA-C02 rule:

• Use Parameter Store SecureString for non-rotating sensitive configuration (API endpoint, encryption salt, license keys) where Secrets Manager's $0.40/month per secret is overkill.
• Use Secrets Manager when the secret needs scheduled automatic rotation, when it is a database credential, or when the value exceeds 4 KB.

Reviewing Findings: Security Hub, GuardDuty, Inspector

The data protection operational loop closes with reviewing findings — proactive detections from security services that surface gaps in your encryption, access, or vulnerability posture.

GuardDuty: continuous threat detection

GuardDuty analyzes VPC Flow Logs, DNS query logs, and CloudTrail event logs to detect anomalous behavior:

• Reconnaissance findings (Recon:EC2/Portscan) — port scanning from outside or inside.
• Backdoor findings (Backdoor:EC2/C&CActivity.B!DNS) — instance communicating with known C2 domains.
• Cryptocurrency mining (CryptoCurrency:EC2/BitcoinTool.B) — DNS queries to mining pools.
• Unauthorized access (UnauthorizedAccess:EC2/MaliciousIPCaller.Custom) — login from threat-intel-flagged IP.

GuardDuty is enabled per region and per account. AWS Organizations support lets a delegated administrator enable GuardDuty across every member account. Findings have severity (Low / Medium / High) and a finding ID; CloudTrail-source findings include the principal ID.

Amazon Inspector: vulnerability scanning

Inspector scans for software vulnerabilities and unintended network exposure on:

• EC2 instances — packages, kernel CVEs.
• ECR container images — base image vulnerabilities, package CVEs.
• Lambda functions — function code dependencies.

Inspector is continuous by default — when an EC2 instance launches with the SSM agent running, Inspector picks it up; when an ECR image is pushed, Inspector scans it. Findings carry a CVSS score and a remediation recommendation.

Security Hub: aggregation and ASFF

Security Hub is the central aggregation layer. It pulls findings from GuardDuty, Inspector, Macie, Firewall Manager, IAM Access Analyzer, AWS Config, and third-party partners, normalizes everything into the AWS Security Finding Format (ASFF), and presents:

• Findings list with severity, workflow status, region, account.
• Insights — saved queries (e.g., "all critical findings in production").
• Standards & Controls — pre-built compliance packs (CIS AWS Foundations, AWS Foundational Security Best Practices, PCI-DSS).
• Workflow status transitions: NEW → NOTIFIED → SUPPRESSED → RESOLVED.

Security Hub finding workflow is what SOA-C02 tests:

• A new finding arrives; the SysOps team acknowledges it (NOTIFIED).
• After remediation, the team marks RESOLVED.
• For accepted-risk false positives, the team marks SUPPRESSED so it does not re-page.

Wiring findings into automated remediation

The standard SOA-C02 remediation pipeline:

1. GuardDuty / Inspector / Security Hub finding generated.
2. EventBridge rule on aws.securityhub or aws.guardduty event source matches the finding pattern.
3. EventBridge target — Lambda function or Systems Manager Automation runbook.
4. Remediation action: isolate EC2 (security group quarantine), revoke IAM session, snapshot for forensics, page on-call.

Scenario Pattern: ACM Certificate Won't Auto-Renew

Canonical SOA-C02 troubleshooting pattern. The runbook:

1. Confirm the validation method. ACM Console → Certificates → select cert → "Domains" tab. If validation method is DNS, every domain must have a valid CNAME validation record currently in DNS.
2. Check the validation status of each domain. Look for "Pending validation" or "Failed". The cert as a whole renews only when every domain validates.
3. Verify CNAME records in Route 53 (or external DNS). ACM's validation CNAME has a specific name and value — both must be present and resolve from the public internet.
4. Check if the certificate is attached to a service. ACM does not aggressively renew certificates that are not attached to any AWS service. Attaching the certificate to an ALB, NLB, CloudFront, or API Gateway re-enables renewal.
5. Inspect CloudWatch Events for renewal events. EventBridge aws.acm events with detail-type ACM Certificate Approaching Expiration or ACM Certificate Renewal Failure show the precise failure reason.
6. For email validation, check that the domain admin contact email is reachable; reissue with DNS validation if not.

The fix is virtually always restoring the DNS validation CNAME. Once the CNAME is back, ACM resumes auto-renewal on its next attempt (typically within hours).

Scenario Pattern: GuardDuty Reports Suspicious EC2 Outbound Traffic

Another canonical SOA-C02 pattern. GuardDuty fires Backdoor:EC2/C&CActivity.B!DNS against instance i-0abc123. The data protection remediation playbook:

1. Containment first. Move the instance into a quarantine security group that denies all inbound and outbound except the SSM endpoint (so investigators can still reach it via Session Manager). Do not terminate immediately — you need forensics.
2. Snapshot the EBS volumes for offline forensic analysis.
3. Disable the instance's IAM instance profile to revoke any credential exfiltrated into the instance.
4. Tag the instance Investigation=true and link to the GuardDuty finding ID.
5. Notify the on-call via SNS topic wired through the EventBridge → Security Hub finding pipeline.
6. Preserve CloudTrail and VPC Flow Logs for the affected time window — they are usually already stored in S3 with lifecycle rules, but confirm before any cleanup.
7. After investigation — restore from a known-clean AMI, rotate any credentials potentially exposed, update the GuardDuty Security Hub finding workflow status to RESOLVED.

A mature SysOps shop has this entire playbook automated via EventBridge → Lambda or Systems Manager Automation runbook so step 1 (containment) is instant, the remaining steps are partially automated, and the on-call is paged in parallel.

Common Trap: KMS Multi-Region Keys

A multi-Region KMS key has the same key ID and the same key material replicated across regions, so ciphertext encrypted in one region can be decrypted in another. The traps:

• Multi-Region keys are not the default — you must explicitly create a primary key as multi-Region, then create replica keys in target regions. Standard KMS keys are single-region.
• Each replica has its own key policy — granting permission in one region does not grant it in another. The data protection administrator must mirror policies.
• Multi-Region keys do not automatically replicate to new regions — adding a region requires a new replica creation.
• Multi-Region keys are useful for cross-region disaster recovery scenarios where data is replicated (S3 CRR, DynamoDB global tables) and must remain decryptable in the recovery region. They are not a substitute for cross-account access patterns.

Common Trap: KMS Deletion Removes Data Permanently

When a customer-managed key is deleted, every ciphertext encrypted under that key becomes permanently unrecoverable. The 7-to-30-day waiting period is a safety net, not a guarantee — once the period passes, the key material is irreversibly destroyed. Operational practice:

• Default to 30 days on every key deletion request, never 7.
• Disable the key first for at least a week before scheduling deletion. A disabled key fails every encryption/decryption call, so any application still using it surfaces the dependency immediately.
• Audit CloudTrail for any kms:Decrypt calls against the key during the disabled period. If there is any usage, do not proceed with deletion.
• For any data protection critical key (RDS encryption, S3 CRR target), require a second engineer's approval before scheduling deletion.

Common Trap: ACM Certificate Renewal via Email

Email validation is the legacy ACM validation method. It sends a validation email to a small set of WHOIS-derived addresses (admin@, administrator@, hostmaster@, webmaster@, postmaster@ plus the WHOIS contact). Auto-renewal via email validation is fragile because:

• Email contacts age out — the original webmaster@ mailbox no longer routes anywhere.
• WHOIS records get masked behind privacy services, breaking the renewal email pathway.
• The renewal email is easy to mistake for spam or phishing.

The SOA-C02 right answer for any new public certificate is DNS validation. For existing email-validated certificates, the migration is to reissue the certificate with DNS validation before the next renewal cycle.

Common Trap: Secrets Manager Rotation Lambda Fails Silently

Rotation failure does not page anyone unless you wire it explicitly. Operational hardening:

• Configure the secret with a rotation schedule plus a CloudWatch alarm on the rotation Lambda's Errors metric.
• Subscribe the alarm to an SNS topic that pages the data protection on-call.
• Build a CloudWatch dashboard widget showing each secret's last successful rotation time — visible drift means rotation is broken even if no alarm fires.
• For RDS rotation, monitor the Lambda's VPC connectivity (DurationByPhase metric) — most failures are network path issues to the database.

SOA-C02 vs SAA-C03: The Operational Lens on Data Protection

The same services, different lenses.

The SAA candidate selects the data protection service; the SOA candidate operates it, troubleshoots the failure modes, and stitches it into the broader monitoring and remediation fabric.

Exam Signal: How to Recognize a Domain 4.2 Question

Domain 4.2 questions follow predictable shapes. Recognize them and your time per question drops dramatically.

• "The KMS key was deleted, can the data be recovered?" — within the 7–30-day waiting period yes (cancel deletion); after the waiting period no, ever.
• "Auto-renewal failed for the ACM certificate" — DNS validation CNAME removed, certificate no longer attached, or domain validation expired. Restore the CNAME.
• "Database password rotation must happen every 30 days without downtime" — Secrets Manager with rotation Lambda; RDS-managed master credential is the easiest path.
• "Application logs sensitive credentials" — migrate the credential into Secrets Manager or Parameter Store SecureString; remove from log output.
• "GuardDuty flagged an EC2 communicating with C2" — quarantine via security group, snapshot for forensics, disable IAM profile, page on-call, do not immediately terminate.
• "Compliance requires encryption with a customer-managed key, not the AWS-managed key" — recreate or migrate the resource with a customer-managed CMK and update the key policy to permit the service.
• "Cross-account decryption fails despite IAM allowing it" — the KMS key policy in the source account must grant the destination account principal kms:Decrypt (or use a grant); IAM alone is insufficient for KMS.
• "Inspector reports a critical CVE on an EC2 instance" — patch via Systems Manager Patch Manager or rebuild from a refreshed Image Builder AMI; mark the Security Hub finding as RESOLVED.

Decision Matrix — Data Protection Construct for Each SysOps Goal

Use this lookup during the exam.

Common Traps Recap — Data Protection on AWS

Every SOA-C02 attempt will see two or three of these distractors.

Trap 1: Automatic key rotation re-encrypts existing data

It does not. Automatic rotation rotates the backing key material; existing ciphertexts continue to use the old material. To re-encrypt, you must read and write each object, or copy to a new resource using a new key.

Trap 2: KMS key deletion is instant

It is not. There is a mandatory 7-to-30-day waiting period during which the key is in PendingDeletion. Cancel the schedule to recover.

Trap 3: ACM email validation auto-renews reliably

It often does not. WHOIS contacts age out, validation emails go to spam. DNS validation is the right answer.

Trap 4: Detailed KMS access via IAM only

KMS requires both the key policy and the IAM policy (when delegated) to allow the action. IAM alone is insufficient unless the key policy includes the IAM-delegation statement.

Trap 5: Secrets Manager replaces all credential storage

Parameter Store SecureString is sufficient and cheaper for non-rotating sensitive configuration. Secrets Manager is for rotation, large values, and native database integration.

Trap 6: Multi-Region keys auto-propagate policies

They do not. Each replica has its own key policy that the administrator must keep in sync.

Trap 7: GuardDuty findings page automatically

They do not. You must wire EventBridge → SNS or Security Hub → EventBridge → SNS to actually page the on-call.

Trap 8: Inspector requires manual scans

It does not. Continuous mode is the default and triggers on instance launch, image push, and software change.

Trap 9: Security Hub aggregates everything by default

It does not. You must enable each integration (GuardDuty, Inspector, Macie, Config) explicitly.

Trap 10: Encryption in transit always equals ACM

ACM is the right answer for AWS-terminated TLS. Encryption in transit between AWS regions also includes the AWS backbone (already encrypted) plus VPN/Direct Connect with optional MACsec for extra assurance.

FAQ — Data Protection on AWS

Q1: When should I use a customer-managed KMS key versus the AWS-managed key?

Use a customer-managed key (CMK) when you need any of: control over the key policy, ability to grant cross-account access, automatic rotation that you can audit, the option to disable or delete the key on your timeline, dedicated CloudTrail logs distinct from other workloads, or compliance evidence that the data protection key is under your direct administrative control. Use the AWS-managed key (aws/s3, aws/ebs, aws/rds) when none of those apply — usually for development or non-regulated workloads where the AWS-managed default is operationally simpler. For SOA-C02, the giveaway phrase "compliance team requires control of the encryption key" or "audit team needs to see who used the key" maps to customer-managed every time.

Q2: How does KMS automatic rotation interact with old ciphertexts?

KMS rotates the backing key material every 365 days but keeps the old material indefinitely so existing ciphertexts remain decryptable. The key ID and ARN do not change. New encryption operations use the new material; old ciphertexts decrypt against whichever version they were encrypted under. KMS handles version selection internally — applications never see it. What rotation does not do is re-encrypt existing data; if data protection policy requires re-encryption (cryptographic erasure for example), you must read and write every ciphertext through the alias, which causes the encryption to use the current material. Automatic rotation buys forward secrecy on new data, not retroactive cleanup of old data.

Q3: What is the right way to remediate a GuardDuty finding for a compromised EC2 instance?

Containment first, forensics second, recovery third. Step one: move the instance into a quarantine security group that denies all traffic except the SSM endpoint, so Session Manager investigators can still reach the host without giving the attacker any path out. Step two: snapshot the EBS volumes for offline analysis. Step three: disable the IAM instance profile so any credentials extracted from the instance are revoked. Step four: page the on-call via the EventBridge → SNS pipeline you wired ahead of time. Step five: investigate, identify the root cause, and rebuild from a known-clean AMI. Step six: rotate any potentially leaked credentials (database passwords, API keys, IAM access keys). Mature SOA shops have steps one through four automated via EventBridge → Lambda or SSM Automation runbook; SOA-C02 favors the automated answer over manual steps.

Q4: When does Parameter Store SecureString suffice and when do I need Secrets Manager?

Use Parameter Store SecureString when the secret is mostly static — API endpoint URLs, license keys, application configuration, encryption salts, feature flags. The cost difference is meaningful at scale: Parameter Store Standard tier is free; Secrets Manager is $0.40 per secret per month. Use Secrets Manager when the secret needs scheduled automatic rotation (database credentials, API tokens with short TTL), when the value exceeds Parameter Store's 4 KB / 8 KB limits, or when you need the native AWS database integration (RDS-managed master credential). For a 200-secret application portfolio, mixing the two is operationally normal — Parameter Store for the 180 static values, Secrets Manager for the 20 that rotate.

Q5: How does ACM auto-renewal work and why does it fail?

ACM begins automatic renewal 60 days before expiration. For DNS-validated public certificates, ACM rechecks every domain's validation CNAME record; if every domain is still validated, ACM issues a new certificate and replaces the old one on every attached resource (ALB, NLB, CloudFront, API Gateway) without disruption. The renewal fails when: (a) the DNS validation CNAME was removed after initial issuance — the most common cause; (b) one of the alternate names in a multi-domain certificate has a stale or missing CNAME; (c) the certificate has not been attached to any AWS service for an extended period; (d) email validation contacts no longer route. The fix is restoring the validation CNAME and triggering reissuance. For data protection hardening, alarm on the CloudWatch DaysToExpiry metric at 45 and 30 days remaining as defense-in-depth against silent renewal failure.

Q6: How do I enable encryption at rest on an existing unencrypted RDS instance?

You cannot enable encryption in place — RDS encryption is set at instance creation. The data protection migration sequence is: (1) take a manual DB snapshot of the unencrypted instance; (2) copy the snapshot, choosing "Enable encryption" with the desired KMS key (AWS-managed aws/rds or your customer-managed CMK); (3) restore the encrypted snapshot into a new DB instance; (4) update application connection strings or use a CNAME flip to cut traffic over to the encrypted instance; (5) once verified, decommission the unencrypted instance and delete its snapshots. The cutover causes a brief outage equal to the application's reconnect time. For Multi-AZ instances, the same sequence applies; for Aurora, you can use the cluster snapshot copy approach.

Q7: What is envelope encryption and why does AWS use it?

Envelope encryption is the technique of encrypting data with a fast symmetric data key, then encrypting that data key with a slower (more expensive) master key in KMS. AWS uses it because calling KMS for every byte of S3 / EBS / RDS data would be impossibly slow and expensive. With envelope encryption, KMS is called once per object (or per bucket-key time slice with S3 Bucket Keys) to wrap the data key. The actual bulk encryption uses AES-256 directly on the storage host, at line rate. The encrypted data key is stored alongside the object as metadata. To decrypt, the storage service calls KMS once to unwrap the data key, then decrypts the object locally. This pattern keeps KMS API costs and latency manageable while preserving the data protection benefit of a centrally managed master key.

Q8: How should I structure Security Hub for a multi-account organization?

Designate a delegated administrator account for Security Hub at the AWS Organizations level — usually a dedicated security tooling account, not the management account. Enable Security Hub in every member account through the delegated admin's "Auto-enable" feature so new accounts onboard automatically. Enable the AWS Foundational Security Best Practices standard and the CIS AWS Foundations Benchmark standard at minimum. Enable GuardDuty and Amazon Inspector as findings sources, plus IAM Access Analyzer and AWS Config. Configure cross-account aggregation so every member's findings flow into the delegated admin's region of choice. Wire EventBridge rules in the delegated admin account on aws.securityhub events to route critical findings to SNS / Lambda / SSM Automation for triage. This is the SOA-C02 reference architecture for organization-wide data protection observability.

Q9: What is the operational difference between a KMS grant and a key policy?

A key policy is the resource policy on the KMS key — long-lived, declared once, applies broadly to listed principals. A grant is a programmatic, lightweight permission attached to the key for a specific principal and a specific set of operations, optionally bounded by encryption context. Grants are the right answer when: (a) a permission is short-lived (the lifetime of an EBS volume creation, an EC2 instance, a Lambda invocation); (b) the grantee should not have permission inscribed in the key policy; (c) you want to be able to revoke without rewriting policy. AWS services routinely use grants under the hood — for example, when you launch an encrypted EC2 instance, EC2 calls CreateGrant on the volume's KMS key for the instance, then retires the grant when the instance terminates. SOA-C02 expects you to know that grants are the AWS-recommended pattern for service-to-resource delegation; key policies are for human and role-based access.

Q10: What is the right way to structure data protection findings remediation at scale?

Build a single multi-account pipeline once, then onboard accounts to it. The reference architecture: (1) GuardDuty, Inspector, Macie, AWS Config, IAM Access Analyzer enabled in every account via Organizations auto-enable; (2) Security Hub aggregating findings across accounts and regions into a delegated admin account; (3) EventBridge rules in the delegated admin account on aws.securityhub finding-imported events, filtered by severity (Critical, High); (4) EventBridge targets — Lambda for fast actions like security group quarantine, SSM Automation for multi-step runbooks (snapshot, isolate, page, ticket), SNS for human notification; (5) CloudWatch dashboards showing finding counts by severity per account; (6) explicit workflow status hygiene — every NEW finding gets NOTIFIED within an SLA, false positives are SUPPRESSED with a reason tag, RESOLVED findings track mean-time-to-remediate as an operational metric. The SOA-C02 right answer for any scale-out data protection scenario is "use Security Hub + EventBridge + SSM Automation"; ad-hoc per-account scripts lose points.

Further Reading and Related Operational Patterns

• AWS KMS Developer Guide
• AWS KMS Concepts and Key Types
• Rotating AWS KMS Keys
• KMS Grants
• KMS Key Policies
• KMS Multi-Region Keys
• Deleting AWS KMS Keys
• AWS Certificate Manager User Guide
• ACM Managed Certificate Renewal
• ACM DNS Validation
• AWS Private Certificate Authority
• AWS Secrets Manager User Guide
• Rotating Secrets in AWS Secrets Manager
• Systems Manager Parameter Store
• AWS Security Hub User Guide
• Amazon GuardDuty User Guide
• Amazon Inspector User Guide
• AWS SOA-C02 Exam Guide v2.3 (PDF)

Once data protection is in place, the natural follow-on operational topics are: IAM Policies, MFA, SCPs, and Access Troubleshooting for the access control side that complements encryption; CloudTrail and AWS Config for Audit and Compliance for the audit trail that proves your data protection controls are working; Multi-Account Strategy with Organizations and Control Tower for scaling these data protection patterns across many accounts; and Backup, Restore, and Disaster Recovery Procedures for the resilience side of data protection where encrypted snapshots must remain decryptable in the recovery scenario.

• IAM Policies, MFA, SCPs, and Access Troubleshooting — SOA-C02 Study Notes
• Backup, Restore, and Disaster Recovery Procedures — SOA-C02 Study Notes
• CloudTrail and AWS Config for Audit and Compliance — SOA-C02 Study Notes
• Multi-Account Strategy with Organizations and Control Tower — SOA-C02 Study Notes