ExamworthyExamworthy
Open the appStart free

GCP-ACE - Configuring access and security - Section 4.2

Manage service accounts, including creating service accounts with minimum permissions, assigning them to resources, managing impersonation and short-lived credentials, using a service account with a GKE application, and provisioning Workload Identity Federation.

Create service accounts and grant them the minimum permissions their workload needs, assign them to resources, and manage the permissions on the service account itself. Use service account impersonation and short-lived credentials instead of exported keys, bind a Kubernetes service account to a Google Cloud service account with Workload Identity for a GKE application, and provision Workload Identity Federation so external workloads authenticate without long-lived keys.

Service accountsService account impersonationShort-lived credentialsWorkload IdentityWorkload Identity Federation

Practice question for this objective

Free sampleConfiguring access and securityhard

A payments service runs in the 'ledger' namespace of a GKE cluster that has Workload Identity enabled and the node pool already on the GKE metadata server. The pods use a Kubernetes service account annotated with iam.gke.io/gcp-service-account pointing at a Google service account that holds the Storage Object Viewer role. Calls to Cloud Storage still return 403. Which step completes the keyless setup?

  • AGrant the Google service account the Storage Object Admin role, because Object Viewer cannot read bucket objects and the 403 signals an insufficient Cloud Storage permission on the account.
  • BAdd an IAM policy binding granting the Workload Identity User role on the Google service account to the member serviceAccount:PROJECT_ID.svc.id.goog[ledger/KSA_NAME], linking the Kubernetes account to it. Correct
  • CRecreate the node pool with the flag --workload-metadata=GCE_METADATA so the pods can reach the metadata server and fetch tokens for the annotated Google service account.
  • DExport a JSON key for the Google service account and mount it into the pods as a Kubernetes secret so they can authenticate to Cloud Storage directly using the key file.
Binding a Kubernetes service account to a Google service account requires the Workload Identity User IAM binding, not just the KSA annotation. Workload Identity needs two links: the KSA annotation naming the Google service account, and an IAM binding of roles/iam.workloadIdentityUser on that Google service account to the KSA member string. Without the binding the impersonation is not authorised, so API calls fail with 403.

Why A is wrong: This is tempting because the failure surfaces on a storage call, but Object Viewer does permit reading objects; the 403 here reflects a missing Workload Identity trust binding, not an under-scoped storage role.

Why B is correct: Correct: the annotation alone is not enough. The Google service account needs an IAM binding of roles/iam.workloadIdentityUser to the KSA member, which is what authorises the pod to impersonate it without a key.

Why C is wrong: This is tempting because metadata configuration is part of the setup, but GCE_METADATA exposes the node's own identity and disables Workload Identity; the correct value is GKE_METADATA, and the node pool is already on it.

Why D is wrong: This is tempting as a quick fix, but it reintroduces an exported key, which is exactly what Workload Identity removes; the missing piece is the IAM binding, not a mounted credential file.

See more GCP-ACE practice questions, answers explained.

More in this domain

Back to all Configuring access and security objectives, or the GCP-ACE cert hub.

Examworthy is not affiliated with or endorsed by Google Cloud. Original, blueprint-aligned practice material only.