AWS Data Security Controls: KMS Encryption, S3 Encryption, and Key Management

Almost every AWS service encrypts data at rest by calling AWS Key Management Service, so the real architectural decision is never "should I encrypt" — it is which kind of key the service should use. KMS offers three ownership levels, and SAA-C03 scenarios are written so that only one of them satisfies the requirement.

AWS owned keys belong to the service itself. You never see them, cannot audit their use per-account, and cannot control them; they simply provide baseline encryption at no cost. AWS managed keys (the aws/s3, aws/ebs style keys) live in your account and are visible in the KMS console, but the control stops there: AWS rotates them automatically every year, you cannot edit their key policies, you cannot use them in cross-account scenarios, and you cannot disable or delete them. They are free and require zero administration — which is exactly what makes them wrong the moment a scenario demands control.

Customer managed keys are the answer whenever the requirement includes any of these words: control rotation, restrict which roles or services can use the key, share encrypted data with another account, disable the key immediately, or audit against a key policy you wrote. You author the key policy (the resource-based policy that is the ultimate authority over the key — even account administrators are locked out if the policy does not allow them), you can issue grants for temporary, programmatic access (how services like EBS use your key on your behalf), and you can allow cross-account use by combining a key policy statement for the external account with an IAM policy in that account. Customer managed keys cost a monthly fee per key plus API-request charges, and deletion is deliberately hard: you schedule it with a 7–30 day waiting period, because destroying a key makes everything it encrypted permanently unreadable.

Underneath all of this sits envelope encryption: KMS keys never leave KMS and can only encrypt small payloads directly, so services generate a data key, encrypt your actual data with it locally, then use the KMS key only to encrypt the data key. The encrypted data key is stored alongside the data; decryption means asking KMS to unwrap the data key first. That is why disabling one KMS key can instantly cut off access to terabytes of data — and why CloudTrail records a KMS API call every time encrypted data is opened.

The exam probes this as an elimination exercise: a scenario states a requirement like "the security team must approve which principals can use the encryption key" or "encrypted snapshots must be shared with a partner account," and only the customer managed key option survives. Default answers (SSE with AWS managed keys) appear as distractors that encrypt the data but fail the control requirement.

KMS is a multi-tenant managed service: your keys are protected by hardware security modules that AWS operates and shares across customers, with strong logical isolation. For most workloads — including regulated ones — that is enough, and KMS wins on integration: every major AWS service can call it natively, CloudTrail logs every operation, and IAM plus key policies govern access. AWS CloudHSM exists for the narrower case where compliance language demands more than logical isolation: a dedicated, single-tenant hardware security module, validated to FIPS 140 Level 3, inside your VPC, where you manage the users and keys on the device and AWS has no access to your key material at all.

Two nuances keep appearing in questions. First, CloudHSM and KMS are not mutually exclusive: a KMS custom key store backs KMS keys with your CloudHSM cluster, giving you KMS's service integration on top of single-tenant hardware — the answer when a scenario needs both native S3/EBS integration and dedicated HSMs. Second, CloudHSM shifts operational responsibility to you: durability, user management, and client configuration are your problem, so it loses every "LEAST operational overhead" contest.

On the exam, read the compliance sentence literally. "Auditable, centrally controlled encryption keys" means KMS customer managed keys. "Dedicated hardware," "single-tenant," "the cloud provider must never be able to access key material," or "FIPS 140 Level 3 hardware you control" means CloudHSM. Choosing CloudHSM for an ordinary audit requirement is the classic over-engineering trap.

Encryption at rest protects stored data; TLS protects data moving between clients and your architecture and between tiers inside it. On AWS the certificate machinery is AWS Certificate Manager (ACM): it issues public TLS certificates for domains you can validate (DNS validation is the practical choice), at no cost, and deploys them to the managed endpoints that terminate TLS for you — Application Load Balancers, CloudFront distributions, and API Gateway. You cannot export ACM public certificates to install on your own EC2 instances; ACM certificates only work on integrated AWS services. If you need certificates on instances or on-premises servers, that is ACM Private CA territory (or certificates you bring yourself).

The placement rule the exam states precisely and tests relentlessly: ACM certificates are regional resources. A certificate can only be attached to resources in the Region where it was requested or imported — an ALB in eu-west-1 needs a certificate in eu-west-1. The one carve-out is CloudFront: because CloudFront is a global service, the ACM certificate for a distribution must exist in us-east-1 (N. Virginia), regardless of where your origins or users are. A scenario describing a CloudFront distribution that cannot use a custom domain certificate created in ap-southeast-2 is testing exactly this fact, and the fix is to request the certificate again in us-east-1.

Issuing a certificate is half the job; enforcing HTTPS is the other half, and each service has its own lever. On an ALB, keep the HTTP :80 listener but configure it to redirect to HTTPS. On CloudFront, set the viewer protocol policy to redirect HTTP to HTTPS (or HTTPS-only), and separately choose the origin protocol policy so the CloudFront-to-origin leg is also encrypted. For S3, add a bucket policy that denies all requests where aws:SecureTransport is false — the standard answer for "ensure data in the bucket can only be accessed over encrypted connections." For databases and internal services, require TLS in the client connection settings or parameter groups.

SAA-C03 tests transit encryption in two shapes: placement questions (which Region does this certificate go in — the answer hinges on ALB-regional vs CloudFront-us-east-1) and enforcement questions ("the security team requires all access to be encrypted in transit" — the answer is the redirect, protocol policy, or aws:SecureTransport deny, not merely "attach a certificate").

Compliance frameworks require keys and certificates to be rotated, and the exam wants you to know which mechanisms are automatic, which are opt-in, and which are entirely manual.

For KMS: AWS managed keys rotate automatically every year, and you cannot change that — no faster, no slower, no off switch. Customer managed keys support optional automatic rotation: you enable it, and KMS transparently generates new key material on a yearly cadence by default. The crucial mechanic is that rotation keeps all previous key material: the key's ID and alias never change, old ciphertexts are still decrypted with the material that created them, and nothing needs to be re-encrypted. Rotation limits how much data any single generation of key material protects; it does not retire old ciphertexts. Two cases fall outside automatic rotation entirely: keys with imported key material (bring-your-own-key) and keys in custom key stores cannot auto-rotate — for those you perform manual rotation by creating a new key and re-pointing the alias to it. Aliases are the reason applications should always reference keys by alias: manual rotation then requires no code change, but note that manual rotation means new data uses the new key while old data still requires the old key to remain available.

For certificates: ACM automatically renews the public certificates it issued, as long as the certificate is in use and DNS validation records remain in place — this is the single biggest operational argument for DNS validation over email validation, which requires a human to respond. Imported certificates are never renewed by ACM: you must obtain a new certificate from your CA and re-import it before expiry (ACM sends expiration notices, but the work is yours). Certificates from ACM Private CA used with integrated services also renew automatically.

Exam probes here are subtle rather than deep. A scenario requiring "encryption keys rotated automatically every year with no application changes" is satisfied by KMS automatic rotation — a distractor will propose manually re-encrypting data. A scenario where certificates keep expiring and taking the site down points to imported certificates or email validation; the fix is ACM-issued certificates with DNS validation. And any requirement to rotate on a custom schedule or with imported material pushes you to manual rotation via aliases.

S3 encrypts every new object by default with SSE-S3, so the exam question is never whether S3 data is encrypted — it is whether the default satisfies the stated requirement. The options differ on exactly two axes that scenarios exploit: who owns the key and what audit and access control you get over it.

The decision rule compresses well. No key requirement → SSE-S3. Audit, key-level access control, or cross-account → SSE-KMS with a customer managed key. KMS request costs at massive scale → add Bucket Keys. "AWS must never see the plaintext" → client-side encryption — no server-side option can meet that wording, because every SSE variant has S3 performing the encryption on data it momentarily holds in plaintext. To mandate a particular encryption type on uploads, use a bucket policy that denies PutObject unless the request specifies the required server-side encryption header.

One more SSE-KMS behavior earns its own trap: because decryption requires KMS permissions, a principal can have full S3 permissions and still get access-denied on a KMS-encrypted object. Exam stems describe exactly that symptom — "the user has s3:GetObject but receives an error on some objects" — and the answer is missing kms:Decrypt on the key. Expect the S3 options to appear side by side as answer choices, differing only in key ownership; match the requirement's strongest word (audit, control, never-see-plaintext) to the table row that provides it.

Block storage and database encryption share one governing rule: encryption is set when the resource is created, and cannot be toggled on an existing resource in place. Everything the exam asks about EBS and RDS encryption is a consequence of that rule.

EBS volumes encrypt with a KMS key (the aws/ebs AWS managed key by default, or a customer managed key you specify), covering the volume, its snapshots, and data moving between the volume and the instance. Enable EBS encryption by default at the account/Region level and every new volume is encrypted without anyone remembering to tick the box — the standard answer to "ensure all future volumes are encrypted with LEAST operational overhead." Encryption is sticky in the safe direction: snapshots of an encrypted volume are encrypted, and volumes restored from encrypted snapshots are encrypted; you cannot strip encryption off. For an existing unencrypted volume, the path is fixed and worth memorizing as a sequence: snapshot the volume → copy the snapshot with encryption enabled (choosing your KMS key) → create a new volume from the encrypted copy → swap it onto the instance. The snapshot-copy step is also how you re-encrypt under a different key, and how you share encrypted data across accounts — which requires a customer managed key, because snapshots encrypted with the default AWS managed key cannot be shared.

RDS follows the same shape. Enable encryption at instance creation and it covers the instance's storage, automated backups, snapshots, and read replicas. You cannot encrypt a running unencrypted instance, and you cannot restore an unencrypted snapshot directly into an encrypted instance. The migration path mirrors EBS: take a snapshot → copy the snapshot with encryption enabled → restore a new instance from the encrypted copy → repoint the application (expect a cutover window, or use replication tooling to narrow it). Replicas add a regional wrinkle: KMS keys are regional, so a cross-Region encrypted read replica or snapshot copy is encrypted with a key in the destination Region, which you specify during the copy.

Exam scenarios here are procedural: "an unencrypted production database must be encrypted to meet a new compliance requirement — what should the solutions architect do?" The correct chain is always snapshot → encrypted copy → restore/create → cut over. Distractors offer the impossible shortcuts: "modify the instance to enable encryption" or "enable encryption on the existing volume." If an option flips encryption on in place, eliminate it.

Encryption protects data from whoever lacks the key; access controls decide who legitimately gets to it, and Task 1.3 expects you to layer them. The first layer is the policy pair. IAM policies are identity-based: attached to users and roles, they answer "what can this principal do, across all services?" S3 bucket policies are resource-based: attached to the bucket, they answer "who may touch this bucket, and under what conditions?" Within one account, access is granted if either an IAM policy or the bucket policy allows it and nothing explicitly denies it — an explicit deny anywhere always wins. Bucket policies earn their place in three situations IAM alone handles badly: cross-account access (grant another account's principals access without creating roles for each), bucket-wide guardrails (deny unencrypted uploads, deny non-TLS transport), and condition-based restriction (allow access only from specific VPC endpoints or IP ranges).

The second layer is the blunt instrument: S3 Block Public Access. Applied at the account or bucket level, it overrides any bucket policy or ACL that would otherwise expose data publicly. It is the exam's answer to "prevent any bucket in the organization from ever being made public" — a preventive control, superior to detective alternatives like alerting on public buckets after the fact, and it should be on at the account level unless a bucket genuinely serves public content.

The third layer is the network path. By default, traffic from a VPC to S3 resolves to public service endpoints. A VPC gateway endpoint for S3 (or DynamoDB) keeps that traffic on the AWS network with no internet gateway or NAT in the path, at no charge; interface endpoints (AWS PrivateLink) do the same for most other services via an ENI in your subnet. The governance move the exam loves: combine the endpoint with a bucket policy that denies access unless the request arrives via your endpoint (condition on aws:sourceVpce) — now the data has exactly one door, and it is private. "Data must not traverse the public internet" is a VPC endpoint requirement, not an encryption requirement.

The fourth layer is knowing what you are protecting: Amazon Macie uses machine learning and pattern matching to discover sensitive data — PII, credentials, financial records — in S3, and reports where it lives and whether the buckets holding it are public or unencrypted. Any stem containing "identify buckets containing personally identifiable information" or "discover sensitive data at scale" is a Macie question. Expect governance items to be layering questions: the correct answer combines a preventive control (Block Public Access, deny-conditions) with the private path or discovery tool the requirement names, while distractors offer a single control or a detective one where prevention was demanded.

Compliance requirements about data usually arrive as sentences about time: keep it for seven years, make it undeletable, be able to recover it, keep a copy in another Region. Each phrase maps to a specific control, and the exam grades you on the mapping.

Immutability is S3 Object Lock: write-once-read-many (WORM) protection with a retention period per object, on a bucket with versioning enabled (a prerequisite). Its two modes are the decision point. Governance mode protects objects but lets specially-permissioned users override or shorten retention — right for internal policy where administrators need an escape hatch. Compliance mode allows no one, not even the root user, to delete an object version or shorten its retention until the period expires — the only correct answer when the stem says "regulatory requirement," "must not be deleted by any user," or "MOST secure" retention. A legal hold is the third tool: indefinite protection with no expiry, applied and removed explicitly, for litigation scenarios where the end date is unknown.

Recovery from mistakes is versioning on its own: overwrites and deletes become recoverable prior versions (a delete merely adds a delete marker), with MFA Delete as an extra gate on permanent deletion. Cost-aligned retention is lifecycle configuration: transition objects to cheaper storage classes as they age — Standard-IA, then the Glacier tiers for archives — and expire them (and their noncurrent versions) when the retention clock runs out. A seven-year retention requirement is typically Object Lock for immutability plus a lifecycle rule moving the data to a Glacier class for cost, and distractors will offer one without the other.

Geographic and organizational survival is replication and backup — and they are not the same control. Cross-Region Replication (CRR) continuously copies new S3 objects to a bucket in another Region (versioning required on both sides), answering requirements to keep data hundreds of miles away or serve it closer to a second team; it can even replicate into a different account, isolating the copy from a compromise of the source account. But replication faithfully propagates changes — it is availability, not point-in-time protection. Backups — RDS automated backups and snapshots, EBS snapshots, and AWS Backup for centralized, policy-driven scheduling across services — give you point-in-time recovery, and AWS Backup Vault Lock extends WORM immutability to the backups themselves. Exam stems distinguish these by intent: "recover from accidental deletion or corruption" needs versioning or backups; "retain in a second Region" needs CRR or cross-Region backup copies; "prevent anyone from tampering with retained data" needs Object Lock or Vault Lock in compliance mode.

Scenario 1 — auditable keys and a partner account. A financial-services company stores reports in S3. Regulators require that the security team control exactly which principals can decrypt the data, that every decryption be auditable, and that a partner AWS account be able to read one prefix. Work the requirements against the key-type ladder. SSE-S3 fails immediately: no key policy, no key-usage audit trail. SSE-KMS with the AWS managed aws/s3 key gets CloudTrail logging of key use but fails twice — its key policy cannot be edited, and AWS managed keys cannot be used cross-account. CloudHSM is over-engineering: nothing in the requirement says single-tenant hardware, and it would add operational burden without adding a required capability. The answer is SSE-KMS with a customer managed key: the security team authors the key policy (control), CloudTrail records every encrypt/decrypt (audit), and a key policy statement plus the partner's IAM policies grant cross-account decryption — paired with a bucket policy granting the partner account access to the prefix. This elimination pattern — each stronger requirement killing one more option — is exactly how the real items are constructed.

Scenario 2 — the unencrypted production database. An audit finds a production RDS instance unencrypted; the new policy requires encryption at rest with a customer managed key, with minimal disruption. There is no in-place toggle, so any option that "modifies the instance to enable encryption" is wrong by mechanism. The path: snapshot the instance → copy the snapshot with encryption enabled, selecting the customer managed key → restore a new instance from the encrypted copy → cut the application over (a maintenance window, or replication to narrow the gap). The same reasoning answers the EBS variant: snapshot, encrypted copy, new volume, swap. When two answer options both reach an encrypted database, prefer the one that follows this exact sequence; the distractor usually skips the copy step or claims a direct restore of an unencrypted snapshot into an encrypted instance.

Scenario 3 — seven years, untouchable. A healthcare provider must retain records for seven years, guarantee no employee — including administrators — can delete or alter them, and minimize storage cost. "No one including administrators" selects Object Lock in compliance mode (governance mode fails: privileged users can override it), which requires versioning. Cost drives a lifecycle rule transitioning records to a Glacier storage class. If the stem adds "survive a Regional disaster," layer Cross-Region Replication to a second locked bucket. Three requirements, three controls, one answer option that contains all three — the option with only two is the trap.