Certificate management is one of those SCS-C02 topics that looks small on the exam blueprint and then shows up in question after question. A scenario describes a public website whose certificate expired at 2 a.m. and asks why automatic renewal failed. Another describes an internal microservices mesh that needs mutual TLS and asks which service issues the certificates. A third asks where TLS should terminate for a CloudFront distribution and which Region the certificate must live in. None of these are hard once you understand how AWS Certificate Manager (ACM) and AWS Private Certificate Authority (Private CA) actually work — but they trip up candidates who only know “ACM gives you free certs.”
This guide covers certificate management the way the SCS-C02 tests it: the difference between public and private certificates, how ACM handles validation and automatic renewal (and the one reason renewal silently fails), where TLS terminates across ALB, CloudFront, and API Gateway, why ACM certificates cannot be exported, and when a workload needs AWS Private CA instead. It focuses on encryption in transit and the certificate lifecycle; for encryption at rest with KMS, envelope encryption, and key policies, see the companion KMS and data protection deep dive. If you are still planning your prep, start with the SCS-C02 exam guide for 2026 and the domains explained overview.
Why Certificate Management Matters on the SCS-C02
The Data Protection domain of the SCS-C02 is built on two halves: protecting data at rest (KMS, S3 encryption, envelope encryption) and protecting data in transit (TLS, certificates, secure endpoints). Certificate management is the backbone of the in-transit half. Every HTTPS endpoint, every ALB listener on port 443, every CloudFront distribution, and every internal mTLS connection depends on X.509 certificates that must be issued, validated, deployed, rotated, and eventually renewed. The exam wants to know that you can design that lifecycle securely and diagnose it when it breaks.
There are two AWS services to keep straight, and the whole topic hinges on the distinction:
- AWS Certificate Manager (ACM) — provisions, manages, and auto-renews certificates for use with integrated AWS services. Public certificates from ACM are free.
- AWS Private Certificate Authority (AWS Private CA) — a managed private certificate authority for issuing your own private certificates inside your organization. Private CA is a paid service (a monthly cost per CA plus per-certificate charges).
Almost every certificate question reduces to “which of these two, and why.”
Public vs. Private Certificates: The Core Distinction
The first fork in any certificate question is whether the certificate is public or private, because it decides which service you use and how the certificate is trusted.
A public certificate is trusted automatically by browsers and operating systems because it chains up to a well-known public root CA that ships in every trust store. You use public certificates for anything on the public internet — a customer-facing website, a public API. ACM issues these for free through Amazon’s own public CA.
A private certificate is trusted only by clients you have explicitly configured to trust your private CA. You use private certificates for internal traffic — service-to-service mTLS, internal load balancers, IoT devices, VPN endpoints — where you control both ends and do not want to expose anything to the public internet. AWS Private CA issues these.
| ACM public certificate | AWS Private CA | |
|---|---|---|
| Trusted by | Public browsers/OS trust stores | Only clients that trust your CA |
| Use case | Public websites, public APIs | Internal services, mTLS, IoT, VPN |
| Cost | Free | Paid (per CA + per certificate) |
| Validation | DNS or email (you prove domain ownership) | You control the CA; no external validation |
| Exportable private key | No (see below) | Yes — you can issue and export certs |
| Auto-renewal | Yes, managed by ACM | Renewal you manage/automate |
When a scenario says “public-facing,” “customer website,” or “internet,” think ACM public. When it says “internal,” “private,” “service mesh,” “mutual TLS,” or “on-premises devices we control,” think AWS Private CA.
How ACM Validation Works: DNS vs. Email
Before ACM issues a public certificate, you must prove you control the domain. There are two validation methods, and the exam strongly prefers one.
DNS validation asks you to add a specific CNAME record to your domain’s DNS. Because the record is durable, ACM can re-check it whenever the certificate is up for renewal — which means DNS validation supports fully automatic renewal. If your domain is in Route 53, ACM can even create the CNAME for you with one click. This is the recommended, exam-preferred method.
Email validation sends an approval email to the domain’s registered contact addresses (and a few well-known addresses like admin@ and webmaster@). Someone must click the link. Because there is no durable proof ACM can re-check automatically, email-validated certificates require a manual re-approval at renewal time every time. That is a fragile design, and the exam treats it as the inferior choice.
The takeaway for the exam: prefer DNS validation because it enables hands-off automatic renewal; email validation forces recurring manual steps and is a common root cause of “why did our certificate expire” incidents.
Automatic Renewal — and the One Reason It Fails
The single biggest reason to use ACM is managed renewal: for eligible certificates, ACM automatically renews them before expiry (starting well ahead of the expiration date) and, because the integrated services reference the certificate by ARN, deploys the renewed certificate with no downtime and no manual redeploy. This is why “let ACM manage it” is the right answer to most “how do we avoid certificate expiry” questions.
But there is a crucial condition the exam loves to test. Automatic renewal only works when ACM can still re-validate domain ownership. Two failure modes matter:
- Email-validated certificates cannot renew silently because they need a human to re-approve — this is why they are discouraged.
- DNS-validated certificates renew automatically only as long as the validation CNAME record remains in place. If someone deletes that CNAME from DNS, ACM can no longer confirm ownership at renewal time and the certificate fails to renew and eventually expires.
So when a scenario says “our ACM certificate expired even though we use ACM,” the diagnosis is almost always one of: the certificate was imported (see below) rather than ACM-issued, it was email-validated and nobody re-approved, or the DNS validation record was removed. ACM raises events and can be monitored — pairing ACM with Amazon EventBridge and AWS Config rules to alert on approaching expiry is the exam-approved way to catch these before they become outages.
TLS Termination: Where the Certificate Lives
A recurring exam pattern gives you an architecture and asks where TLS terminates and therefore where the certificate must be attached. ACM integrates directly with a specific set of services, and you attach the certificate to whichever of them fronts the traffic.
- Application Load Balancer (ALB) and Network Load Balancer (NLB) — attach the ACM certificate to the HTTPS/TLS listener; the load balancer terminates TLS and forwards to targets. This is the most common answer for traffic entering a VPC.
- Amazon CloudFront — attach the certificate to the distribution. TLS terminates at the edge, close to the user.
- Amazon API Gateway — attach the certificate for custom domain names on your APIs.
Two hard constraints the exam tests directly:
- CloudFront certificates must be in
us-east-1(N. Virginia). ACM is a Regional service, and CloudFront — being global — only reads certificates fromus-east-1. If you request the certificate in the wrong Region, CloudFront will not offer it. This is one of the most frequently missed facts on the whole exam. - Certificates for ALB/NLB/API Gateway must be in the same Region as the resource. Because those resources are Regional, the certificate has to be requested in that Region.
Do not overlook a related design point: TLS can terminate at the edge/load balancer and then use separate encryption for the backend hop. For end-to-end encryption you configure HTTPS from the load balancer to the targets as well — the front-end certificate does not by itself encrypt the internal hop.
Why ACM Certificates Cannot Be Exported
Here is a property that generates a lot of exam questions: for certificates that ACM issues (public certificates from Amazon’s CA), you cannot export the private key. ACM generates and stores the private key, and it can only be used by the AWS services ACM is integrated with — you cannot download it to install on an EC2 instance’s web server, an on-premises appliance, or a third-party device.
This drives the decision tree for three scenarios:
- You need the certificate on an integrated AWS service (ALB, CloudFront, API Gateway). Use an ACM public certificate — free, auto-renewing, no export needed.
- You need to install a certificate somewhere ACM does not integrate (a self-managed web server on EC2, an on-premises box), and it must be publicly trusted. You cannot use an ACM-issued public cert here; you either obtain a certificate elsewhere and import it into ACM, or run the endpoint behind an integrated service.
- You need exportable certificates for internal use — for example, to install on many internal servers or devices. Use AWS Private CA, which can issue and export private certificates you control.
Imported certificates are worth their own note: ACM lets you import third-party certificates (with their private keys) to use with integrated services, but ACM cannot auto-renew an imported certificate — you must re-import a new one before it expires. “The certificate was imported” is a classic explanation for an unexpected expiry.
When to Use AWS Private CA
AWS Private CA is the answer whenever the requirement is private trust at scale. It lets you stand up a managed CA hierarchy — a root CA and one or more subordinate (intermediate) CAs — and issue private certificates programmatically. Typical exam-worthy use cases:
- Mutual TLS (mTLS) between microservices, where each service presents a client certificate that the other validates against your private CA.
- Internal load balancers and internal websites that should be trusted only by your own fleet.
- IoT device identity, issuing a unique certificate per device.
- Kubernetes / service mesh workloads that need an internal issuer.
Key design facts: a best-practice hierarchy keeps the root CA offline/rarely used and issues day-to-day certificates from subordinate CAs, limiting the blast radius if a subordinate is compromised. Private CA integrates with ACM so that ACM can request private certificates from your CA and even manage their renewal for integrated services. Because Private CA is billed per CA per month plus per issued certificate, “cost-sensitive and only needs public certs” points away from Private CA and back to free ACM public certificates.
Certificate Management Decision Cheat Sheet
| Scenario wording | Answer |
|---|---|
| Public website / customer-facing, free, auto-renew | ACM public certificate |
| CloudFront distribution certificate | ACM cert in us-east-1 |
| ALB/NLB HTTPS listener | ACM cert in the ALB’s Region |
| ”Certificate expired despite using ACM” | Imported cert, email validation, or deleted DNS record |
| Need to install cert on EC2/on-prem, publicly trusted | Import into ACM (no auto-renew) |
| Internal mTLS / service-to-service | AWS Private CA |
| Per-device / IoT identity certificates | AWS Private CA |
| Certificate that must be exportable | AWS Private CA (ACM-issued public certs are not exportable) |
| Enable hands-off renewal | DNS validation |
Common Mistakes on This Topic
- Forgetting the CloudFront
us-east-1rule. A certificate in any other Region simply will not appear for a CloudFront distribution. - Assuming every ACM certificate auto-renews. Imported certificates never do; email-validated ones need manual re-approval; DNS-validated ones need the validation record to stay in place.
- Trying to export an ACM-issued public certificate. The private key is not downloadable — reach for Private CA when you need exportable certs.
- Reaching for Private CA when public certs would do. Private CA is a paid service for private trust; do not use it for public websites where free ACM public certs are correct.
- Terminating TLS only at the edge and calling it “end-to-end.” Encrypting the front-end hop does not encrypt the load-balancer-to-target hop; configure backend HTTPS for true end-to-end encryption.
Frequently Asked Questions
What is the difference between AWS Certificate Manager and AWS Private CA?
AWS Certificate Manager (ACM) provisions, manages, and auto-renews certificates for use with integrated AWS services, and its public certificates are free and trusted by browsers automatically. AWS Private CA is a managed private certificate authority you use to issue your own private certificates for internal trust — service-to-service mTLS, internal load balancers, IoT devices — that only clients configured to trust your CA will accept. ACM is for public-facing TLS; Private CA is for internal, private trust and is a paid service.
Why did my ACM certificate expire even though ACM auto-renews?
Automatic renewal only works when ACM can re-validate domain ownership and when ACM issued the certificate. The three usual causes of an unexpected expiry are: the certificate was imported (ACM never auto-renews imported certificates), it was email-validated and nobody re-approved the renewal, or it used DNS validation but the validation CNAME record was removed so ACM could no longer confirm ownership. Use DNS validation, keep the validation record in place, and monitor expiry with EventBridge and AWS Config.
Which Region must a certificate be in for CloudFront?
A certificate used with an Amazon CloudFront distribution must be requested or imported in the us-east-1 (N. Virginia) Region. CloudFront is a global service that reads ACM certificates only from us-east-1, so a certificate in any other Region will not be selectable for the distribution. For Regional resources like an ALB or API Gateway custom domain, the certificate must instead be in the same Region as that resource.
Can I export a certificate from AWS Certificate Manager?
No — for public certificates that ACM issues, you cannot export the private key; it is generated and stored by ACM and can only be used by integrated AWS services such as ALB, CloudFront, and API Gateway. If you need an exportable certificate to install on an EC2 instance, an on-premises server, or a device you manage, use AWS Private CA, which can issue and export private certificates you control.
What is the difference between DNS and email validation in ACM?
Both prove you control the domain before ACM issues a public certificate. DNS validation adds a CNAME record to your domain and, because that record is durable, lets ACM automatically renew the certificate with no manual steps — it is the recommended method. Email validation sends an approval link to the domain’s contacts and requires a person to click it both at issuance and at every renewal, making it fragile and a frequent cause of missed renewals. Prefer DNS validation.
When should I use AWS Private CA instead of ACM public certificates?
Use AWS Private CA whenever you need private trust rather than public trust: mutual TLS between microservices, internal load balancers and websites, per-device IoT identity, or any endpoint where you control both sides and do not want public exposure. Private CA also gives you exportable certificates and a CA hierarchy you manage. Stick with free ACM public certificates for anything internet-facing that browsers must trust automatically, since Private CA is a paid service.
Conclusion and Next Steps
Certificate management stops being intimidating on the SCS-C02 once you anchor on a few decisions. Public and internet-facing means an ACM public certificate — free and auto-renewing. Private and internal means AWS Private CA. DNS validation enables hands-off renewal; email validation and imported certificates are the usual reasons a certificate expires. TLS terminates at the ALB, CloudFront (with the certificate in us-east-1), or API Gateway, and ACM-issued public certificates can never be exported. Get those reflexes down and the certificate questions become reliable points, and the diagnostic scenarios — “why did it expire,” “where does it terminate,” “which service issues it” — answer themselves.
The fastest way to turn this into exam-day confidence is realistic practice. Sailor.sh’s AWS Certified Security - Specialty (SCS-C02) Mock Exam Bundle gives you full-length, exam-style questions that mirror the real format and difficulty — including the certificate-lifecycle, validation, and TLS-termination scenarios covered here — with detailed explanations that reinforce the exact facts the exam tests. Working through realistic questions is the surest way to find your weak spots before exam day.
Pair the practice with the SCS-C02 study plan, then complete the Data Protection domain with the KMS and data-protection deep dive for encryption at rest and the infrastructure security guide for VPC, WAF, and edge protection. To sharpen the identity side that governs who can request and manage certificates, review the IAM deep dive.