An enterprise is deploying an automated, non-interactive data processing pipeline to a Google Kubernetes Engine (GKE) cluster. The pipeline runs scheduled nightly jobs and microservices that query BigQuery datasets and write report outputs to Cloud Storage buckets without human intervention. Security policy requires that: Automated workloads must authenticate using non-human identities with the principle of least privilege. No long-lived downloadable service account keys (JSON files) may be generated or stored in cluster secrets. Workloads must not inherit the broad ambient permissions assigned to the underlying GKE cluster nodes. Which identity configuration should the security team implement to satisfy these requirements?

Configure GKE Workload Identity by binding the roles/iam.workloadIdentityUser role on a dedicated Google Service Account to the Kubernetes Service Account, and annotating the Kubernetes Service Account.: ### What GKE Workload Identity Is **GKE Workload Identity** is the recommended, best-practice mechanism for granting non-interactive, automated containerized workloads on Google Kubernetes Engine access to Google Cloud APIs. It enables a **Kubernetes Service Account (KSA)** running within a specific namespace to securely impersonate a **Google Service Account (GSA)** without requiring static credentials or JSON private keys. ### How It Meets the Requirements - **Automated, non-human identity**: Workload Identity allows automated pods to obtain short-lived, auto-rotating OAuth 2.0 access tokens directly from the GKE metadata server, eliminating any requirement for human user credentials or interactive logins. - **No static private keys**: Because authentication is mediated by the GKE metadata server via the Workload Identity pool (`$PROJECT_ID.svc.id.goog`), administrators do not need to generate, manage, or store long-lived JSON service account key files in Kubernetes Secrets. - **Least-privilege separation from node credentials**: Each pod gets its own distinct identity based on its assigned KSA. Permissions are scoped strictly to the linked GSA rather than relying on or exposing the underlying Compute Engine VM node service account. ### Key Advantages and Capabilities - **Role-based binding**: Grants the `roles/iam.workloadIdentityUser` IAM role on the target GSA specifically to the principal member string `serviceAccount:$PROJECT_ID.svc.id.goog[$NAMESPACE/$KSA_NAME]`. - **Kubernetes metadata annotation**: Connects the KSA to the target GSA using the `iam.gke.io/gcp-service-account=$GSA_NAME@$PROJECT_ID.iam.gserviceaccount.com` annotation. - **Automatic credential rotation**: Access tokens generated for pods are short-lived and automatically refreshed by the Google Cloud client libraries and metadata server. - **Comprehensive auditability**: Cloud Audit Logs capture the exact Google Service Account identity performing BigQuery queries and Cloud Storage operations. ### Why This Is Optimal Workload Identity completely eliminates the attack surface associated with credential exfiltration from local pod storage, enforces strong workload isolation across namespaces, and natively supports non-interactive execution for automated pipelines.

Gke Automated Workload Identity Service Accounts | Professional Cloud Security Engineer

Gke Automated Workload Identity Service Accounts

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise is deploying an automated, non-interactive data processing pipeline to a Google Kubernetes Engine (GKE) cluster. The pipeline runs scheduled nightly jobs and microservices that query BigQuery datasets and write report outputs to Cloud Storage buckets without human intervention.

Security policy requires that:

Automated workloads must authenticate using non-human identities with the principle of least privilege.
No long-lived downloadable service account keys (JSON files) may be generated or stored in cluster secrets.
Workloads must not inherit the broad ambient permissions assigned to the underlying GKE cluster nodes.

Which identity configuration should the security team implement to satisfy these requirements?

Configure GKE Workload Identity by binding the roles/iam.workloadIdentityUser role on a dedicated Google Service Account to the Kubernetes Service Account, and annotating the Kubernetes Service Account.

Provision user-managed service account private keys (JSON), store them in Secret Manager, and mount them as files inside the pipeline containers.

Assign the required BigQuery and Cloud Storage IAM roles directly to the GKE node pool Compute Engine default service account.

Generate OAuth 2.0 user refresh tokens using developer credentials and store them in Kubernetes Secrets for the background jobs to consume.

Professional Cloud Security Engineer

Gke Automated Workload Identity Service Accounts

Related questions