Google PCA Manage and provision cloud infrastructure Practice Question
A DevOps team is deploying a microservices application on Google Kubernetes Engine (GKE). They want to ensure that the pods can securely access Google Cloud APIs (e.g., Cloud Storage) without managing service account keys. Which TWO steps should they take? (Choose two.)
⚠ Common exam trap
Google Cloud often tests the misconception that storing keys in Kubernetes Secrets or using node-level default service accounts is acceptable for secure API access, when in fact Workload Identity is the recommended, keyless approach for GKE.
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
✓
Create a dedicated GCP service account with necessary roles and bind it to Kubernetes service accounts via Workload Identity.
Option A is correct because Workload Identity requires creating a dedicated Google Cloud service account with the necessary IAM roles and binding it to a Kubernetes service account (via an IAM policy binding with roles/iam.workloadIdentityUser), which lets the pod impersonate the GCP service account without keys. Option D is correct because Workload Identity must first be enabled on the GKE cluster (e.g., with gcloud container clusters update --workload-pool=PROJECT_ID.svc.id.goog), which sets up the cluster's identity pool and OIDC issuer so Kubernetes service accounts can federate to Google Cloud IAM. Option B is wrong because using the Compute Engine default service account on nodes grants broad, shared credentials to every pod and does not provide per-pod identity or keyless access. Option C is wrong because storing service account keys in Vault still involves managing long-lived keys, which is exactly what the team wants to avoid. Option E is wrong because mounting service account keys from a Kubernetes Secret also relies on static, manually managed credentials rather than keyless Workload 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.
- ✓
Create a dedicated GCP service account with necessary roles and bind it to Kubernetes service accounts via Workload Identity.
Why this is correct
Workload Identity federates Kubernetes service accounts to a Google Cloud service account, so pods obtain short-lived credentials from the metadata server. Creating the dedicated service account with the required roles and binding it to the Kubernetes service account removes the need for exported, long-lived keys.
- ✗
Use the Compute Engine default service account on each node.
Why it's wrong here
The Compute Engine default service account is shared by all node workloads and typically holds broad project roles, granting every pod the same permissions. Workload Identity Federation for GKE maps distinct Kubernetes service accounts to distinct Google service accounts. The default account suits throwaway nodes, not least-privilege pod access.
- ✗
Use a secrets management solution like HashiCorp Vault to store service account keys and retrieve them at runtime.
Why it's wrong here
Vault still stores and distributes static service account keys, so key management and rotation remain, failing the keyless requirement. Workload Identity Federation for GKE lets pods obtain short-lived Google Cloud credentials through IAM binding. Vault fits managing secrets for external systems that lack native federation.
- ✓
Enable Workload Identity on the GKE cluster.
Why this is correct
Enabling Workload Identity on the cluster activates the IAM-to-Kubernetes federation mechanism, configuring the workload identity pool and metadata server behaviour that lets pods impersonate Google Cloud service accounts. Without this cluster-level setting, the service account binding alone cannot issue keyless credentials.
- ✗
Store service account keys in a Kubernetes Secret and mount them into pods.
Why it's wrong here
Storing keys in a Kubernetes Secret still creates long-lived credentials to manage and rotate, contradicting the keyless requirement. Workload Identity Federation for GKE binds a Kubernetes service account to a Google service account via IAM, issuing short-lived tokens. Secrets suit non-GCP credentials that cannot use federation.
Go deeper
Related to this question
Learn chapter
Cloud Storage: Objects and Buckets
Key term
Service
A service is a software component or system that performs a specific function and is available to be used by other programs or users over a network.
Key term
Least privilege
Least privilege is a security principle that means giving users, systems, or programs only the minimum permissions they need to do their job and nothing more.
About these practice questions
This PCA question is part of Courseiva's 807-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCA practice question is part of Courseiva's free Google Cloud 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 PCA exam.