CV0-004 Cloud Architecture and Design Practice Question
A cloud engineer is deploying a containerized microservices application on Google Kubernetes Engine. The team wants each pod to authenticate to Google Cloud APIs without embedding long-lived service account keys, and they want per-workload identity that can be granted least-privilege IAM roles. Which approach should the engineer implement?
⚠ Common exam trap
The trap here is treating secret storage or rotation as equivalent to eliminating long-lived credentials entirely.
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
✓
Enable Workload Identity and bind a Kubernetes service account to a Google service account
Workload Identity is the GKE-native mechanism that lets pods impersonate a Google service account through short-lived federated tokens, eliminating static key files and enabling per-workload IAM bindings. The alternatives either reintroduce long-lived credentials or collapse identity to the node level, neither of which provides keyless, least-privilege access for individual microservices.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a service account key JSON file and mount it as a Kubernetes Secret in each pod
Why it's wrong here
Mounting a service account key JSON file works technically, but it creates a long-lived credential that must be stored, rotated, and protected, which is exactly what the team wants to avoid. Leaked keys grant persistent access, and there is no per-workload binding, so this approach fails both the keyless authentication and least-privilege identity goals described.
- ✗
Grant the Compute Engine default service account broad roles and let all pods share it
Why it's wrong here
Using the node's default service account gives every pod on that node the same broad permissions, which violates least privilege and creates lateral movement risk if one pod is compromised. It also relies on node-level identity rather than per-workload identity, so it does not meet the requirement for scoped, keyless authentication for each microservice.
- ✓
Enable Workload Identity and bind a Kubernetes service account to a Google service account
Why this is correct
Workload Identity federates Kubernetes service accounts with Google Cloud IAM, allowing pods to obtain short-lived access tokens through the metadata server without any static key files. Each Kubernetes service account maps to a Google service account, so IAM roles can be scoped per workload, satisfying the keyless authentication and least-privilege requirements for the microservices deployment.
- ✗
Store the service account credentials in Secret Manager and inject them at pod startup
Why it's wrong here
Secret Manager centralizes storage and can rotate secrets, but the pod still receives a static credential that lives for its lifetime and must be fetched with some initial identity. There is no federation between the pod identity and IAM, so least-privilege per-workload authorization is not achieved, and the long-lived credential problem remains for this scenario.
Go deeper
Related to this question
About these practice questions
One of 834 original CV0-004 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 CV0-004 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 CV0-004 exam.