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.

StudyCerts

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Service Account Impersonation Token Downscoping

Section: Managing and creating short-lived credentials.

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 Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on the Cloud Storage bucket, and configure an IAM Deny Policy on the project.

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 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 User role (roles/iam.serviceAccountUser) at the project level, and apply an IAM Condition on the project binding targeting bucket-prod-artifacts.

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Service Account Impersonation Token Downscoping

Section: Managing and creating short-lived credentials.

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.

Explanations

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.

View source documentation

Professional Cloud Security Engineer

Service Account Impersonation Token Downscoping

Professional Cloud Security Engineer

Service Account Impersonation Token Downscoping

What this solution is

How it meets the requirements

Key advantages

Why this is optimal

Related questions