An enterprise uses an external continuous deployment (CD) pipeline to deploy build artifacts into a specific Google Cloud Storage bucket (bucket-prod-artifacts). The designated service account (deployer-sa@project-id.iam.gserviceaccount.com) has the Storage Object Admin role at the project level. To adhere to least-privilege security principles, the security engineer must implement a solution that fulfills the following requirements: The external pipeline workload must authenticate securely without using downloadable, long-lived service account keys. Only the specific external pipeline identity mapped in the Workload Identity Pool is permitted to impersonate deployer-sa. The short-lived OAuth 2.0 access token issued for each pipeline execution must be restricted so that it can only read and write objects within bucket-prod-artifacts, preventing access to any other buckets. Which strategy should the security engineer implement?

Grant the external principal identifier the Workload Identity User role (`roles/iam.workloadIdentityUser`) on `deployer-sa`, and generate a downscoped access token by applying a Credential Access Boundary definition that limits access to `bucket-prod-artifacts`.: ### What this solution is This solution combines **Workload Identity Federation** with **Service Account Impersonation** and **Token Downscoping** using **Credential Access Boundaries** to enforce strict least-privilege access for external workloads. ### How it meets the requirements - **Eliminating long-lived service account keys**: Workload Identity Federation exchanges external identity credentials (such as OIDC tokens from GitHub Actions or GitLab CI) for temporary Google Cloud credentials, completely removing the need to generate or store downloadable JSON private keys. - **Securing service account impersonation**: Granting `roles/iam.workloadIdentityUser` directly on `deployer-sa` to a specific principal identifier (`principal://iam.googleapis.com/.../subject/PIPELINE_ID`) ensures that only the authorized external CI/CD workflow can impersonate the service account. - **Restricting token scope to a specific bucket**: A **Credential Access Boundary** downscopes the short-lived OAuth 2.0 access token at generation time. Even though `deployer-sa` has broad project-level permissions, the downscoped token is mathematically and logically restricted to interact only with `bucket-prod-artifacts` and execute only the specified storage actions. ### Key advantages - **Zero credential management overhead**: Eliminates the lifecycle management, exposure risks, and rotation burdens of static service account private keys. - **Fine-grained runtime containment**: Downscoping prevents compromised pipeline steps or unintended scripts from accessing unauthorized buckets within the project. - **Auditable identity chain**: Cloud Audit Logs capture both the federated workload principal and the impersonated service account identity in access logs. - **Dynamic permission restriction**: Downscoping rules are passed during token exchange without requiring permanent modifications to the underlying IAM policy bindings of the service account. ### Why this is optimal Using `roles/iam.workloadIdentityUser` on the service account combined with token downscoping represents the architectural best practice for external CI/CD systems interacting with sensitive cloud resources. It decouples high-level service account grants from runtime execution privileges.

Service Account Impersonation Token Downscoping | Professional Cloud Security Engineer

Service Account Impersonation Token Downscoping

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 uses an external continuous deployment (CD) pipeline to deploy build artifacts into a specific Google Cloud Storage bucket (bucket-prod-artifacts). The designated service account (deployer-sa@project-id.iam.gserviceaccount.com) has the Storage Object Admin role at the project level.

To adhere to least-privilege security principles, the security engineer must implement a solution that fulfills the following requirements:

The external pipeline workload must authenticate securely without using downloadable, long-lived service account keys.
Only the specific external pipeline identity mapped in the Workload Identity Pool is permitted to impersonate deployer-sa.
The short-lived OAuth 2.0 access token issued for each pipeline execution must be restricted so that it can only read and write objects within bucket-prod-artifacts, preventing access to any other buckets.

Which strategy should the security engineer implement?

Download an encrypted service account private key file, store it in the external pipeline secrets store, and enforce token restriction using an Organization Policy constraint.

Grant the external principal identifier the Service Account User role (roles/iam.serviceAccountUser) at the project level, and apply an IAM Condition on the project binding targeting bucket-prod-artifacts.

Grant the external principal identifier the Workload Identity User role (roles/iam.workloadIdentityUser) on deployer-sa, and generate a downscoped access token by applying a Credential Access Boundary definition that limits access to bucket-prod-artifacts.

Grant the external principal identifier the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on the Cloud Storage bucket, and configure an IAM Deny Policy on the project.

Professional Cloud Security Engineer

Service Account Impersonation Token Downscoping

Related questions