2 · Data Protection¶
Domain 1 — Design Secure Architectures · 30%
Data protection questions are usually one of three shapes: "how do I encrypt this?", "who controls the key?", and "where do I store this secret / certificate?" The services are KMS, CloudHSM, Secrets Manager, Parameter Store, ACM, and Macie — this page is about picking the right one and knowing the encryption mechanics the exam probes.
Core concept¶
Two kinds of encryption, and the exam expects both:
- At rest — data sitting in S3, EBS, RDS, DynamoDB, etc. Almost always done with AWS KMS.
- In transit — data moving over the network. Done with TLS (certificates from ACM), plus VPN / Direct Connect for hybrid links.
Envelope encryption is the mechanic underneath nearly all AWS at-rest encryption. KMS keys don't encrypt your big objects directly (a KMS key can only encrypt ≤ 4 KB). Instead:
- A service asks KMS for a data key (
GenerateDataKey). KMS returns it twice: once in plaintext, once encrypted under the KMS key. - The service encrypts your data with the plaintext data key, then throws the plaintext away and stores the encrypted data key next to the ciphertext.
- To decrypt, the service sends the encrypted data key back to KMS, which returns the plaintext data key, which decrypts the data.
Think of the KMS key as a master key locked in a vault that only ever encrypts other keys — the data keys — so the master itself never leaves KMS and never touches your bulk data.
KMS — who controls the key¶
A KMS key (formerly "CMK") comes in three ownership flavours, and the difference is a common answer:
| Key type | Who manages it | You control policy / rotation? | Audit in CloudTrail? |
|---|---|---|---|
| Customer managed | You | Yes — full key policy, rotation, grants | Yes |
AWS managed (aws/service) |
AWS, per service | No policy control; auto-rotates yearly | Yes |
| AWS owned | AWS, shared | No | No |
Use a customer managed key whenever the scenario needs control: a specific key policy, cross-account key sharing, your own rotation schedule, or an audit trail of every use.
Key access is different from normal IAM — this trips people up. Every KMS key has a key
policy (a resource policy), and it is the root of access control. An IAM policy granting
kms:Decrypt only works if the key policy delegates to the account (the default key policy
includes "Principal": { "AWS": "arn:aws:iam::<acct>:root" }, which lets IAM policies in that account
govern the key). If the key policy doesn't delegate, no IAM policy can grant access. Grants are a
way to delegate limited, temporary key use to a principal (often another AWS service) without editing
the key policy.
Rotation (verified):
- Customer managed keys — automatic rotation is opt-in; default period 365 days, configurable, plus on-demand rotation. Only symmetric KMS keys with AWS-generated material.
- AWS managed keys — rotate automatically every ~year; you can't enable/disable it.
- Rotation keeps the same key ID/ARN — no application changes, old ciphertext still decrypts.
Deletion (verified): you can't delete a key immediately. Scheduling deletion enforces a 7–30 day waiting period (default 30), during which the key is pending deletion and unusable. Prefer disabling a key if you're unsure — deletion is irreversible and orphaned ciphertext becomes unrecoverable.
Multi-Region keys replicate a key (same key material) into other Regions so you can decrypt in a Region without a cross-Region KMS call — useful for cross-Region DR of encrypted data.
KMS vs CloudHSM¶
| AWS KMS | AWS CloudHSM | |
|---|---|---|
| Tenancy | Multi-tenant, managed | Single-tenant, dedicated hardware |
| Compliance | FIPS 140-2 Level 3 validated HSMs (KMS uses HSMs under the hood) | FIPS 140-2 Level 3, you get direct HSM control |
| Who holds keys | AWS manages the HSMs | You fully manage keys; AWS can't access them |
| Use when | Default for AWS-integrated encryption | You must own the keys, need HSM control, SQL Server/Oracle TDE, or a custom key store |
Default to KMS. Reach for CloudHSM only when a requirement says you must exclusively control the keys / meet a mandate KMS's shared model doesn't satisfy.
Secrets vs parameters vs certificates¶
| Need | Service | Key points |
|---|---|---|
| DB passwords, API keys with automatic rotation | AWS Secrets Manager | Built-in scheduled rotation (native for RDS/Redshift/DocumentDB via Lambda); encrypted with KMS; per-secret cost |
| Config values, and secrets without built-in rotation | SSM Parameter Store | Free standard tier; SecureString encrypts with KMS; hierarchical paths; no native rotation |
| Public TLS/SSL certificates | AWS Certificate Manager (ACM) | Free public certs, auto-renews them; deploy to ELB, CloudFront, API Gateway |
| Discover sensitive data (PII) in S3 | Amazon Macie | ML-based; finds and classifies PII/PHI in buckets |
ACM gotchas the exam loves:
- ACM public certs integrate directly with ELB, CloudFront, API Gateway — the standard, auto-renewing, free path. Historically you couldn't put an ACM public cert on a raw EC2 instance (no private-key export); since June 2025 ACM also offers exportable public certificates (a paid option, ~$15/FQDN, 395-day validity) whose private key you can export for EC2/containers/on-prem. For the exam the default answer is still ELB/CloudFront/API Gateway — just know exportable certs now exist for EC2/hybrid.
- A CloudFront distribution's certificate must be in us-east-1 (N. Virginia), regardless of where your origin lives. ACM certs are otherwise Regional.
Encrypting storage — the mechanics¶
| Service | Options |
|---|---|
| S3 | SSE-S3 (AES-256, AWS-managed keys — the default applied to all new objects); SSE-KMS (KMS key → adds audit trail + access control, but each op calls KMS); SSE-C (you supply the key per request); client-side (encrypt before upload) |
| EBS | KMS-based; encrypts the volume, its snapshots, and data in transit between instance and volume. Turn on "encryption by default" per Region/account |
| RDS | KMS at creation; encrypts data, snapshots, replicas, backups |
Two mechanics that appear as answers repeatedly:
- You cannot toggle encryption on an existing unencrypted EBS volume or RDS instance. The path is snapshot → copy the snapshot with encryption enabled → create the new volume / restore the DB from the encrypted copy, then cut over.
- S3 Bucket Keys cut SSE-KMS cost/throttling by generating a short-lived bucket-level key so S3 doesn't call KMS on every single object operation. If a scenario mentions high S3 request volume and KMS throttling/cost with SSE-KMS → enable S3 Bucket Keys.
To enforce encryption, use a policy, not a checkbox: e.g. an S3 bucket policy that denies
s3:PutObject when the request lacks the expected encryption header.
Worked example — why the IAM policy "isn't working" for KMS¶
An admin gives user maria an IAM policy allowing kms:Decrypt on a specific customer managed key.
She still gets AccessDenied. The key policy was custom-written and contains only a statement letting
the key administrators manage the key — it does not include the default statement delegating to
arn:aws:iam::<acct>:root.
Why is she denied, and what's the fix?
Answer
KMS access starts from the key policy. Because this key policy never delegates authority to the
account root, IAM policies in the account have no effect on the key — so Maria's kms:Decrypt
grant is inert. Fix: add a statement to the key policy that either allows Maria directly, or
delegates to the account ("Principal": {"AWS": "arn:aws:iam::<acct>:root"}) so her IAM policy
takes effect. This is the opposite of S3, where an IAM policy alone can grant access — for KMS the
key policy must open the door first.
Exam traps¶
- KMS keys only encrypt ≤ 4 KB directly — bulk data uses envelope encryption with data keys.
- KMS access = key policy first. An IAM
kms:*grant does nothing unless the key policy delegates to the account or names the principal. - Can't encrypt an existing unencrypted EBS/RDS in place → snapshot, copy-with-encryption, restore.
- SSE-KMS at high request volume can throttle / cost more → S3 Bucket Keys.
- CloudFront certs must live in us-east-1; ACM public certs deploy to ELB/CloudFront/API Gateway (exportable-to-EC2 certs exist since 2025 but are the exception).
- Secrets Manager rotates; Parameter Store (standard) does not — "automatic rotation" is the tell for Secrets Manager.
- Key deletion has a 7–30 day (default 30) waiting period — prefer disable; you can't delete AWS managed/owned keys.
- CloudHSM = single-tenant, you own the keys (TDE, strict mandates); KMS is the default otherwise.
Practice questions¶
Q1. An application must store a database password and rotate it automatically every 30 days without code changes to fetch the new value. Which service?
- A. Systems Manager Parameter Store (standard
SecureString) - B. AWS Secrets Manager
- C. AWS KMS
- D. AWS Certificate Manager
Answer: B
B. Secrets Manager provides built-in scheduled rotation (native for RDS and other databases) and apps retrieve the current value by name. Parameter Store standard parameters have no native rotation. KMS manages keys, ACM manages certificates.
Q2. A company has an existing unencrypted Amazon RDS instance and now must encrypt its data at rest with a KMS key. What is the correct approach?
- A. Enable the "encryption at rest" option on the running instance.
- B. Take a snapshot, copy the snapshot with encryption enabled, and restore a new instance from the encrypted copy.
- C. Enable Multi-AZ, which encrypts the standby.
- D. Attach a KMS key to the instance's parameter group.
Answer: B
B. Encryption can't be enabled on an existing unencrypted RDS instance in place. Snapshot → copy snapshot with a KMS key (the copy is encrypted) → restore a new encrypted instance → cut over. A isn't possible; Multi-AZ is about availability; parameter groups don't control encryption.
Q3. A high-traffic application writes millions of objects per hour to S3 using SSE-KMS and is now hitting KMS request throttling and rising KMS costs. What reduces this with the least change?
- A. Switch to SSE-C and manage keys in the app.
- B. Enable S3 Bucket Keys on the bucket.
- C. Disable encryption on the bucket.
- D. Move the objects to a new bucket in another Region.
Answer: B
B. S3 Bucket Keys generate a bucket-level key so S3 doesn't call KMS for every object, cutting KMS API calls, throttling, and cost while keeping SSE-KMS. SSE-C pushes key management to the app (more work, more risk); disabling encryption fails compliance; a new Region doesn't address KMS call volume.
Q4. A regulated customer requires that encryption keys be stored in single-tenant, dedicated hardware that they fully control, and that AWS operators cannot access the key material. Which service meets this?
- A. AWS KMS with an AWS managed key
- B. AWS KMS with a customer managed key
- C. AWS CloudHSM
- D. AWS Secrets Manager
Answer: C
C. CloudHSM provides single-tenant, dedicated FIPS 140-2 Level 3 HSMs where you exclusively control the keys and AWS cannot access them. KMS (A, B) is multi-tenant and AWS-operated even for customer managed keys. Secrets Manager stores secrets, not HSM-controlled keys.
Q5. A user has an IAM policy allowing kms:Decrypt on a customer managed key, but calls fail with
AccessDenied. The key's policy does not reference the user or delegate to the account root. What is
the cause?
- A. KMS keys can only be used by the root user.
- B. The key policy is the root of KMS access; without delegating to the account or naming the user, the IAM policy has no effect.
- C.
kms:Decryptmust be granted in an SCP. - D. The key needs automatic rotation enabled first.
Answer: B
B. For KMS, the key policy governs access first. Unless it delegates to the account
(iam::<acct>:root) or explicitly allows the principal, IAM policies can't grant use of the key.
Fix the key policy. Rotation, SCPs, and root-only use are unrelated to this failure.
Next: 3 · Network & Infrastructure Security → · Revise — Data Protection