Internal microservices for a city’s tax stack must authenticate to each other with TLS certificates that are not public website certs. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
Public ACME certs are for the front door on the internet. Inside city microservices, a private CA issues the badges services trust among themselves. Private IP alone is not a substitute for TLS identity.
Full Explanation
Internal microservices in a city’s tax stack should authenticate to each other using TLS certificates issued by a private certificate authority such as AWS Private CA. Private CA certificates establish service identity for internal hostnames and private trust domains without forcing public ACME certificates onto non-public service names. Pair issuance with automated rotation and trust-store distribution across the mesh.
Requiring only Let’s Encrypt or other public ACME certificates and refusing any private CA creates friction for internal naming and private trust. Disabling TLS inside the VPC because addresses are private ignores credential theft and east-west movement. Sharing one self-signed certificate pasted into every repository README without rotation or proper trust stores is fragile and often insecure.
Exam caveat: mutual TLS needs a trusted CA, validated SANs, and rotation—AWS Private CA plus ACM integrations are a common managed approach on exam scenarios. Operational check: issue certificates from Private CA to two tax microservices, complete an mTLS call, replace or revoke a certificate, and confirm untrusted or expired certificates fail the handshake while valid pairs continue to succeed.