CAS-004 Security Engineering Practice Question
A security architect is designing a microservices platform that runs on a shared Kubernetes cluster. Each service must be able to prove its identity to other services, and the design must avoid long-lived shared secrets and support automatic credential rotation when a pod is rescheduled. Which approach BEST meets these requirements?
⚠ Common exam trap
The trap here is assuming that Kubernetes Secrets or NetworkPolicies provide workload identity, when they only store data or filter traffic and cannot cryptographically prove which service is calling.
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
✓
Issue each service a signed SPIFFE SVID through a SPIRE agent running as a DaemonSet, and use mTLS between services.
Workload identity frameworks such as SPIFFE/SPIRE bind a cryptographic identity to the actual workload through node and pod attestation, then issue short-lived certificates that rotate automatically. Using mTLS with those identities gives mutual authentication and encryption without shared static secrets, which is exactly what the microservices platform needs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable Kubernetes service account token projection with a 24-hour expiration and use the token as a bearer credential for inter-service calls.
Why it's wrong here
Projected service account tokens are bound to a pod and audience, but using them as bearer tokens for service-to-service calls does not provide mutual authentication or encryption, and a stolen token can be replayed. Rotation exists, yet the design still lacks the cryptographic peer verification the scenario demands.
- ✗
Store a unique API key for each service in a Kubernetes Secret and require services to present the key in an HTTP header.
Why it's wrong here
Kubernetes Secrets are long-lived and, unless additionally encrypted and carefully RBAC-restricted, can be read by anyone with access to the namespace or the etcd datastore. Static API keys do not rotate automatically and provide no cryptographic proof of workload identity, so they fail the stated requirements.
- ✓
Issue each service a signed SPIFFE SVID through a SPIRE agent running as a DaemonSet, and use mTLS between services.
Why this is correct
SPIFFE/SPIRE issues short-lived, cryptographically verifiable identities (SVIDs) to workloads based on attested node and pod attributes, and automatically rotates them. mTLS using these SVIDs lets each service authenticate peers without embedded static secrets, satisfying the rotation requirement when pods move.
- ✗
Configure Kubernetes NetworkPolicies to allow traffic only between approved service namespaces.
Why it's wrong here
NetworkPolicies restrict which pods can communicate at the IP/port level, but they do not authenticate the identity of a service or rotate credentials. An attacker who compromises an allowed pod can still reach peers, so NetworkPolicies complement but do not replace workload identity.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CAS-005 question from scratch — 973 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.