CAS-004 Security Architecture Practice Question
A financial services firm is designing a new internal API platform. The security architect must ensure that every service-to-service call is authenticated, that a compromised service cannot impersonate another service, and that credentials are short-lived and automatically rotated. The platform runs on Kubernetes and uses an external secrets manager. Which of the following designs best meets these requirements?
⚠ Common exam trap
The trap here is treating network segmentation or a shared secret as equivalent to cryptographic service identity, when only a per-service credential bound to an identity prevents impersonation.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use mutual TLS with certificates issued by a service mesh certificate authority that binds each certificate to the service's Kubernetes service account and rotates it automatically.
Binding a cryptographic identity to each service's Kubernetes service account through a service mesh certificate authority ensures that a compromised service cannot present another service's identity. Mutual TLS authenticates both ends of every call, and the mesh can issue short-lived certificates and rotate them automatically without manual intervention. The other options either share secrets across services, rely only on network reachability, or use long-lived credentials that are not bound to a specific service identity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Rely on network policies that restrict pod-to-pod traffic to approved namespaces and assume that only authorized services can reach each other.
Why it's wrong here
Network policies control reachability but do not authenticate the caller or establish service identity. A compromised pod inside an allowed namespace can still call any reachable service and be treated as legitimate. There is no credential rotation and no binding between the caller and a specific service identity, so the design fails to prevent impersonation and does not provide the short-lived credentials the scenario requires.
- ✗
Issue a long-lived shared API key to each service and store it in a Kubernetes Secret mounted as an environment variable.
Why it's wrong here
A shared, long-lived API key provides authentication but no meaningful service identity binding, so any service that obtains the key can impersonate another. Environment variables and Kubernetes Secrets are also readable by anyone with pod access and are not automatically rotated. This design fails the requirement that a compromised service cannot impersonate another service and does not deliver short-lived, automatically rotated credentials.
- ✓
Use mutual TLS with certificates issued by a service mesh certificate authority that binds each certificate to the service's Kubernetes service account and rotates it automatically.
Why this is correct
Mutual TLS with certificates bound to a Kubernetes service account gives each service a cryptographic identity that cannot be transferred to another service without its private key. A service mesh certificate authority can issue short-lived certificates and rotate them automatically, and the service account binding ensures a compromised pod cannot claim a different service identity. This satisfies authentication, non-impersonation, and automated rotation in one design.
- ✗
Require services to present a JSON Web Token signed with a symmetric key that is distributed to all services in the cluster.
Why it's wrong here
A symmetric signing key shared across all services means any service can forge a token for any other service, directly violating the non-impersonation requirement. Distributing the key cluster-wide also makes rotation difficult because every service must be updated simultaneously. While JWTs can be short-lived, the symmetric trust model collapses the distinction between services, so a single compromised service can mint tokens for the entire platform.
Go deeper
Related to this question
About these practice questions
One of 973 original CAS-005 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CAS-005 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CAS-005 exam.