Exams / SAP-C03 / Study guide / Encryption at rest, key policies and post-quantum cryptography (AWS KMS)
Encryption at rest, key policies and post-quantum cryptography (AWS KMS): SAP-C03 study notes and practice questions
What to know about Encryption at rest, key policies and post-quantum cryptography (AWS KMS) for the SAP-C03 exam, from the Security, Compliance, and Governance domain (25% of the exam guide), then 2 free questions to test it. Part of the SAP-C03 study guide.
These questions ask which key type and key setup meets a control requirement: who can use the key, who manages its material, how often it rotates, and where it lives.
Key types and control
AWS owned keys are invisible to you. AWS managed keys (aws/s3, aws/ebs) appear in your account but you can’t change their policy or share them across accounts.
Customer managed keys give full control: key policy, grants, enable and disable, rotation, scheduled deletion (7 to 30 day waiting period), and cross-account use. Pick them whenever the scenario mentions audit of key use, separation of duties, cross-account sharing or revoking access by disabling a key.
The key policy is the primary control. IAM policies work only if the key policy allows the account to delegate to IAM.
Grants give temporary, programmatic use to a service or principal; services such as EBS use them.
Conditions such as kms:ViaService and encryption context narrow use; encryption context also appears in CloudTrail.
Rotation and key material
Automatic rotation for symmetric customer managed keys with KMS-generated material. The default period is 365 days and you can set a custom period (90 to 2,560 days). Old material is kept, so existing data still decrypts and nothing is re-encrypted.
On-demand rotation rotates immediately, including keys with imported material.
Asymmetric keys, HMAC keys and keys in custom key stores rotate manually (new key, update the alias).
Imported key material (BYOK) for rules that require you to generate keys. CloudHSM custom key stores keep material in your own single-tenant HSM cluster. External key stores (XKS) keep material in an HSM outside AWS for “keys must never be in AWS” rules.
Patterns the exam likes
Multi-Region keys share key material and key ID across Regions, so data encrypted in one Region decrypts in another without a cross-Region call. Use for DR copies and global tables; not needed for most single-Region workloads.
S3 Bucket Keys cut KMS request volume and cost for SSE-KMS.
Per-tenant keys for SaaS isolation, chosen through tags or encryption context.
Encrypted snapshots and AMIs shared across accounts need a customer managed key that the other account can use.
Post-quantum cryptography
KMS endpoints support hybrid post-quantum TLS (ECDH combined with ML-KEM, for example X25519MLKEM768) when the SDK’s client enables it. CloudTrail’s tlsDetails.keyExchange field shows what each call used.
ML-DSA asymmetric keys (ML_DSA_44, ML_DSA_65, ML_DSA_87) sign and verify, for example to sign code or documents that must stay trustworthy for decades.
ML-KEM keys (ML_KEM_512, ML_KEM_768, ML_KEM_1024) encapsulate and decapsulate shared secrets.
Symmetric data keys (AES-256-GCM) are already considered quantum resistant; the risk is “harvest now, decrypt later” on key exchange in transit.
How to choose
Scenario wording
Pick
Audit and control who uses the key, share across accounts
Customer managed key
Rotate yearly with no re-encryption
Automatic rotation
Key material must be generated and held by us
Imported material, CloudHSM key store or XKS
Decrypt replicated data in a DR Region
Multi-Region key
Signatures that resist quantum attacks
ML-DSA key in KMS
Common traps
AWS managed keys for cross-account sharing.
Re-encrypting data after rotation. KMS keeps old material.
Expecting automatic rotation on asymmetric or imported keys.
Multi-Region keys for data residency; they deliberately copy key material to other Regions.
A car maker signs its vehicle firmware images with AWS KMS asymmetric keys. Each vehicle verifies the signature before installing an update, and a vehicle stays on the road for about 15 years.
The security team wants the signing keys to remain secure against future quantum computers, so a firmware image signed today must still be trustworthy when a vehicle reads it in 2040. The signing service must keep using KMS in the company's account, and the team does not want to build its own signing service.
Which solution meets these requirements?
Choose one answer.
AA. Create a KMS signing key with an RSA 4096-bit key spec, and replace it with a new key every year so that a compromised key is retired quickly.
BB. Create an ECC_NIST_P521 signing key, the largest elliptic-curve key spec that KMS offers, and sign each firmware image with ECDSA and SHA-512.
CC. Create a KMS asymmetric signing key with an ML-DSA key spec, and sign each firmware image through the KMS Sign API, using the external mu message type for large images.
DD. Move the firmware signing into an AWS CloudHSM cluster with an RSA key, and let the build servers call the HSM directly.
Show the answer and explanation
Answer: C
A. Wrong: RSA is a classical algorithm at any key size, so yearly replacement does not make the signatures resistant to a future quantum attacker. KMS also does not rotate asymmetric keys automatically, so the replacement would be manual work.
B. Wrong: A larger curve is still a classical algorithm, and a large enough quantum computer could break elliptic-curve signatures whatever the curve size. The option does not meet the quantum-resistance requirement.
C. Right: Correct. KMS supports ML-DSA post-quantum signing keys (ML_DSA_44, ML_DSA_65 and ML_DSA_87), so the signatures do not rely on algorithms that a future quantum computer could break. The images are signed through the KMS Sign API in the company's account, with no custom signing service.
D. Wrong: CloudHSM gives dedicated hardware, but an RSA key inside it is still a classical algorithm. The option also requires the team to manage the HSM client and signing integration.
Explanation
KMS supports post-quantum signing with ML-DSA key specs, which keeps the signing in KMS and protects signatures over the long vehicle lifetime. RSA and elliptic-curve keys are classical at any size, and an RSA key in CloudHSM leaves KMS and still uses a classical algorithm.
A retailer's backup tool writes nightly dump files of its 4 TB order database and encrypts them on the client side with the AWS Encryption SDK, using a customer managed KMS key in eu-west-1. The files are copied to an S3 bucket in eu-central-1 for disaster recovery.
During a recovery, the team must decrypt the files in eu-central-1 with no dependency on the eu-west-1 Region. The team does not want a job that decrypts and re-encrypts the files, and key rotation in eu-west-1 must also apply to the key used in eu-central-1.
Which solution meets these requirements?
Choose one answer.
AA. Keep the single-Region key in eu-west-1, and have the recovery process in eu-central-1 call KMS in eu-west-1 to decrypt the data keys of the dump files.
BB. Create a separate single-Region key in eu-central-1, and have a nightly job decrypt each copied file with the eu-west-1 key and re-encrypt it with the eu-central-1 key.
CC. Create a multi-Region primary key in eu-west-1 and a replica key in eu-central-1, encrypt the dump files with the primary key, and decrypt them with the replica during a recovery.
DD. Write a second, unencrypted copy of each dump file to the eu-central-1 bucket, and rely on the bucket's default SSE-S3 encryption so that the recovery needs no KMS key at all.
Show the answer and explanation
Answer: C
A. Wrong: The recovery depends on the KMS endpoint in eu-west-1, which fails when eu-west-1 is the Region that went down. This is the dependency the team wants to remove.
B. Wrong: This removes the recovery-time dependency, but it is the decrypt and re-encrypt job the team wants to avoid. The two keys are also unrelated, so rotating one does not rotate the other.
C. Right: Correct. Related multi-Region keys share the same key material and key ID, so the replica in eu-central-1 can decrypt ciphertext produced with the primary without calling eu-west-1. Rotating the primary key also rotates the key material of its replicas.
D. Wrong: S3 still encrypts the copy at rest, but the backup data leaves the customer managed key and its key policy. The extra copy process also adds work and drops the key control the team relies on.
Explanation
Multi-Region KMS keys let a replica in the recovery Region decrypt ciphertext from the primary with no cross-Region call, and rotation of the primary carries to the replica. A single-Region key keeps the dependency, a re-encryption job is ruled out, and an SSE-S3 copy gives up the customer managed key.
Want more on Encryption at rest, key policies and post-quantum cryptography (AWS KMS)? The 5 full-length practice sets have 10 more Encryption at rest, key policies and post-quantum cryptography (AWS KMS) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Encryption at rest, key policies and post-quantum cryptography (AWS KMS)