Certificates, private CA and CloudHSM: SAP-C03 study notes and practice questions
What to know about Certificates, private CA and CloudHSM for the SAP-C03 exam, from the Security, Compliance, and Governance domain (25% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
These questions ask how to encrypt traffic end to end, how to issue and renew certificates without outages, and when a dedicated HSM is required instead of AWS KMS.
Certificates with ACM
Public certificates are free on integrated services: Elastic Load Balancing, CloudFront, API Gateway and others. ACM renews them automatically.
DNS validation renews with no action as long as the CNAME record stays in place; email validation needs someone to approve renewals.
CloudFront requires its certificate in us-east-1; ALB and regional API Gateway endpoints need a certificate in their own Region.
Exportable public certificates (extra charge) let you install ACM-issued certificates on EC2, containers or on-premises servers. ACM renews them, but you must deploy each renewed certificate.
Imported certificates are not renewed by ACM; monitor their expiry.
AWS Private CA
A managed private certificate authority for internal services, mutual TLS, service meshes, IoT-style devices and IAM Roles Anywhere trust anchors.
Build a hierarchy: an offline-style root CA with subordinate issuing CAs, shared to other accounts through AWS RAM.
ACM can issue and renew private certificates from Private CA for integrated services.
Short-lived certificate mode lowers cost for certificates that live only days.
TLS in practice
Choose an ELB security policy that supports TLS 1.3 (and drops old protocols) for the listener, and a CloudFront viewer security policy for the minimum version.
End-to-end encryption: re-encrypt from the load balancer to targets, or use an NLB TLS passthrough (TCP listener) when the application must terminate TLS itself.
Mutual TLS is supported on ALB and API Gateway custom domains with a trust store of CA certificates.
Enforce TLS for S3 with aws:SecureTransport in a bucket policy.
AWS CloudHSM
Single-tenant HSMs in your VPC, FIPS 140-2 or 140-3 Level 3 validated (in FIPS mode). You manage the users and keys; AWS can’t see or use them.
Run a cluster across Availability Zones for availability; AWS handles provisioning, backups and patching.
Use cases: regulations that require a dedicated HSM, PKCS #11, JCE or OpenSSL integration, SSL/TLS offload, Oracle TDE, or acting as a CA signing key store.
Can back a KMS custom key store, so AWS services keep using KMS APIs while key material stays in your cluster.
How to choose
Scenario wording
Pick
HTTPS on ALB or CloudFront, no renewal work
ACM public certificate with DNS validation
Internal mTLS between services
AWS Private CA
Certificate on EC2 or on premises, managed renewals
ACM exportable public certificate
Regulation requires single-tenant HSM you control
CloudHSM
Dedicated HSM but services must use KMS integration
KMS custom key store on CloudHSM
App must see the original TLS session
NLB with TCP passthrough
Common traps
CloudHSM when the requirement is only “customer managed keys with audit”; KMS meets that with far less work.
A certificate in the wrong Region for CloudFront.
Email validation that silently fails to renew.
Self-signed certificates on instances when Private CA or ACM handles issuance and renewal.
A hospital group runs a legacy record-signing service that signs clinical documents with a private key. The service calls the PKCS#11 interface, so the key must be held in a hardware module that the service can reach directly.
The group's auditors require single-tenant hardware that only the group's own administrators manage, with FIPS 140-3 Level 3 validation. The service runs in two Availability Zones, and the key must survive the loss of one of them.
Which solution meets these requirements?
Choose one answer.
AA. Create an AWS CloudHSM cluster with an HSM in each of two Availability Zones, install the CloudHSM client on the service hosts, and sign through the PKCS#11 library against the cluster.
BB. Create a customer managed KMS asymmetric key in the default key store with an RSA key spec, and have the service call the KMS Sign API for each document instead of using its PKCS#11 interface.
CC. Create the signing key in an AWS KMS custom key store backed by an AWS CloudHSM cluster, and have the service call the KMS Sign API for each document.
DD. Store the signing key in AWS Secrets Manager, encrypted with a customer managed KMS key, and have the service read the key into memory at startup.
Show the answer and explanation
Answer: A
A. Right: Correct. CloudHSM gives dedicated, single-tenant HSMs that the group manages, and the PKCS#11 library lets the service sign with the key that stays inside the module. Two HSMs in separate Availability Zones keep the key available if one zone fails.
B. Wrong: The KMS default key store uses a shared fleet of HSMs managed by AWS, not single-tenant hardware that the group's administrators manage. The service would also have to change from PKCS#11 to the KMS API.
C. Wrong: Custom key stores support only symmetric encryption KMS keys, so they cannot hold an asymmetric signing key. The service would also call the KMS API instead of reaching the HSM through PKCS#11.
D. Wrong: The key would be held in software in the service's memory after startup, which breaks the requirement for a hardware module. Secrets Manager is for secrets, not for hardware-protected signing keys.
Explanation
CloudHSM provides single-tenant, FIPS-validated hardware that the service reaches through PKCS#11, with HSMs in two Availability Zones for resilience. The KMS default key store is shared, custom key stores hold only symmetric keys, and Secrets Manager keeps the key in software.
Want more on Certificates, private CA and CloudHSM? The 5 full-length practice sets have 6 more Certificates, private CA and CloudHSM questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →