A security architect is configuring Workload Identity Federation to allow external CI/CD pipelines running on a third-party OpenID Connect (OIDC) identity provider to access Google Cloud resources without using service account keys. The incoming OIDC ID token contains the following claims: sub: A unique subject string (under 127 bytes) repository_owner: The organization owning the repository (e.g., example-org) ref: The branch reference (e.g., refs/heads/main) environment: The deployment target environment (e.g., production) The security requirements are: Tokens must be validated and filtered at the Workload Identity Pool Provider level so that only pipelines owned by example-org targeting production can exchange tokens for Google Cloud credentials. The external claims must be translated into Google Cloud attributes to allow granular access control in IAM policies without relying on static service account keys. Downstream IAM policies must grant access specifically to all production workloads within the pool. Which configuration strategy should the architect implement?

Configure the OIDC provider with `--attribute-mapping="google.subject=assertion.sub,attribute.owner=assertion.repository_owner,attribute.env=assertion.environment"`, set the `--attribute-condition="assertion.repository_owner == 'example-org' && assertion.environment == 'production'"`, and grant IAM roles to the principal set `principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.env/production`.: ### What Workload Identity Federation Attribute Mapping and Conditions Are **Workload Identity Federation** allows external workloads (such as third-party CI/CD runners, Kubernetes clusters, or multi-cloud services) to authenticate to Google Cloud by exchanging external OIDC or SAML assertions for short-lived Google Cloud federated tokens. **Attribute mappings** define how incoming token claims (`assertion.CLAIM_NAME`) map to standard Google attributes (`google.subject`) and custom attributes (`attribute.CUSTOM_NAME`). **Attribute conditions** use Common Expression Language (CEL) expressions evaluated by Google Cloud's Security Token Service (STS) to validate and filter assertions before issuing any federated credentials. ### How It Meets the Requirements - **Provider-level token filtering:** Setting `--attribute-condition="assertion.repository_owner == 'example-org' && assertion.environment == 'production'"` ensures that the Workload Identity Pool Provider evaluates the incoming OIDC token assertions upon receipt. If the workload is not from `example-org` or is not deploying to `production`, STS immediately rejects the exchange request and refuses to issue a token. - **Translating external tokens into Google credentials:** The `--attribute-mapping` flag maps `google.subject=assertion.sub` (ensuring unique principal identity tracking under 127 bytes) and creates custom attributes `attribute.owner` and `attribute.env` from `assertion.repository_owner` and `assertion.environment` respectively. - **Granular IAM access via principal sets:** Granting the role directly to `principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.env/production` ensures that any authenticated identity carrying the mapped `attribute.env` value of `production` from that pool receives the necessary IAM permissions without managing long-lived keys. ### Key Advantages and Capabilities - **Elimination of secret management:** Eliminates the lifecycle overhead and leakage risk of user-managed service account keys. - **Fail-closed perimeter security:** Provider-level attribute conditions stop unauthorized tokens at the STS boundary before they ever touch IAM or resource APIs. - **Contextual and granular IAM bindings:** Allows security teams to bind IAM roles to specific principal sets based on custom mapped attributes like branch, repository, or environment. - **Auditability:** Mapped `google.subject` attributes appear directly in Cloud Audit Logs to provide traceability for every external workload action. ### Why This Is Optimal Evaluating attribute conditions at the provider level minimizes security exposure and computational overhead by rejecting untrusted pipelines immediately. Leveraging mapped custom attributes in IAM principal sets ensures a least-privilege access model without creating individual service accounts or keys for each repository.

Workload Identity Attribute Mapping Policy Configuration | Professional Cloud Security Engineer

Workload Identity Attribute Mapping Policy Configuration

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.

A security architect is configuring Workload Identity Federation to allow external CI/CD pipelines running on a third-party OpenID Connect (OIDC) identity provider to access Google Cloud resources without using service account keys.

The incoming OIDC ID token contains the following claims:

sub: A unique subject string (under 127 bytes)
repository_owner: The organization owning the repository (e.g., example-org)
ref: The branch reference (e.g., refs/heads/main)
environment: The deployment target environment (e.g., production)

The security requirements are:

Tokens must be validated and filtered at the Workload Identity Pool Provider level so that only pipelines owned by example-org targeting production can exchange tokens for Google Cloud credentials.
The external claims must be translated into Google Cloud attributes to allow granular access control in IAM policies without relying on static service account keys.
Downstream IAM policies must grant access specifically to all production workloads within the pool.

Which configuration strategy should the architect implement?

Generate a user-managed service account key, store it securely in Google Cloud Secret Manager, and configure the external CI/CD runners to retrieve the key dynamically at runtime to authenticate to Google APIs.

Configure the OIDC provider with --attribute-mapping="google.subject=assertion.sub+assertion.repository_owner+assertion.environment", omit custom attribute mappings, and grant IAM roles directly to the entire pool using principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*.

Configure the OIDC provider with --attribute-mapping="google.subject=assertion.sub,attribute.owner=assertion.repository_owner,attribute.env=assertion.environment", set the --attribute-condition="assertion.repository_owner == 'example-org' && assertion.environment == 'production'", and grant IAM roles to the principal set principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.env/production.

Configure the OIDC provider with --attribute-mapping="attribute.owner=assertion.repository_owner,attribute.env=assertion.environment", omit the provider --attribute-condition, and enforce the filtering logic exclusively using IAM Conditions on individual service accounts.

Professional Cloud Security Engineer

Workload Identity Attribute Mapping Policy Configuration

Related questions