mediumMultiple ChoiceObjective-mapped
Google ACE Practice Question: Your application runs on GKE and needs to call…
Your application runs on GKE and needs to call the Cloud Translation API. You want to follow Google's recommended security practice for service-to-cloud-API authentication within GKE. Which approach should you use?
⚠ Common exam trap
Google Cloud often tests the misconception that mounting a service account key as a Kubernetes Secret is acceptable for production, but the correct answer emphasizes using Workload Identity to avoid managing static keys.
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
✓
Configure Workload Identity to bind the pod's Kubernetes Service Account to a Google Service Account with Translation API access.
Workload Identity is Google's recommended approach for authenticating workloads in GKE to Google Cloud APIs. It allows you to bind a Kubernetes Service Account (KSA) to a Google Service Account (GSA), so pods can impersonate the GSA without managing or storing long-lived service account keys. This eliminates the security risk of key exposure and follows the principle of least privilege.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Download a service account key JSON and mount it as a Kubernetes Secret in the pod.
Why it's wrong here
Manually downloading a service account key JSON and mounting it as a Kubernetes Secret is the antithesis of Google's recommended approach for GKE, because the key is a long-lived credential that never automatically rotates. Unless you build additional automation to revoke and reissue keys, the credential remains valid for up to the key's lifespan, even if the pod or secret is deleted. This also places the burden of Secret encryption, access control, and rotation on the cluster operator, and any user with `secrets.get` or `pods/exec` access could extract the key. Workload Identity avoids all these issues by generating short-lived tokens based on the Kubernetes Service Account identity, with no manual secret handling.
- ✓
Configure Workload Identity to bind the pod's Kubernetes Service Account to a Google Service Account with Translation API access.
Why this is correct
Workload Identity is the recommended GKE authentication mechanism because it binds a Kubernetes Service Account to a Google Service Account via the `iam.gke.io/gcp-service-account` annotation. Pods automatically receive short-lived OAuth 2.0 access tokens from the GKE metadata server, eliminating the need to create, store, or rotate any service account key files. Since the mapped Google Service Account holds only `roles/cloudtranslate.user`, access is strictly scoped to the Translation API for that workload, satisfying least privilege. The node pool's service account only needs `roles/iam.workloadIdentityUser` to enable impersonation, so node-level permissions stay minimal.
- ✗
Grant the GKE node pool's service account `roles/cloudtranslate.user`.
Why it's wrong here
Granting the GKE node pool's service account `roles/cloudtranslate.user` grants Translation API access to every pod scheduled on those nodes, not just the workload that needs it. This violates least privilege because unrelated workloads running on the same nodes silently inherit the permission, expanding the blast radius if any of those pods is compromised. Additionally, the node service account is the identity for the node itself, used for node management operations, and should not be repurposed for application-level API access. Workload Identity solves this by mapping a specific Kubernetes Service Account to a dedicated Google Service Account, enabling granular per-workload permission isolation.
- ✗
Use the GOOGLE_APPLICATION_CREDENTIALS environment variable pointing to a mounted key file.
Why it's wrong here
This approach still relies on a service account key file—typically stored in a Kubernetes Secret and referenced by `GOOGLE_APPLICATION_CREDENTIALS`—which is a long-lived, static credential requiring manual rotation, secure storage, and careful secret management. On GKE, the metadata server already provides a secure token path via Workload Identity, so introducing a key file adds unnecessary attack surface and operational overhead. If the pod is compromised, the key can be exfiltrated and used outside the cluster indefinitely. Google explicitly recommends against using key files when Workload Identity is available because it defeats the automatic token expiry and fine-grained scoping benefits of Workload Identity.
Go deeper
Related to this question
Learn chapter
Google Cloud Platform Overview
Key term
Anthos
Anthos is a Google Cloud platform that lets you run applications consistently across different computing environments, like on-premises data centers and multiple public clouds.
Key term
Cloud Translation
Cloud Translation is a managed service that uses machine learning to dynamically translate text between languages over the internet.
About these practice questions
One of 769 original ACE 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE 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 ACE exam.