Data Protection Day 2

SCS-C03 · Domain 5 · Data Protection (18%) · Day 2 of 5

Key material, HSMs, multi-Region keys and certificates

Day 1 used keys that KMS creates. Today is about who makes and holds the key material: imported material, AWS CloudHSM, CloudHSM and external key stores. Then keys across Regions with multi-Region keys, and certificates with ACM and AWS Private CA.

Skill 5.3.2 imported material, external key storesSkill 5.3.3 imported vs AWS-generatedSkill 5.3.5 keys and certificates across Regions~90 min read + 30 min lab

Where key material comes from

Every KMS key has an origin: where its secret bits (the key material) were made and where they live. By default KMS generates them (AWS_KMS). You can instead bring your own (EXTERNAL, imported), or keep them in a CloudHSM cluster (AWS_CLOUDHSM) or outside AWS (EXTERNAL_KEY_STORE). Skill 5.3.3 asks you to describe the difference between imported and AWS-generated material, and the exam loves to ask which option meets a compliance sentence with the least effort.

Concept profile

Imported key material (EXTERNAL)

often confused with AWS-generated key material (AWS_KMS)

?What is it?

Key material you generate in your own system and import into a KMS key created with Origin=EXTERNAL. KMS uses a copy; you keep the original and stay responsible for it.

⚙How does it work?

Create a KMS key with no material (--origin EXTERNAL).
Download a wrapping public key and import token, wrap your material, import it.
Optionally set an expiration; KMS deletes the material when it expires.
Use the key normally: services and APIs can't tell the difference.

{ }Structure

From “AWS does everything” to “you do everything”.

⇄Imported material vs AWS-generated key material (AWS_KMS)

	Imported (EXTERNAL)	AWS-generated (AWS_KMS)
Who generates	You (your HSM / entropy source)	KMS HSMs
Durability	You must keep a copy	AWS (highly durable)
Delete instantly	Yes: delete material (reimport later)	No: 7–30 day scheduled deletion
Expiration date	Optional	Not available
Automatic rotation	No (on-demand rotation yes, single-Region symmetric keys only)	Yes, 90–2560 days
Decrypt outside AWS	No for symmetric ciphertext	No

!Common mistakes the exam tests

Thinking imported material is “more secure”. It's about control and provenance, not strength.
Losing your copy: if the material expires or is deleted and you have no copy, the data is gone.
Expecting to decrypt KMS ciphertext outside AWS with your copy of symmetric material. KMS ciphertext format doesn't allow it.
Choosing imported material when the requirement is “keys must never be stored in AWS” (that's XKS).

✓Benefits and use cases

Prove the key came from an approved entropy source.
Instant revocation by deleting material, with the option to restore.
Same asymmetric/HMAC keys inside and outside AWS.

Think of it like · baking bread

You can buy bread, bake it in the shop's oven, or bake at home.

AWS concept		Familiar thing
AWS_KMS origin	≈	The bakery makes the dough and bakes it for you
Imported material	≈	You bring your own dough, the bakery bakes it; you keep a spare batch
CloudHSM key store	≈	You rent a private oven inside the bakery
External key store	≈	Dough never leaves your house; the bakery phones you each time
Material expiration	≈	Your dough has a best-before date; then the bakery throws it out

Real AWS example · see a key's origin

DescribeKey shows the origin and, for imported keys, the expiration.

$ aws kms describe-key --key-id alias/byok-payments --query KeyMetadata
{ "KeyId": "0987dcba-09fe-87dc-65ba-ab0987654321",
  "Origin": "EXTERNAL",
  "KeyState": "Enabled",
  "ExpirationModel": "KEY_MATERIAL_EXPIRES",
  "ValidTo": "2027-01-01T00:00:00Z",
  "KeyManager": "CUSTOMER" }

ExpirationModel can also be KEY_MATERIAL_DOES_NOT_EXPIRE.

Exam-style scenario

A bank's policy says encryption key material must be generated by its own on-premises HSM, and the bank must be able to make the key unusable immediately and later restore it. It wants to keep using SSE-KMS with S3 and EBS with minimal changes. What should it use?

A. AWS managed keys.
B. A customer managed KMS key with imported key material (EXTERNAL origin), keeping the original in the on-prem HSM.
C. An external key store.
D. Client-side encryption with keys stored in Secrets Manager.

Show the worked answer

Answer: B

Imported material proves provenance, can be deleted at once (key goes to PendingImport) and reimported later, and works with all KMS-integrated services.

Why not the others

A: AWS generates and manages those.
C: Overkill: the requirement isn't that keys stay outside AWS, and it adds latency and availability risk.
D: Big app change and Secrets Manager isn't a key manager.

How the exam tests this

“Key material must come from our own HSM”→ Imported key material.
“Revoke instantly but recoverable”→ Delete imported material, reimport later.
“Least overhead, compliance not specified”→ AWS_KMS origin.
“Difference imported vs generated”→ Durability and expiration are yours; no auto-rotation.

Must remember

Origins: AWS_KMS · EXTERNAL · AWS_CLOUDHSM · EXTERNAL_KEY_STORE.
Imported = you keep the copy; optional expiration.
Imported: no automatic rotation (on-demand OK for single-Region symmetric keys; multi-Region imported keys = manual).
Not more secure, just more control.

Official sources: Importing key material Choosing a key store

Managing imported key material

Importing is a four-step ceremony, and afterwards the material has a life you manage: optional expiry, deletion, reimport and rotation. The exam usually tests what happens to the key and the data when the material disappears, and how you would notice before it does.

Concept profile

Deleting / expiring imported material

often confused with scheduling key deletion

?What is it?

Removing the key material from an EXTERNAL-origin key, either manually (DeleteImportedKeyMaterial) or automatically at its expiration time.

⚙How does it work?

The key state becomes PendingImport and the key can't be used.
Data keys already decrypted in memory keep working until they are needed from KMS again (e.g. EBS on next attach).
Reimport the same key material (new wrapping key and token) to make the key usable again.
Set a CloudWatch alarm on the SecondsUntilKeyMaterialExpiration metric to avoid surprise outages.

{ }Structure

Wrap, import, and keep your copy safe.

⇄Deleting imported material vs scheduling key deletion

	Delete imported material	ScheduleKeyDeletion
Effect	Key unusable now (PendingImport)	Key unusable now (PendingDeletion)
Waiting period	None	7–30 days
Undo	Reimport the same material	CancelKeyDeletion before the window ends
Key metadata	Kept (ID, policy, aliases)	Deleted at the end
Works on	EXTERNAL origin only	Any customer managed key

!Common mistakes the exam tests

Using a wrapping key or import token older than 24 hours: import fails.
Trying to import different material to restore a key: it must be the same (new material is only for on-demand rotation).
Forgetting the expiration date: production stops when the material expires.
Importing into a CloudHSM or external key store key: not supported.

✓Benefits and use cases

Emergency “kill switch” for data, reversible by the key owner.
Time-boxed keys for projects or contracts.
On-demand rotation by importing new material into the same key.

Think of it like · a spare house key with a timer

You lend the building a copy of your key that self-destructs on a date.

AWS concept		Familiar thing
Import token + wrapping key	≈	A sealed delivery envelope valid for 24 hours
ImportKeyMaterial	≈	Handing the copy to the building manager
Expiration	≈	The copy dissolves on a set date
PendingImport	≈	The door won't open until you bring the key again
Your original	≈	The master you keep at home: lose it and the door is locked forever

Real AWS example · import with expiration, then alarm

Wrap with RSAES_OAEP_SHA_256, import with a 1-year expiry, and alarm 30 days before it expires.

aws kms get-parameters-for-import --key-id 0987dcba-... \
  --wrapping-algorithm RSAES_OAEP_SHA_256 --wrapping-key-spec RSA_4096
# (wrap the 256-bit material with the returned public key using OpenSSL)
aws kms import-key-material --key-id 0987dcba-... \
  --encrypted-key-material fileb://EncryptedKeyMaterial.bin \
  --import-token fileb://ImportToken.bin \
  --expiration-model KEY_MATERIAL_EXPIRES --valid-to 2027-10-08T00:00:00Z

aws cloudwatch put-metric-alarm --alarm-name byok-expiry \
  --namespace AWS/KMS --metric-name SecondsUntilKeyMaterialExpiration \
  --dimensions Name=KeyId,Value=0987dcba-... --statistic Minimum \
  --period 86400 --evaluation-periods 1 --threshold 2592000 \
  --comparison-operator LessThanThreshold --alarm-actions arn:aws:sns:...:secops

2592000 seconds = 30 days.

Exam-style scenario

A company's imported key material expired over the weekend. On Monday, new EBS volumes can't be created and some RDS operations fail. The security team still has the original key material in its HSM. What restores service fastest with no data loss?

A. Create a new KMS key and re-encrypt everything.
B. Get a new wrapping key and import token, then reimport the same key material into the same KMS key (optionally with a later expiry or none).
C. Call CancelKeyDeletion.
D. Restore the volumes from snapshots.

Show the worked answer

Answer: B

Expired material puts the key in PendingImport. Reimporting the same material makes it Enabled again with the same key ID, so existing data decrypts.

Why not the others

A: Slow and unnecessary; old data can't be read without the old material anyway.
C: The key isn't pending deletion.
D: Snapshots are encrypted under the same key, so they fail too.

How the exam tests this

“Imported key stopped working on a date”→ Material expired → reimport same material.
“Avoid surprise expiry”→ Alarm on SecondsUntilKeyMaterialExpiration.
“Import fails after a day”→ Token/wrapping key valid 24 h.
“Rotate imported material”→ Import new material with --import-type NEW_KEY_MATERIAL, then RotateKeyOnDemand (single-Region symmetric keys; since June 2025).

Must remember

Delete/expire → PendingImport, no waiting period.
Restore = reimport the same material.
Wrapping key + import token: 24 hours.
Not available in custom key stores.

Official sources: Importing key material Delete imported material KMS CloudWatch metrics

AWS CloudHSM

AWS CloudHSM gives you your own hardware security modules in your VPC. They are single-tenant and FIPS 140 Level 3 validated (in FIPS mode). AWS runs the hardware, patching and backups, but you create the HSM users and keys, and AWS cannot see or use them. Apps talk to it through standard crypto libraries (PKCS #11, JCE, OpenSSL, KSP/CNG), not through the KMS API.

Concept profile

AWS CloudHSM

often confused with AWS KMS

?What is it?

Dedicated, single-tenant HSMs in a cluster in your VPC where you fully control the keys and the HSM users.

⚙How does it work?

Create a cluster, then add HSMs in different AZs for availability; keys sync across the cluster.
Initialize it: sign the cluster certificate, create the crypto officer (CO) and crypto users (CU).
Install the client SDK on your instances; apps use PKCS #11, JCE, OpenSSL or KSP/CNG.
AWS takes encrypted backups automatically; only your HSMs can decrypt them.

{ }Structure

Your HSMs, your users, your keys; AWS runs the boxes.

⇄AWS CloudHSM vs AWS KMS

	CloudHSM	KMS
Tenancy	Single-tenant HSMs	Multi-tenant, AWS-managed HSMs
Who manages users and keys	You (CO / CU, not IAM)	IAM + key policies
APIs	PKCS #11, JCE, OpenSSL, KSP/CNG	KMS API, integrated with 100+ services
Service integration	Only through a KMS CloudHSM key store	Native
Availability	You add HSMs across AZs	Managed, 99.999% SLA
Typical uses	TLS offload, Oracle TDE, PKI/CA keys, custom crypto	Encrypt AWS data with least effort

!Common mistakes the exam tests

Picking CloudHSM when the question says “least operational overhead”: that's KMS.
Running one HSM in production: no HA. Use at least two in different AZs.
Thinking IAM controls who can use keys inside the HSM. IAM controls the CloudHSM API (cluster management); HSM users control keys.
Losing the CO/CU credentials: AWS can't recover your keys.

✓Benefits and use cases

Regulations that demand single-tenant HSMs you control.
SSL/TLS offload for web servers, Oracle TDE, Microsoft SQL Server / AD CS.
Backing store for a KMS custom key store.

Think of it like · a bank safe vs a private vault

KMS is a safe-deposit box in a shared vault; CloudHSM is a vault room only you have the code to.

AWS concept		Familiar thing
KMS	≈	Box in a shared, bank-run vault
CloudHSM	≈	A private vault room rented from the bank
Crypto officer / crypto user	≈	The people on your own access list
AWS's role	≈	Guards the building and cleans it, can't open your room
Cluster in 2 AZs	≈	Two identical vault rooms in different buildings

Real AWS example · using CloudHSM from Java (JCE)

The application signs data with a key that never leaves the HSM.

// Add the CloudHSM JCE provider
Security.addProvider(new com.amazonaws.cloudhsm.jce.provider.CloudHsmProvider());
KeyStore ks = KeyStore.getInstance("CloudHSM");
ks.load(null, null);                      // login with CU credentials from env/config
PrivateKey key = (PrivateKey) ks.getKey("release-signing", null);
Signature sig = Signature.getInstance("SHA256withRSA", "CloudHSM");
sig.initSign(key);
sig.update(artifactBytes);
byte[] signature = sig.sign();

Standard Java crypto code: only the provider name changes.

Exam-style scenario

A payment processor must store its TLS private keys in single-tenant, FIPS 140 Level 3 HSMs under its exclusive control, and offload TLS operations from its NGINX web servers on EC2. Which service fits?

A. AWS KMS with a customer managed key.
B. AWS CloudHSM with the OpenSSL dynamic engine on the NGINX servers.
C. ACM public certificates on an ALB.
D. Secrets Manager.

Show the worked answer

Answer: B

CloudHSM gives single-tenant HSMs under customer control and supports SSL/TLS offload through OpenSSL for NGINX/Apache.

Why not the others

A: KMS is multi-tenant and doesn't do TLS offload for your servers.
C: ACM keys are AWS-controlled, not in your HSM.
D: Stores secrets, not an HSM.

How the exam tests this

“Single-tenant HSM, exclusive control”→ CloudHSM.
“PKCS #11 / JCE / Oracle TDE”→ CloudHSM.
“High availability for CloudHSM”→ ≥ 2 HSMs in different AZs.
“Least effort encryption for AWS services”→ KMS, not CloudHSM.

Must remember

CloudHSM = single-tenant, you manage users and keys.
Apps use PKCS #11, JCE, OpenSSL, KSP/CNG.
HA: HSMs in multiple AZs.
AWS can't access your keys or recover lost credentials.

Official sources: CloudHSM overview Use cases Clusters

Custom key stores: CloudHSM key store and external key store

A custom key store lets you keep the KMS API (and all its service integrations) while the key material lives in hardware you control. With a CloudHSM key store it lives in your CloudHSM cluster. With an external key store (XKS) it lives outside AWS entirely, reached through an XKS proxy you run. AWS's own advice: use these only when a regulation explicitly requires it, because they cost more, are slower, and have no SLA.

Concept profile

External key store (XKS)

often confused with CloudHSM key store

?What is it?

A KMS custom key store whose keys are in an external key manager outside AWS. KMS sends each request to your XKS proxy, which asks your key manager to encrypt or decrypt.

⚙How does it work?

Deploy an XKS proxy (public endpoint or VPC endpoint service) in front of your HSM / key manager.
Create the external key store in KMS with the proxy's URI and authentication credential.
Create KMS keys with Origin=EXTERNAL_KEY_STORE, each mapped to an external key ID.
Data is double encrypted: first by KMS key material in AWS, then by your external key.
If your proxy or key manager is down, every encrypt/decrypt with those keys fails.

{ }Structure

Same KMS API, very different responsibility.

⇄External key store vs CloudHSM key store

	External key store	CloudHSM key store
Key material lives	Outside AWS	Your CloudHSM cluster in AWS
Network path	Leaves AWS (via XKS proxy)	Stays inside AWS
Requirement it meets	“Keys must never be in AWS” / hold your own key	“Single-tenant HSM under our control”
Setup	XKS proxy + external key manager	Cluster with ≥ 2 active HSMs in different AZs, `kmsuser` CU
Performance / SLA	Lowest TPS, highest latency, no SLA	Low TPS, no SLA
AWS preference	Last resort	Preferred over XKS

!Common mistakes the exam tests

Using a custom key store for high-volume S3 or DynamoDB workloads: AWS says only low-TPS uses like EBS or RDS.
Expecting asymmetric, HMAC, multi-Region, imported material or automatic rotation in custom key stores: symmetric only, manual rotation.
Forgetting availability is yours: a disconnected key store or offline proxy breaks every dependent service.
Choosing XKS when imported material would meet the requirement with far less risk.

✓Benefits and use cases

Sovereignty rules that forbid key material in the cloud provider.
Ability to cut off AWS's access to your data instantly by blocking the proxy.
Regulated workloads needing single-tenant HSMs with KMS integration.

Think of it like · keeping the house key at home

A courier (KMS) must phone you every time they need to open your shop.

AWS concept		Familiar thing
Standard KMS	≈	The landlord keeps your key in their safe
CloudHSM key store	≈	Your own lockbox in the landlord's building
External key store	≈	The key never leaves your home; the courier calls you each time
XKS proxy	≈	Your home phone line
Proxy offline	≈	Nobody answers: the shop stays shut

Real AWS example · create keys in each kind of custom key store

Origin tells you where the material lives.

# CloudHSM key store (cluster must have >= 2 active HSMs in different AZs)
aws kms create-key --origin AWS_CLOUDHSM --custom-key-store-id cks-1234567890abcdef0

# External key store (XKS proxy must be connected)
aws kms create-key --origin EXTERNAL_KEY_STORE \
  --custom-key-store-id cks-9876543210fedcba0 --xks-key-id ext-key-0042

aws kms describe-custom-key-stores --custom-key-store-id cks-1234567890abcdef0 \
  --query 'CustomKeyStores[0].ConnectionState'
"CONNECTED"

If ConnectionState is DISCONNECTED, all keys in that store are unusable.

Exam-style scenario

A European regulator requires that the cryptographic keys protecting customer data in Amazon EBS and RDS never be stored in, or accessible to, the cloud provider without the customer's ongoing cooperation. Which option meets this?

A. Customer managed KMS key with AWS_KMS origin.
B. Imported key material.
C. An AWS KMS external key store backed by the company's on-premises HSM through an XKS proxy.
D. AWS CloudHSM key store.

Show the worked answer

Answer: C

Only XKS keeps the key material outside AWS, with every use going through the customer's proxy. Imported material and CloudHSM both store key material in AWS.

Why not the others

A: Material is generated and stored by KMS.
B: KMS holds a copy of imported material.
D: Single-tenant, but the HSMs are in AWS.

How the exam tests this

“Keys must never be stored in AWS”→ External key store (XKS).
“Single-tenant HSM but use S3/EBS SSE-KMS”→ CloudHSM key store.
“Custom key store keys suddenly unusable”→ Key store disconnected / proxy or cluster down.
“Need automatic rotation or multi-Region”→ Not in custom key stores.

Must remember

Custom key stores: symmetric only, no auto-rotation, no MRK, no import.
CloudHSM key store: ≥ 2 HSMs, 2 AZs, kmsuser.
XKS: outside AWS, proxy, double encryption, you own availability.
Low-TPS workloads only; no SLA.

Official sources: Key store overview CloudHSM key stores External key stores

Multi-Region keys and cross-Region designs

A normal KMS key lives in one Region, so data encrypted in us-east-1 can't be decrypted in eu-west-1 without calling back to us-east-1 or re-encrypting. Multi-Region keys are sets of related keys in different Regions that share the same key ID and key material. Ciphertext from one decrypts with any other in the set, locally. You choose each Region; they are not global.

Concept profile

Multi-Region key

often confused with single-Region key

?What is it?

A primary KMS key plus replicas in other Regions, all with the same key ID (prefix mrk-), key material, key spec and rotation, so they're interchangeable.

⚙How does it work?

Create the primary with --multi-region.
Run ReplicateKey into each Region you need.
Encrypt in one Region, decrypt in another with the local replica.
Rotation is enabled on the primary and synced to replicas; key policies, grants, aliases, tags and enabled state are per key.
You can promote a replica to primary (UpdatePrimaryRegion).

{ }Structure

Same key ID and material; separate policies.

⇄Multi-Region key vs single-Region key

	Multi-Region key	Single-Region key
Key ID	`mrk-…`, same in every Region	Unique UUID
Decrypt in another Region	Yes, locally	Only by calling the original Region or re-encrypting
Convert later?	n/a	Cannot be converted to multi-Region
Policies	Separate per Region	One
Best for	Client-side encryption, DR, global apps, signing	Most workloads (AWS recommends by default)

!Common mistakes the exam tests

Assuming a replica's key policy is copied or synced: each key has its own policy.
Thinking you can convert an existing key: you must create a new MRK and re-encrypt.
Thinking AWS services like S3 CRR need MRKs: S3 replication re-encrypts with a key in the destination Region; MRKs mainly help client-side encryption and your own apps.
Creating MRKs in a custom key store: not supported.
Using MRKs everywhere: they make data portable across Regions, which may break data-residency rules.

✓Benefits and use cases

Disaster recovery: decrypt backups in the recovery Region during an outage.
Active-active global apps with client-side encryption (Encryption SDK, DynamoDB Encryption Client).
Identical signatures in many Regions.

Think of it like · identical twins with separate passports

Same DNA, different paperwork.

AWS concept		Familiar thing
Multi-Region key set	≈	Identical twins
Same key material	≈	Same DNA: either can open the family safe
Separate key policies	≈	Each twin has their own passport and visa rules
Primary key	≈	The older twin who decides when to change the family code (rotation)
Not global	≈	Twins only exist in the countries you sent them to

Real AWS example · create, replicate and use a multi-Region key

Encrypt in us-east-1, decrypt in eu-west-1 with the same key ID.

aws kms create-key --multi-region --region us-east-1 --description "orders-mrk"
# KeyId: mrk-1234abcd12ab34cd56ef1234567890ab
aws kms replicate-key --region us-east-1 \
  --key-id mrk-1234abcd12ab34cd56ef1234567890ab --replica-region eu-west-1 \
  --policy file://eu-replica-policy.json

aws kms encrypt --region us-east-1 --key-id mrk-1234abcd... \
  --plaintext fileb://order.json --query CiphertextBlob --output text > order.enc
aws kms decrypt --region eu-west-1 --key-id mrk-1234abcd... \
  --ciphertext-blob fileb://<(base64 -d order.enc)

The replica needs its own key policy (here supplied at replication time).

Exam-style scenario

A global app encrypts records client-side with the AWS Encryption SDK in us-east-1 and replicates them to ap-southeast-2. During a us-east-1 outage, the Sydney application must decrypt the records without calling us-east-1. The current key is a single-Region key. What should the team do?

A. Enable cross-Region replication on the existing key.
B. Create a multi-Region primary key, replicate it to ap-southeast-2, re-encrypt the data (or data keys) under the MRK, and use the local replica in Sydney.
C. Copy the key material to Sydney.
D. Use an AWS managed key.

Show the worked answer

Answer: B

A single-Region key can't become multi-Region. With an MRK, the Sydney replica decrypts ciphertext produced in us-east-1 locally.

Why not the others

A: No such feature for single-Region keys.
C: KMS key material can't be exported.
D: AWS managed keys are always single-Region.

How the exam tests this

“Decrypt in another Region without cross-Region calls”→ Multi-Region key.
“Convert existing key to multi-Region”→ Not possible: create new + re-encrypt.
“Replica policy differs from primary”→ Normal: policies are independent.
“Data must never leave one Region”→ Avoid MRKs; use single-Region keys.

Must remember

MRK: same key ID + material, separate policies.
Not global; can't convert single-Region keys.
Rotation managed on the primary.
Mainly for client-side encryption and DR.

Official sources: Multi-Region keys Create replica keys Security considerations

Certificates: ACM and AWS Private CA

Encryption in transit needs certificates. AWS Certificate Manager (ACM) issues free public TLS certificates for AWS services like load balancers, CloudFront and API Gateway, and renews them for you. AWS Private CA lets you run your own private certificate authority hierarchy for internal names, mutual TLS, IoT devices and code signing. Skill 5.3.5 asks you to create and manage keys and certificates in one or many Regions.

Concept profile

AWS Private CA

often confused with ACM public certificates

?What is it?

A managed private certificate authority service: you create root and subordinate CAs whose private keys are kept in AWS-managed HSMs, and issue private certificates trusted only by systems that trust your root.

⚙How does it work?

Create a root CA (or chain to an external root), then subordinate CAs.
Issue certificates through ACM (managed renewal for ACM-integrated services) or directly with the Private CA API.
Publish revocation status with a CRL (to S3) and/or OCSP.
Share a CA with other accounts using AWS RAM.
Choose general-purpose mode or the cheaper short-lived certificate mode (validity up to 7 days).

{ }Structure

Public trust for the internet; private trust for inside your company.

⇄AWS Private CA vs ACM public certificates

	Private CA	ACM public
Trusted by	Only systems with your root installed	All browsers and OSes
Names	Any internal name (e.g. api.corp.internal)	Public domain names you prove you own
Cost	Monthly fee per CA + per certificate	Free for ACM-integrated services
Export private key	Yes, for private certs	Not by default (exportable public certificates are a separate, paid option)
Typical use	mTLS, internal TLS, IoT, Roles Anywhere trust anchor	Public websites and APIs

!Common mistakes the exam tests

Requesting an ACM certificate for CloudFront outside us-east-1: CloudFront only uses certificates from N. Virginia.
Choosing email validation, then the certificate fails to renew because nobody clicks the email. Use DNS validation for automatic renewal.
Using an ACM public certificate on EC2 directly: you can't install it on your own server (unless exportable). Put it on an ALB/NLB/CloudFront.
Forgetting certificates are Regional: request one in each Region you use.
Buying Private CA for public websites: browsers won't trust it.

✓Benefits and use cases

Zero-touch renewal for public endpoints.
Mutual TLS between microservices with private certs.
Trust anchor for IAM Roles Anywhere (IAM Day 3).

Think of it like · passports vs company ID badges

A passport works everywhere; your company badge only opens your company's doors.

AWS concept		Familiar thing
ACM public certificate	≈	A passport issued by the government: accepted everywhere
DNS validation	≈	Proving your address by receiving mail there
AWS Private CA	≈	Your company's badge office
Root CA	≈	The head of security who signs the badge office's authority
CRL / OCSP	≈	The list of lost or cancelled badges at the door
Short-lived certificates	≈	Day passes that expire on their own, so no cancel list is needed

Real AWS example · request a DNS-validated certificate and a private certificate

Public certificate for CloudFront (us-east-1) and a private one for an internal service.

# Public, for CloudFront: must be in us-east-1
aws acm request-certificate --region us-east-1 \
  --domain-name www.example.com --validation-method DNS

# Private, from a Private CA, through ACM
aws acm request-certificate --region eu-west-1 \
  --domain-name payments.corp.internal \
  --certificate-authority-arn arn:aws:acm-pca:eu-west-1:111122223333:certificate-authority/12345678-...

# Export the private certificate and key for an EC2 service (passphrase-protected)
aws acm export-certificate --certificate-arn arn:aws:acm:eu-west-1:...:certificate/abcd... \
  --passphrase fileb://pass.txt

Private certificates issued through ACM can be exported and are renewed by ACM.

Exam-style scenario

Microservices in 12 accounts must authenticate each other with mutual TLS using certificates for names under corp.internal. Certificates should be issued centrally and revoked quickly when a service is compromised. What should the security team build?

A. ACM public certificates with DNS validation.
B. An AWS Private CA hierarchy in a central security account, shared to the 12 accounts with AWS RAM, with OCSP or a CRL for revocation.
C. Self-signed certificates per service.
D. CloudHSM with a hand-built CA.

Show the worked answer

Answer: B

Private CA issues private names, can be shared with RAM, and publishes revocation via CRL/OCSP. Public CAs can't issue certificates for internal-only domains.

Why not the others

A: Public CAs won't issue for corp.internal.
C: No central trust or revocation.
D: Possible but far more effort than a managed CA.

How the exam tests this

“Certificate for CloudFront”→ ACM in us-east-1.
“Certificates must renew automatically”→ DNS validation.
“Internal names, mTLS, IoT”→ AWS Private CA.
“Share a CA across accounts”→ AWS RAM.
“Cheap, very short validity, no revocation needed”→ Short-lived certificate mode.

Must remember

ACM public: free, Regional, CloudFront → us-east-1.
DNS validation = auto-renew.
Private CA: root → subordinate; CRL / OCSP; share with RAM.
Private certs can be exported; public ones normally can't.

Official sources: ACM overview DNS validation AWS Private CA Sharing a private CA

Cheatsheet extras: setting up CloudHSM, its user roles and old KMS myths

Your cheat sheet walks through building a CloudHSM cluster by hand and lists the HSM user types. It also repeats a few “KMS vs CloudHSM” facts that were true years ago but are not true today. This section fills in the setup steps and corrects the old facts, because exam questions written from old material still appear in practice tests.

Concept profile

CloudHSM cluster setup and HSM users

often confused with IAM users for CloudHSM

?What is it?

The steps to turn an empty CloudHSM cluster into a working one, and the HSM users that live inside the HSMs. IAM only controls the CloudHSM API (create cluster, add HSM, backups); it can’t log in to an HSM or use its keys.

⚙How does it work?

1. Create the cluster in private subnets of two or more AZs. CloudHSM creates a security group for the HSM ENIs (ports 2223–2225).
2. Add an HSM, download its CSR, optionally verify the HSM identity certificates.
3. Initialize: sign the CSR with your own issuing CA and upload the signed certificate and your trust anchor.
4. Install the Client SDK on an EC2 instance in the VPC, copy your CA certificate to it.
5. Activate: set the password of the first admin. Then create crypto users who create and use keys.
Add a second HSM in another AZ: keys sync automatically across the cluster.

{ }Structure

Older name (cheat sheet)	Name today (Client SDK 5)	What it can do
PRECO (precrypto officer)	Unactivated admin	Exists only until you activate the cluster and set a password
CO (crypto officer)	Admin	Manages HSM users (create, delete, change passwords). Can’t use keys.
CU (crypto user)	Crypto user	Creates, shares, imports, exports (wrapped) and uses keys: encrypt, decrypt, sign, verify.
AU (appliance user)	Appliance user	Used by AWS to clone and sync HSMs in the cluster. Can’t see your keys.

⇄HSM users vs IAM users for CloudHSM

	HSM users (admin, crypto user)	IAM users/roles
Where they live	Inside the HSMs	In your AWS account
What they control	Keys and crypto operations	The cluster: create, delete, backups, tags
Logged by	HSM audit logs → CloudWatch Logs	CloudTrail
Can AWS reset them?	No: lose all admin passwords and you lose control	Yes, through your account root/admins

!Common mistakes the exam tests

Thinking an IAM policy can stop a crypto user from using a key inside the HSM: only HSM users and key sharing control that.
One HSM only: no high availability. Use at least two HSMs in different AZs.
Expecting CloudTrail to show encrypt/decrypt inside the HSM: those are in the HSM audit logs in CloudWatch Logs.
Believing AWS can recover your keys or passwords: CloudHSM is under your exclusive control.

✓Benefits and use cases

Oracle TDE and SQL Server TDE on EC2 (not RDS) with keys in your own HSM.
SSL/TLS offload for NGINX/Apache, code signing, your own private CA keys.
A KMS custom key store when KMS keys must sit in HSMs you control.

Old facts to unlearn

Older material says	Today
“For FIPS 140-2 compliance you must use CloudHSM, because KMS is multi-tenant.”	KMS HSMs are FIPS 140-3 Level 3 validated. Choose CloudHSM for single-tenant HSMs under your exclusive control, in your VPC, or for APIs KMS doesn’t offer (PKCS #11, JCE, TDE on EC2).
“KMS keys are FIPS 140-2 Level 2.”	Level 3 today. The exam difference is tenancy and control, not the FIPS level.
“Asymmetric keys can’t be in KMS.”	KMS supports RSA, ECC and HMAC keys. Custom key stores (CloudHSM-backed) support symmetric encryption keys only.
“CloudHSM Classic for RDS Oracle / Redshift.”	CloudHSM Classic is gone. RDS Oracle TDE uses an Oracle wallet; Redshift and RDS use KMS keys.
“Imported key material can never be rotated.”	No automatic rotation, but you can rotate on demand after importing new material, or do the classic manual way: new key + move the alias.

Think of it like · a private safe-deposit room

The bank owns the building; you own everything inside the room.

AWS concept		Familiar thing
Cluster	≈	Two identical safe rooms in two buildings that copy each other
Signing the CSR with your CA	≈	Putting your own seal on the room’s door so you know it is really yours
Admin (CO)	≈	The person who issues and cancels access cards
Crypto user (CU)	≈	The person with a card who actually opens the boxes
Appliance user	≈	The bank’s cleaner who copies the room layout but can’t open boxes
IAM	≈	The bank’s front desk: can rent or close rooms, not open them

Real AWS example · initialize and activate a cluster

Abbreviated CLI and CloudHSM CLI steps after the cluster and first HSM exist.

$ aws cloudhsmv2 describe-clusters --filters clusterIds=cluster-abc123 \
    --query "Clusters[0].Certificates.ClusterCsr" --output text > cluster.csr
$ openssl x509 -req -days 3652 -in cluster.csr -CA customerCA.crt \
    -CAkey customerCA.key -CAcreateserial -out CustomerHsmCertificate.crt
$ aws cloudhsmv2 initialize-cluster --cluster-id cluster-abc123 \
    --signed-cert file://CustomerHsmCertificate.crt --trust-anchor file://customerCA.crt

# On the client instance (Client SDK 5)
$ /opt/cloudhsm/bin/cloudhsm-cli interactive
aws-cloudhsm > cluster activate          # sets the first admin password
aws-cloudhsm > login --username admin --role admin
aws-cloudhsm > user create --username app1 --role crypto-user

After activation the admin creates crypto users. Applications log in as a crypto user through PKCS #11, JCE, OpenSSL or KSP/CNG.

Exam-style scenario

A team created a CloudHSM cluster with one HSM. The application can use keys, but auditors ask for (1) protection against an AZ failure and (2) a log of every key use inside the HSM. What should the team do?

A. Enable a CloudTrail data event trail for CloudHSM.
B. Add a second HSM in a different AZ, and use the HSM audit logs that CloudHSM sends to CloudWatch Logs.
C. Take daily CloudHSM backups and copy them to another Region.
D. Move the keys to a KMS custom key store.

Show the worked answer

Answer: B

Two HSMs in different AZs keep the cluster available, and key operations inside the HSM are recorded in HSM audit logs in CloudWatch Logs.

Why not the others

A: CloudTrail records CloudHSM API calls, not crypto operations inside the HSM.
C: Backups help recovery, not availability.
D: Still needs a healthy cluster with two HSMs, and changes the application.

How the exam tests this

“Single-tenant, exclusive control, keys in your VPC”→ CloudHSM.
“FIPS validated HSM, easy AWS integration”→ KMS is fine today.
“Who manages HSM users?”→ Admin (old name CO).
“Who uses keys?”→ Crypto user (CU).
“Log each key use inside the HSM”→ HSM audit logs in CloudWatch Logs.

Must remember

Initialize = sign the cluster CSR with your CA.
Roles: admin (CO) · crypto user (CU) · appliance user (AU).
At least 2 HSMs in 2 AZs.
Crypto ops logged in CloudWatch Logs, API calls in CloudTrail.
KMS is FIPS 140-3 L3 too; CloudHSM = single-tenant.

Official sources: Getting started with AWS CloudHSM HSM user types HSM audit logs in CloudWatch Logs AWS KMS cryptographic details (FIPS validation) Rotating keys (on-demand)

Lecture summary map

Day 2 on one screen.

1. Mind map

Tap a branch to jump back to that part of the lecture. Try redrawing this map from memory on paper.

2. Match the requirement to the key option

Memorize the left column's wording: exam questions use it almost word for word.

3. “If the question says… pick…”

Key material from our own HSM, least changeImported key material

Revoke data access instantly, restore laterDelete imported material, reimport

Imported key failed on a dateMaterial expired; alarm on SecondsUntilKeyMaterialExpiration

Single-tenant HSM, PKCS #11 / TLS offloadAWS CloudHSM

Single-tenant HSM + SSE-KMS for EBS/RDSCloudHSM key store

Keys must never be stored in AWSExternal key store (XKS)

Need auto rotation, MRK or asymmetricNot a custom key store

Decrypt in another Region locallyMulti-Region key

Make an existing key multi-RegionImpossible: new MRK + re-encrypt

Public HTTPS on CloudFrontACM certificate in us-east-1

mTLS with internal names across accountsPrivate CA shared via RAM

Day 2 in one sentence

Every step away from KMS-generated keys buys you control and costs you effort, speed and availability, so move right only when a rule forces you.

Must-remember cheat sheet

1. Origins: AWS_KMS · EXTERNAL · AWS_CLOUDHSM · EXTERNAL_KEY_STORE.

2. Imported: you own durability; optional expiration.

3. Import token + wrapping key valid 24 h.

4. Delete/expire → PendingImport; reimport same material.

5. Imported: no auto-rotation; on-demand OK.

6. CloudHSM: single-tenant, FIPS 140 L3, you manage users.

7. CloudHSM APIs: PKCS #11, JCE, OpenSSL, KSP/CNG.

8. CloudHSM key store: ≥ 2 active HSMs in different AZs + kmsuser.

9. XKS: keys outside AWS, proxy, double encryption.

10. Custom stores: symmetric only, no auto-rotate, no MRK, no SLA.

11. MRK: same key ID + material; separate policies.

12. Can't convert single-Region → MRK.

13. ACM is Regional; CloudFront needs us-east-1.

14. DNS validation for automatic renewal.

15. Private CA: RAM sharing, CRL/OCSP, short-lived mode.

16. Least overhead = KMS, not CloudHSM.

17. CloudHSM roles: admin (old CO) manages users, crypto user (CU) uses keys, appliance user syncs.

18. KMS HSMs are FIPS 140-3 L3 too; pick CloudHSM for single-tenant, exclusive control.

Core quiz

Check the basics first. Pick an answer, then press Check.

Hard quiz

Harder than most real exam questions on purpose, with one matching question. Aim for 9 out of 12 before Day 3.

Practice test questions (from your mock exams)

These 9 questions match today’s topics. 7 come from your own mock exams (the “practice tests” folder); the wording was tidied, and where a mock answer was out of date or wrong, the explanation says so, with the mock and question number at the end. The last 2 are new exam-style questions (marked “New question”) written in October 2026 from the SCS-C03 exam guide and current AWS documentation, to cover recent changes.

Hands-on lab (30 minutes, low cost)

Create a key with --origin EXTERNAL and note its state PendingImport.
Run get-parameters-for-import, generate 32 random bytes with OpenSSL, wrap them with the public key (RSAES_OAEP_SHA_256) and import them with an expiration a few hours away.
Encrypt a small file, delete the imported material, try to decrypt, then reimport the same material and decrypt again.
Create a multi-Region key in one Region, replicate it to another, and decrypt there a ciphertext produced in the first Region.
Request a DNS-validated ACM certificate for a domain you control (or just look at the validation CNAME it asks for).
Skip creating CloudHSM or Private CA in a personal account unless you delete them quickly: both have hourly/monthly charges.

Official sources: Importing key material Multi-Region keys