Question

Difficulty: Very hardCreating and Managing Service Accounts

An organization runs an enterprise application on Google Kubernetes Engine (GKE) in `project-app-prod`. The application needs to read objects from a Cloud Storage bucket located in a separate project, `project-data-shared`. Security policies strictly mandate adherence to the principle of least privilege and prohibit creating or downloading long-lived service account private keys (`.json` key files). Which of the following configuration steps must you perform to grant the application keyless cross-project access securely? (Select TWO.)

  1. Grant the predefined Cloud Storage Object Viewer role (`roles/storage.objectViewer`) to the Google Service Account directly on the target Cloud Storage bucket in `project-data-shared`.Answer
  2. Bind the Kubernetes Service Account (KSA) to the Google Service Account (GSA) by granting the `roles/iam.workloadIdentityUser` role on the GSA to the KSA principal member.Answer
  3. C
    Create and export a JSON private key file for the Google Service Account, mounting it as a secret inside the GKE pod container environment.
  4. D
    Grant the primitive Owner role (`roles/owner`) to the Google Service Account at the `project-data-shared` project level to ensure full permission inheritance across all buckets.
  5. E
    Enable the Google Kubernetes Engine API in `project-data-shared` instead of `project-app-prod` so that cross-project identity token exchange can be processed.

Answer

To securely enable cross-project access without static credentials, you must grant the Google Service Account the predefined Cloud Storage Object Viewer role (`roles/storage.objectViewer`) on the target bucket in `project-data-shared`, and bind the Kubernetes Service Account to the Google Service Account using the `roles/iam.workloadIdentityUser` role.
The combination of granting the `roles/iam.workloadIdentityUser` role on the Google Service Account to the Kubernetes Service Account and assigning `roles/storage.objectViewer` directly on the destination storage bucket establishes a secure, keyless cross-project authentication path adhering strictly to least privilege.

Step-by-Step Solution

1
Configure Workload Identity mapping between Kubernetes and Google Cloud IAM.
The Kubernetes Service Account (KSA) used by the GKE deployment is granted the `roles/iam.workloadIdentityUser` role on the Google Service Account (GSA).
This allows GKE pods to automatically request short-lived Google OAuth2 tokens without needing downloadable static JSON keys.
2
Assign targeted IAM permissions on the destination Cloud Storage resource.
The GSA is granted `roles/storage.objectViewer` on the specific Cloud Storage bucket inside `project-data-shared`.
Applying predefined roles directly on the target resource enforces least privilege and avoids granting excessive project-wide permissions.

Key Concept

Cross-Project Service Account Management and Workload Identity
Rate this question