A security engineer is designing an authentication architecture for enterprise workloads running in Amazon Web Services (AWS) and Microsoft Azure that need to access Cloud Storage buckets in Google Cloud. To comply with organizational security policies, the architecture must satisfy the following requirements: Eliminate the generation, distribution, and maintenance of downloadable, long-lived service account private keys. Authenticate external workloads using ephemeral, short-lived Google Cloud access tokens. Implement granular access control by mapping external identity attributes to Google Cloud Identity and Access Management (IAM) policies. Which solution should the engineer implement to meet these requirements?

Create a Workload Identity Pool with AWS and OIDC providers, define attribute mappings for external tokens, and grant IAM roles directly to federated principal sets or configure service account impersonation via the Security Token Service.: ### What Workload Identity Federation is **Workload Identity Federation** is a Google Cloud IAM capability that enables workloads running outside Google Cloud (such as in AWS, Microsoft Azure, GitHub Actions, or on-premises environments) to impersonate service accounts or directly access Google Cloud resources by exchanging external identity tokens for short-lived, ephemeral Google Cloud access tokens. ### How it meets the requirements - **Eliminating long-lived service account keys**: Workloads do not require downloadable `.json` service account keys stored on external infrastructure. Trust is established cryptographically via identity federation. - **Ephemeral token exchange**: The external workload requests a native identity token (such as an AWS STS signed request or an Azure Microsoft Entra ID OIDC token) and sends it to the Google Cloud **Security Token Service (STS)**, which validates the token against the **Workload Identity Provider** and returns a temporary OAuth 2.0 access token. - **Granular attribute mapping**: Workload Identity Federation maps claims from external tokens (such as AWS ARN, Azure Tenant ID, or custom claims) to Google Cloud attributes (such as `google.subject`, `google.groups`, or `attribute.custom_name`), allowing access to be bound directly to specific `principalSet://` strings in IAM allow policies. ### Key advantages - **Zero credential storage**: Eliminates key lifecycle overhead, rotation scripts, and exposure vectors. - **Direct resource access**: Supports direct resource-level role grants using `principal://` and `principalSet://` without requiring service account impersonation. - **Least privilege enforcement**: Supports **Attribute Conditions** using Common Expression Language (CEL) to filter which external identities can authenticate. ### Why this is optimal This approach aligns with Google Cloud security best practices by eliminating static secrets while preserving fine-grained authorization across hybrid and multi-cloud architectures.

Workload Identity Federation Ephemeral Tokens | Professional Cloud Security Engineer

Workload Identity Federation Ephemeral Tokens

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 engineer is designing an authentication architecture for enterprise workloads running in Amazon Web Services (AWS) and Microsoft Azure that need to access Cloud Storage buckets in Google Cloud.

To comply with organizational security policies, the architecture must satisfy the following requirements:

Eliminate the generation, distribution, and maintenance of downloadable, long-lived service account private keys.
Authenticate external workloads using ephemeral, short-lived Google Cloud access tokens.
Implement granular access control by mapping external identity attributes to Google Cloud Identity and Access Management (IAM) policies.

Which solution should the engineer implement to meet these requirements?

Create a Workload Identity Pool in TRUST_DOMAIN mode, issue mutual TLS (mTLS) certificates using Certificate Authority Service, and deploy the certificates to the AWS and Azure workloads for direct Google Cloud API authentication.

Create a Workload Identity Pool with AWS and OIDC providers, define attribute mappings for external tokens, and grant IAM roles directly to federated principal sets or configure service account impersonation via the Security Token Service.

Configure a Workforce Identity Pool with SAML 2.0 assertions, synchronize external AWS and Azure identities using Google Cloud Directory Sync (GCDS), and assign individual users IAM roles.

Generate user-managed service account keys for each external workload, store the private keys in an encrypted secret vault, and write a scheduled Cloud Function to rotate and distribute the keys every 24 hours.

Professional Cloud Security Engineer

Workload Identity Federation Ephemeral Tokens

Related questions