GCP Professional Cloud Architect Practice Question

Your organization uses a central CI/CD project on GCP to build and deploy applications to several production projects. A new security policy forbids storing any long-lived service account keys in Cloud Build. Instead, the security team mandates that build jobs obtain short-lived OAuth 2.0 access tokens for a dedicated deploy-service-account in each production project. Only the Cloud Build runtime service account in the CI/CD project should be able to obtain these tokens; developers must not get direct access to the deploy-service-account even if they can trigger builds.

Which design satisfies these requirements with the least operational overhead while following Google-recommended practices?

Grant roles/iam.serviceAccountTokenCreator on each production deploy-service-account to the Cloud Build runtime service account, then configure build steps to run gcloud commands with the --impersonate-service-account flag when deploying.
Store a JSON key for each deploy-service-account in Secret Manager and have Cloud Build retrieve and activate the key during the deploy stage.
Grant the Cloud Build runtime service account the roles/run.admin role directly in every production project so it can deploy without impersonation.
Create a Workload Identity Federation pool that maps Cloud Build to the deploy-service-account, and configure each build step to obtain federated credentials from the pool.

Report Issue

Answer Description

Service account impersonation lets a caller obtain short-lived OAuth 2.0 tokens for another service account without downloading or storing a private key. To allow Cloud Build to impersonate a target service account, you grant the Cloud Build runtime principal the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on that specific service account. At build time you instruct gcloud (or the Cloud Build step) to use --impersonate-service-account, which exchanges Cloud Build's own credentials for a short-lived token bound to the deploy-service-account. No key files are created, satisfying the policy, and because the role is granted only to the Cloud Build service account, individual developers cannot impersonate the deploy-service-account directly.

Incorrect options:

Storing JSON keys in Secret Manager still violates the "no long-lived keys" policy.
Granting roles/run.admin directly to the Cloud Build service account avoids keys but gives excessive, organization-wide privileges and does not enforce short-lived tokens.
Workload Identity Federation targets external (non-GCP) workloads; it is not required when both the caller and the target service account are in Google Cloud.

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.