Google ACE A GKE Pod needs to call the Cloud Storage API Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Mount a service account JSON key file as a Kubernetes Secret and set GOOGLE_APPLICATION_CREDENTIALS

  Why it's wrong here

  Storing a service account JSON key in a Kubernetes Secret and setting GOOGLE_APPLICATION_CREDENTIALS allows Pods to authenticate, but it requires managing long-lived static credentials that must be manually rotated and securely stored. These key files can easily leak through Docker image layers, environment dumps, or compromised containers, and they do not automatically expire or integrate with GCP audit logs in the same way as workload identity. This pattern is exactly what Workload Identity is designed to replace, because it adds operational overhead and increases the risk of key leakage.

• ✓

  Enable Workload Identity on the GKE cluster and bind a Kubernetes ServiceAccount to a GCP IAM ServiceAccount

  Why this is correct

  Workload Identity lets each Kubernetes ServiceAccount map to a dedicated GCP IAM ServiceAccount, so Pods authenticate through the GKE metadata server using short-lived OAuth2 tokens. This completely removes the need for static JSON key files, eliminating manual rotation and key-leak risk. It also enforces least privilege because each workload gets only the IAM permissions bound to its own service account. Enabling it requires the cluster, node pools, and the metadata server configuration, but it's the recommended modern pattern.

• ✗

  Rely on the GKE node's Compute Engine service account for all Pod authentication

  Why it's wrong here

  Using the Compute Engine service account attached to the GKE node means every Pod on that node automatically inherits the exact same broad GCP permissions, violating the principle of least privilege. If any workload is compromised, the attacker gains access to all node-level permissions, including any roles assigned to the node pool. This also makes it impossible to grant different permissions to different workloads without changing the node's service account, which affects all Pods on the node simultaneously.

• ✗

  Grant the GKE node pool's service account the Storage Admin role to cover all Pod needs

  Why it's wrong here

  Assigning Storage Admin to the node pool's service account grants full control over all storage resources across the entire project, far beyond what individual Pods typically need. This broad role not only over-provisions every Pod on those nodes but also creates a single set of credentials with enormous blast radius if compromised. For least privilege, you should instead bind scoped roles like roles/storage.objectViewer or roles/storage.objectAdmin to dedicated IAM service accounts via Workload Identity.

Go deeper

Related to this question