Encryption & Key Management Bundle

AWS KMS, AWS CloudHSM, AWS Secrets Manager, and AWS Certificate Manager — four services that protect data and credentials, but at completely different layers: encryption keys, dedicated hardware control, application secrets, and TLS certificates. The exam tests whether you know which layer a requirement actually lives at, and the post-quantum transition now underway across all four is the freshest material in this domain.

Data Protection — primary role Preventive — encryption at rest/in transit Compliance — FIPS 140-3
FIPS 140-3 L3
KMS & CloudHSM HSM validation
198 days
ACM public cert validity (since Mar 2026)
ML-KEM
Post-quantum TLS, KMS/ACM/Secrets Manager
Multi-tenant
KMS vs single-tenant CloudHSM

The Core Mental Model — Match the Protection Layer

Four Tools, Four Different Jobs
⚠️ The Recurring Exam Theme

Questions in this domain almost always test: (1) KMS vs CloudHSM — multi-tenant managed service vs dedicated single-tenant hardware you directly control, (2) Secrets Manager vs KMS vs Parameter Store — credentials/rotation vs raw encryption keys vs simple config values, (3) ACM vs ACM Private CA — public internet-trusted certs vs internal PKI, and increasingly (4) the post-quantum cryptography rollout (ML-KEM for TLS key agreement, ML-DSA for digital signatures) now spanning KMS, ACM, and Secrets Manager.

Exam Domain Mapping

DomainWhere This Bundle Shows Up
Data ProtectionThe centerpiece — encryption at rest/in transit, key policies, rotation, post-quantum migration
Identity & Access ManagementKMS key policies vs IAM policies vs grants, cross-account key sharing
Infrastructure SecurityACM certificate deployment to ALB/CloudFront, mTLS via CloudHSM
Management & Security GovernanceCompliance-driven HSM requirements (PCI-DSS, FIPS), centralized secret rotation policy

Decision Tree — Mental Model

Threat

Unencrypted data at rest/in transit; long-lived application credentials with no rotation; expired or self-signed certificates; compliance requirements demanding direct HSM control; harvest-now-decrypt-later quantum risk

↓
Security Goal

Encrypt data with appropriately-controlled keys, rotate credentials automatically, keep certificates valid and trusted, and begin transitioning to post-quantum-safe cryptography

↓
AWS Service

The Encryption & Key Management Bundle

KMS — managed encryption keys CloudHSM — dedicated hardware control Secrets Manager — credentials + rotation ACM — TLS certificates
↓
Implementation

Default to KMS customer-managed keys for most encryption needs; CloudHSM only when direct hardware control is mandated; Secrets Manager for any rotating credential; ACM for any AWS-integrated TLS endpoint.

↓
Monitoring

CloudTrail records every KMS API call (Encrypt/Decrypt/GenerateDataKey); Secrets Manager Audit traces who can access a given secret across accounts; ACM tracks certificate expiry/renewal status.

↓
Remediation

Rotate compromised keys/secrets, revoke and reissue certificates, update key policies to remove excessive grants, migrate deprecated HSM instance types before forced end-of-support dates.

Final Summary

Must Memorize
  • KMS = multi-tenant managed service; CloudHSM = single-tenant, customer-controlled dedicated hardware
  • Custom key stores (CloudHSM-backed or External Key Store/XKS) do NOT support multi-Region keys
  • ACM public certificates now have a max 198-day validity (since March 2026, CA/Browser Forum mandate)
  • Secrets Manager = credentials + automatic rotation; KMS = raw encryption keys; Parameter Store = simple config values
  • ML-KEM (post-quantum TLS key agreement) now supported by KMS, ACM, and Secrets Manager endpoints; ML-DSA (post-quantum signatures) supported by KMS and ACM Private CA
Must Understand
  • Why CloudHSM exists even though KMS already provides FIPS 140-3 Level 3 HSMs — it's about WHO controls the hardware, not validation level
  • Multi-Region KMS keys are independent keys with the SAME key material, not a single replicated key — each has its own key policy/grants by default
  • The hsm1.medium → hsm2m.medium forced migration as a real operational/compliance deadline
  • The distinction triangle: KMS (managed keys) vs CloudHSM (dedicated hardware) vs Secrets Manager (credentials)
Can De-prioritize
  • Exact dollar pricing per key/HSM-hour
  • Console UI navigation specifics
  • Full cryptographic detail of ML-KEM/ML-DSA algorithms — know they exist and what problem they solve, not the math

Exam appearance probability: HIGH

Core Services — Deep Dive

AWS KMS — Core Concepts The default encryption key service
ArchitectureMulti-tenant FIPS 140-3 Level 3 validated HSMs, operated by AWS but never giving AWS cryptographic access to your key material
Key typesAWS-owned keys (free, no visibility), AWS-managed keys (per-service, free, automatic rotation), customer-managed keys (full control over policy/rotation/deletion)
AuthorizationKey policies (resource-based, attached to the key — the ONLY way to grant cross-account key access) combined with IAM policies and/or Grants (temporary, programmatic permission delegation)
Envelope encryptionKMS generates a data key, encrypts your data locally with it, then encrypts (wraps) that data key with the KMS key — your actual data never leaves your environment to reach KMS
  • Custom key stores let you back a KMS key with key material that lives outside KMS's own default HSM fleet — either a CloudHSM cluster you own (CloudHSM key store) or an External Key Store (XKS) you operate entirely outside AWS facilities.
  • Automatic key rotation (for KMS-native key material) rotates the underlying cryptographic material yearly while keeping the same key ID/ARN — your applications never need to change anything.
  • Recent additions: on-demand rotation of symmetric multi-Region keys WITH IMPORTED key material (Nov 2025) — previously a gap, since automatic rotation has never applied to imported key material; new keyExchange field in CloudTrail TLS details (Nov 2025); new ECC_NIST_EDWARDS25519 key spec (Nov 2025); dual-stack (IPv6) endpoint support (June 2025).
KMS Multi-Region Keys High-trap
What it doesReplicates a KMS key from one Region (the "primary") into one or more other Regions (the "replicas") — each replica is an independent key with the SAME key material and key ID, but its own key policy and grants by default
Use caseLets you encrypt in one Region and decrypt in another WITHOUT a cross-Region API call — e.g. client-side encrypted data replicated for DR, DynamoDB Global Tables, cross-Region digital signature verification
Primary key changesYou can promote a replica to become the new primary via UpdatePrimaryRegion — this changes no key ARNs or shared key material, just which Region is authoritative for shared properties going forward
  • Critical limitation: custom key stores do NOT support multi-Region keys at all — you cannot create a multi-Region key backed by a CloudHSM key store or an External Key Store. This is one of the most specific, frequently-tested limitations in the whole KMS domain.
  • Multi-Region keys are NOT a substitute for understanding that most AWS services treat them as single-Region keys for their own internal encryption-at-rest purposes — they re-wrap/re-encrypt data moved between Regions rather than leveraging true multi-Region behavior. The multi-Region benefit is primarily for client-side encryption and specific supported integration patterns (e.g. DynamoDB Global Tables), not a blanket guarantee across every AWS service.
AWS CloudHSM Single-tenant, customer-controlled hardware
ArchitectureDedicated, single-tenant HSMs — general purpose, standards-compliant, FIPS 140-3 Level 3 validated when run in FIPS mode (non-FIPS mode also available for use cases outside those restrictions)
Control modelYOU directly administer the HSM — not even AWS can access your key material; this is the core differentiator from KMS, which is AWS-operated (though still without AWS cryptographic access)
Production deploymentAWS recommends at least 2 HSMs across 2 AZs for production; at least 3 HSMs across at least 2 AZs for mission-critical workloads — the client transparently load-balances and handles HSM failures
Instance migrationhsm1.medium reached end of support March 31, 2026 — its CMVP certificate moved to the historical list January 4, 2026. Customers must migrate to hsm2m.medium, which offers improved performance, higher key capacity, and mTLS support for client-to-cluster communication
  • Cross-Region cluster cloning (documented April 2026): use CopyBackupToRegion to copy a cluster backup to another Region, then create a new cluster from that backup — including non-exportable keys. Critically, clusters do NOT auto-sync after cloning: any keys/users created after the clone must be manually replicated to both clusters going forward.
  • Use cases: workloads requiring direct HSM control for compliance (PCI-DSS, PCI-PIN, PCI-3DS), cryptographic operations/algorithms not natively supported by KMS, or as the backing key store for a KMS custom key store.
  • "We need full administrative control over the physical HSM and must be able to prove AWS cannot access our keys under any circumstance" → CloudHSM, not KMS (even though KMS already uses FIPS 140-3 Level 3 hardware and never has cryptographic access either — the exam distinction is about direct customer ADMINISTRATION of the device, not just key confidentiality).
AWS Secrets Manager Credentials, not raw encryption keys
What it storesDatabase credentials, API keys, OAuth tokens, SSH keys, and other application secrets — anything an application needs to authenticate to another system
RotationConfigurable automatic rotation schedule using pre-built or custom Lambda functions — native rotation support for RDS, Redshift, and DocumentDB
EncryptionEvery secret is encrypted using a KMS key — Secrets Manager itself doesn't replace KMS, it builds on top of it
Recent rename (2026)"Secrets Manager Agent" was renamed to "Workload Credentials Provider" — same underlying capability (local credential caching/retrieval for workloads), new name
  • AWS's own guidance steers OTHER secret types elsewhere: AWS credentials → IAM; encryption keys → KMS; SSH keys → EC2 Instance Connect; private keys/certificates → ACM. Secrets Manager is specifically for the credential-rotation use case, not a catch-all secret vault for everything.
  • "Rotate an RDS master password automatically every 30 days without application downtime" → Secrets Manager automatic rotation, the textbook use case.
  • Secrets Manager Audit (newer capability) resolves and reports exactly WHO can access a given secret — across accounts, through Identity Center, down to the specific human behind an IAM role — in a single command, addressing a historically hard cross-account secret-access visibility gap.
AWS Certificate Manager (ACM) High — validity period change, March 2026
What it doesProvisions, deploys, and auto-renews public and private TLS/SSL certificates for AWS-integrated services (ALB, CloudFront, API Gateway, and others)
Public certificate validityReduced from 398 days to 198 days, effective with the CA/Browser Forum mandate of March 15, 2026 — no customer action required, this happens automatically
Renewal windowNew 198-day certificates auto-renew 45 days before expiry (previously 60 days for the older 398-day certificates)
Legacy certificatesExisting 395/398-day certificates remain valid until their own renewal/expiry — they don't get retroactively shortened
  • ACM-issued certificates CANNOT be exported — by design, the private key never leaves AWS, which is why ACM certificates only work with AWS-integrated services rather than being usable on arbitrary external servers.
  • ACM Private CA is the answer when you need to issue PRIVATE certificates for internal-only use cases (internal mTLS, IoT device identity, internal service-to-service trust) — separate from public ACM, which only issues publicly-trusted certificates.
  • ACM Private CA now also supports ML-DSA post-quantum signatures, following KMS's earlier ML-DSA rollout.
  • "Our public-facing website's certificate needs to auto-renew without any manual intervention" → ACM. "We need an internal CA to issue certificates for service-to-service mTLS that should never be publicly trusted" → ACM Private CA.
Post-Quantum Cryptography Rollout High — exam-fresh across all four services
The threat model"Harvest now, decrypt later" (HNDL) — an adversary captures encrypted TLS traffic today, planning to decrypt it once sufficiently powerful quantum computers exist in the future
ML-KEMModule-Lattice-Based Key-Encapsulation Mechanism — the new NIST-standardized post-quantum algorithm for hybrid key AGREEMENT in TLS. Now supported by KMS, ACM, and Secrets Manager endpoints (non-FIPS endpoints) for hybrid post-quantum TLS
ML-DSAModule-Lattice Digital Signature Algorithm — the new NIST-standardized post-quantum algorithm for digital SIGNATURES. Supported by KMS (June 2025) and ACM Private CA
Workload Credentials ProviderSecrets Manager clients should be upgraded to use hybrid post-quantum TLS with ML-KEM to protect secrets specifically against HNDL attacks — verifiable via CloudTrail
  • Key distinction: ML-KEM protects the TLS CONNECTION (key agreement/exchange) against future decryption; ML-DSA protects SIGNATURES (proving authenticity/integrity) against future forgery. They solve different halves of the post-quantum problem.
  • "Harvest now, decrypt later" specifically motivates upgrading TLS key agreement NOW, even though the quantum threat to AES symmetric encryption itself is considered much further off — the urgency is about traffic being captured today for future decryption, not about an imminent break of current algorithms.
  • AWS-LC FIPS 3.0 became the first cryptographic library to include ML-KEM within an in-process FIPS 140-3 validation, signaling AWS's broader infrastructure-wide post-quantum direction.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

Encrypt data at rest for a typical AWS-managed resource (S3, EBS, RDS)
encryption at restmanaged key
Expected Answer

AWS KMS (customer-managed key)

DistractorWhy it's wrong
CloudHSMOverkill — requires you to directly administer hardware for a need KMS's managed service already satisfies natively across nearly every AWS service
Secrets ManagerManages credentials, not raw resource encryption keys
A compliance mandate requires the customer to directly administer the HSM, with proof AWS cannot access key material under any circumstance
direct HSM controlsingle-tenantPCI-DSS
Expected Answer

AWS CloudHSM

DistractorWhy it's wrong
AWS KMS (even with FIPS 140-3 Level 3 hardware)AWS still operationally manages the HSM fleet in KMS — the distinguishing factor here is direct CUSTOMER administration, which only CloudHSM provides
Rotate an RDS database master password automatically on a schedule without app downtime
rotate credentialsdatabase password
Expected Answer

AWS Secrets Manager (automatic rotation via Lambda)

DistractorWhy it's wrong
AWS Systems Manager Parameter StoreNo native automatic rotation mechanism — Secrets Manager is purpose-built for exactly this
AWS KMSManages encryption keys, not application-level credentials/rotation workflows
Auto-renew a public TLS certificate for a CloudFront distribution with zero manual steps
public TLS certificateauto-renewCloudFront
Expected Answer

AWS Certificate Manager (ACM)

DistractorWhy it's wrong
ACM Private CAIssues PRIVATE, not publicly-trusted certificates — wrong tool for a public-facing CloudFront distribution
Secrets Manager storing a manually obtained certWorks as a storage mechanism but doesn't provide ACM's native auto-renewal/deployment integration
Issue internal-only certificates for service-to-service mTLS that should never be publicly trusted
internal mTLSprivate PKI
Expected Answer

ACM Private CA

DistractorWhy it's wrong
Public ACMOnly issues publicly-trusted certificates from a public CA chain — not designed for internal-only PKI
Protect TLS traffic today against future quantum-computer decryption of captured data ("harvest now, decrypt later")
harvest now decrypt laterpost-quantumfuture-proof
Expected Answer

Upgrade to hybrid post-quantum TLS with ML-KEM (supported on KMS, ACM, Secrets Manager endpoints)

DistractorWhy it's wrong
Simply increasing AES key lengthDoesn't address the actual vulnerable component — classical TLS key AGREEMENT (e.g. ECDHE), not the symmetric cipher itself, is what's at risk from a future quantum computer
ML-DSA aloneProtects signatures/authenticity, not the key-agreement step that HNDL attacks specifically target

Integrations

Nearly every AWS service (S3, EBS, RDS, DynamoDB, Lambda, etc.)
WhatNative encryption-at-rest integration with KMS customer-managed or AWS-managed keys
Amazon RDS / Redshift / DocumentDB
WhatNative, pre-built Secrets Manager rotation Lambda functions for these specific database engines
Elastic Load Balancer / CloudFront / API Gateway
WhatACM certificates deploy directly to these services, with automatic renewal requiring no manual reinstallation
AWS CloudTrail
WhatRecords every KMS API call (audit trail for key usage); also now captures the new keyExchange field in TLS details, useful for verifying post-quantum/ML-KEM connection usage
Amazon EKS / Kubernetes Secrets Store CSI Driver
WhatThe AWS provider for the Secrets Store CSI Driver fetches secrets from Secrets Manager (and parameters from Systems Manager Parameter Store) and mounts them as files in Kubernetes pods
IAM Identity Center
WhatSecrets Manager Audit traces secret access down to the specific human behind an IAM role, including access routed through Identity Center

Costs, Limits & Quotas

Pricing Model

KMSMonthly charge per customer-managed key, plus a per-request charge for cryptographic operations beyond the free tier; AWS-managed and AWS-owned keys have no direct charge
CloudHSMHourly charge per HSM instance — meaningfully more expensive than KMS, reflecting the dedicated, single-tenant hardware model
Secrets ManagerMonthly charge per secret stored, plus a per-API-call charge for retrieval
ACM (public)Free for certificates used with AWS-integrated services; ACM Private CA has its own separate monthly + per-certificate pricing

Common Cost Mistakes

Cost Optimization

Limits & Quotas

Multi-Region keys + custom key storesNOT supported together — you cannot create a multi-Region key backed by a CloudHSM key store or External Key Store
ACM public cert validityMaximum 198 days as of March 15, 2026 (down from 395/398 days)
CloudHSM hsm1.mediumEnd of support March 31, 2026 — CMVP certificate already moved to historical list January 4, 2026
CloudHSM cross-Region backupCannot copy backups across partitions (e.g. standard Regions ↔ GovCloud, China Region, or the AWS European Sovereign Cloud)
⚠️ Exam trap

Cloning a CloudHSM cluster cross-Region via CopyBackupToRegion does NOT create an ongoing sync relationship — any keys or users created after the clone must be manually replicated to keep both clusters consistent. This is a one-time snapshot copy, not continuous replication.

Best Practices & Common Exam Traps

8 — Best Practices

Must Know
  • KMS = multi-tenant managed; CloudHSM = single-tenant, customer-administered
  • Custom key stores (CloudHSM-backed or XKS) don't support multi-Region keys
  • ACM public cert validity is now 198 days max (March 2026+)
  • Secrets Manager ≠ KMS ≠ Parameter Store — credentials/rotation vs raw keys vs simple config
  • ML-KEM (TLS key agreement) and ML-DSA (signatures) are the two post-quantum building blocks now rolling out
Good Practice
  • Default to KMS customer-managed keys; reserve CloudHSM for genuine direct-control compliance needs
  • Enable automatic rotation on every Secrets Manager secret that supports it
  • Migrate any remaining hsm1.medium clusters to hsm2m.medium before the deadline
  • Upgrade clients to hybrid post-quantum TLS (ML-KEM) proactively against harvest-now-decrypt-later risk
Advanced Practice
  • Use Secrets Manager Audit to trace cross-account secret access down to the individual human, including Identity Center-routed access
  • Use CloudHSM cross-Region cluster cloning for DR, with a manual process to keep post-clone keys/users in sync
  • Use ACM Private CA with ML-DSA post-quantum signatures for internal PKI requiring future-proofed authenticity guarantees

9 — Common Exam Traps

MisconceptionReality
"KMS and CloudHSM are basically the same thing at different price points"The real differentiator is WHO administers the hardware — KMS is AWS-operated (no AWS cryptographic access either way); CloudHSM is fully customer-administered
"Multi-Region KMS keys work with any key store type"False — custom key stores (CloudHSM-backed or External Key Store) explicitly do NOT support multi-Region keys
"ACM public certificates still get issued with ~1-year validity"Outdated since March 15, 2026 — new/renewed public certs now max out at 198 days per the CA/Browser Forum mandate
"Secrets Manager is just a general-purpose secret store for anything sensitive"AWS's own guidance routes other secret types elsewhere — IAM for AWS credentials, KMS for encryption keys, EC2 Instance Connect for SSH keys, ACM for certificates
"Cloning a CloudHSM cluster cross-Region keeps both clusters automatically synced going forward"False — it's a one-time backup copy; any keys/users created afterward must be manually replicated to both clusters

Lookalike Comparisons

ComparisonWhat actually differs
KMS vs CloudHSMAWS-operated, multi-tenant managed service vs customer-administered, single-tenant dedicated hardware — both can be FIPS 140-3 Level 3 validated
Secrets Manager vs Parameter StoreBuilt-in automatic rotation + native database integrations (paid) vs simple key-value config storage with no native rotation (often free/cheaper)
ACM vs ACM Private CAPublicly-trusted certificates for internet-facing endpoints vs privately-trusted certificates for internal PKI/mTLS that should never be publicly trusted
ML-KEM vs ML-DSAPost-quantum key AGREEMENT for TLS connections (protects against harvest-now-decrypt-later) vs post-quantum digital SIGNATURES (protects authenticity/integrity against future forgery)
KMS key policy vs IAM policy vs GrantResource-based policy attached to the key (required for cross-account access) vs identity-based policy on the principal vs temporary, programmatically-created permission delegation

Flashcards — 18 Cards

Click card to flip. Mark right or wrong to track score.

Click to reveal answer
1 / 18
Mark:   Score: 0/0

Practice Quiz — 9 Questions

SCS-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.

out of 9 correct