GCP Associate Cloud Engineer Practice Question

A development team wants its Pods running in the default namespace of a GKE cluster to upload objects to a Cloud Storage bucket without storing any service-account key files. They created a Google service account named gsa-uploader and a Kubernetes service account named ksa-uploader, and Workload Identity is already enabled on the cluster. Which IAM configuration will let the Pods obtain short-lived credentials and act as gsa-uploader when calling Cloud Storage?

Add the gsa-uploader service account email to a secret in the default namespace so Pods can mount it at runtime.
Grant the role roles/iam.workloadIdentityUser on gsa-uploader to the principal serviceAccount:PROJECT_ID.svc.id.goog[default/ksa-uploader].
Grant the role roles/iam.serviceAccountUser on ksa-uploader to the principal gsa-uploader@PROJECT_ID.iam.gserviceaccount.com.
Grant the role roles/storage.objectAdmin on the Cloud Storage bucket to serviceAccount:PROJECT_ID.svc.id.goog[default/ksa-uploader] and make no other changes.

Report Issue

Answer Description

Workload Identity works by letting a Kubernetes service account (KSA) impersonate a Google service account (GSA). The KSA's federated identity has the form serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]. To authorize that identity to act as the GSA, you grant the IAM role roles/iam.workloadIdentityUser on the GSA to the KSA principal. After this binding, Pods that use ksa-uploader can automatically exchange their projected token for a short-lived OAuth2 access token for gsa-uploader. Granting roles/iam.serviceAccountUser is used for attaching service accounts to resources such as VMs, not for Workload Identity. Granting bucket permissions alone does not establish impersonation, and mounting the GSA email in a secret provides no authentication mechanism.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.