GCP Professional Cloud Architect Practice Question

Your organization wants to let several GitHub Actions workflows deploy infrastructure to Google Cloud without storing any long-lived service account keys. Each repository must be isolated so that it can only impersonate its own deployment service account, and no repository should be able to elevate privileges outside the projects it manages. What is the most appropriate way to design Workload Identity Federation to satisfy these requirements while following the principle of least privilege and minimizing administrative overhead?

Create one Workload Identity pool without any providers and rely on the GitHub runner's default credentials to obtain user tokens through Application Default Credentials (ADC).
Create one Workload Identity pool and configure a separate OIDC provider for each GitHub repository, restrict each provider to its repository using attribute conditions, and bind only the matching provider to a dedicated service account that has the minimal roles needed for its project.
Create one Workload Identity pool with a single OIDC provider that trusts all repositories in the GitHub organization and grant that provider the Owner role on the organization so any repository can impersonate any service account.
Download a JSON key for a single organization-wide service account, store it as an encrypted secret in every GitHub repository, and use it with gcloud auth activate-service-account inside the workflow.

Report Issue

Answer Description

Workload Identity Federation lets external identities obtain short-lived, on-demand Google Cloud credentials by exchanging an external OIDC or SAML token for a Google short-lived access token. The recommended pattern for GitHub Actions is:

Create a single Workload Identity pool (one per enterprise is usually enough) and then create one provider per GitHub repository (or per environment). Each provider is configured to trust the GitHub OIDC issuer and to accept only tokens whose repository (and optionally ref) attribute matches the specific repo.
Create a dedicated service account for every repository. Grant that service account only the IAM roles required by the Terraform code for its target projects (for example, roles/editor on a specific project or finer-grained custom roles).
Add an IAM policy binding on each service account that allows the corresponding provider principal (principalSet://iam.googleapis.com/projects/…/locations/global/workloadIdentityPools/POOL/attribute.repository/owner/repo) to impersonate (roles/iam.workloadIdentityUser) that service account.
In each GitHub workflow, configure GOOGLE_WORKLOAD_IDENTITY_PROVIDER and GOOGLE_SERVICE_ACCOUNT environment variables so gcloud auth login --workload-identity-federation exchanges the GitHub OIDC token for short-lived credentials.

This design keeps a single administrative surface (one pool) but enforces strong isolation and least privilege through separate providers, attribute conditions, and per-repository service accounts. The other options either re-introduce long-lived keys, lack any provider at all, or assign overly broad IAM permissions that violate least-privilege.

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.