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.

Access GCS From AWS and Azure Without Stored Keys

Federated Access to Cloud Storage Without Service Account Keys

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?

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.

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.

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.

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.

Explanations

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.

What this option does

This option relies on generating downloadable service account keys (asymmetric RSA private keys), storing them in a secrets management service (such as HashiCorp Vault or Google Cloud Secret Manager), and automating their rotation via scheduled Cloud Functions.

Why it doesn't meet the requirement

Fails the zero-key policy: It continues to generate and deploy long-lived, downloadable private key files (.json credential files) across external cloud environments.
Increased operational complexity and risk: Automated rotation of physical key files does not make the credentials ephemeral. If an active key is exposed before rotation, unauthorized access remains possible until the key is manually revoked or deleted.
Lack of federated identity attribution: Google Cloud IAM sees actions originating exclusively from the static service account rather than linking each API call directly to verified external identity metadata.

Key limitations

Service account keys introduce severe security risks, including leakages into source control and build logs.
Key distribution across third-party environments creates synchronization latency and operational fragility.

This answer would be correct if

The workloads ran in legacy environments that do not support OpenID Connect (OIDC) or native cloud identity metadata systems and have no viable mechanism for federated token exchange.

View source documentation

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.

View source documentation

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.

What Managed Workload Identities are

Managed Workload Identities in TRUST_DOMAIN mode allow Google Cloud workloads (such as Compute Engine instances) to obtain strongly attested identities and Certificate Authority Service (CAS) provisioned certificates to perform mutual TLS (mTLS) authentication between services.

Why it doesn't meet the requirement

Incompatible with Google Cloud API authentication: Certificates issued through managed workload identities are strictly intended for peer-to-peer workload mTLS communication and cannot be used to authenticate requests to Google Cloud APIs.
Scope limitation: Managed workload identities in TRUST_DOMAIN mode are designed for workloads within Google Cloud Compute Engine, not for exchanging native AWS STS or Azure Entra ID OIDC tokens from external clouds.

Key characteristics

Managed workload identity pools in TRUST_DOMAIN mode issue X.509 certificates via private CA pools for internal mesh/service-to-service mTLS.
Workload Identity Federation with external providers (AWS/OIDC/SAML) is the standard mechanism to exchange external tokens for short-lived Google Cloud OAuth 2.0 access tokens to call Google Cloud APIs.

This answer would be correct if

The goal was to establish mutual TLS (mTLS) service-to-service encryption and workload attestation between internal Compute Engine virtual machines.

View source documentation

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.

What Workforce Identity Federation is

Workforce Identity Federation is designed to allow human users (such as corporate employees, contractors, and partners) in an external Identity Provider (IdP) like Microsoft Entra ID or Okta to authenticate into the Google Cloud console and Google Cloud CLI without needing separate Google Workspace or Cloud Identity user accounts.

Why it doesn't meet the requirement

Target audience mismatch: Workforce Identity Federation applies to human users, whereas automated applications and non-human services running in AWS and Azure require Workload Identity Federation.
Unnecessary directory synchronization: Google Cloud Directory Sync (GCDS) is used to sync Active Directory/LDAP users into Cloud Identity/Google Workspace accounts. Workload authentication does not use GCDS.
Programmatic application compatibility: Automated workloads running batch jobs and API calls cannot utilize interactive workforce authentication flows intended for end-user logins.

Key characteristics

Workforce Identity Federation manages corporate human identities.
Workload Identity Federation manages machine and application workloads across cloud platforms and CI/CD pipelines.

This answer would be correct if

Human administrators and engineers in an external enterprise directory needed single sign-on (SSO) access to the Google Cloud Console and Google Cloud CLI.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Federated Access to Cloud Storage Without Service Account Keys

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?

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.

Explanations

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.

What this option does

Why it doesn't meet the requirement

Fails the zero-key policy: It continues to generate and deploy long-lived, downloadable private key files (.json credential files) across external cloud environments.
Increased operational complexity and risk: Automated rotation of physical key files does not make the credentials ephemeral. If an active key is exposed before rotation, unauthorized access remains possible until the key is manually revoked or deleted.
Lack of federated identity attribution: Google Cloud IAM sees actions originating exclusively from the static service account rather than linking each API call directly to verified external identity metadata.

Key limitations

Service account keys introduce severe security risks, including leakages into source control and build logs.
Key distribution across third-party environments creates synchronization latency and operational fragility.

This answer would be correct if

The workloads ran in legacy environments that do not support OpenID Connect (OIDC) or native cloud identity metadata systems and have no viable mechanism for federated token exchange.

View source documentation

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

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.

View source documentation

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.

What Managed Workload Identities are

Why it doesn't meet the requirement

Incompatible with Google Cloud API authentication: Certificates issued through managed workload identities are strictly intended for peer-to-peer workload mTLS communication and cannot be used to authenticate requests to Google Cloud APIs.
Scope limitation: Managed workload identities in TRUST_DOMAIN mode are designed for workloads within Google Cloud Compute Engine, not for exchanging native AWS STS or Azure Entra ID OIDC tokens from external clouds.

Key characteristics

Managed workload identity pools in TRUST_DOMAIN mode issue X.509 certificates via private CA pools for internal mesh/service-to-service mTLS.
Workload Identity Federation with external providers (AWS/OIDC/SAML) is the standard mechanism to exchange external tokens for short-lived Google Cloud OAuth 2.0 access tokens to call Google Cloud APIs.

This answer would be correct if

The goal was to establish mutual TLS (mTLS) service-to-service encryption and workload attestation between internal Compute Engine virtual machines.

View source documentation

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.

What Workforce Identity Federation is

Why it doesn't meet the requirement

Target audience mismatch: Workforce Identity Federation applies to human users, whereas automated applications and non-human services running in AWS and Azure require Workload Identity Federation.
Unnecessary directory synchronization: Google Cloud Directory Sync (GCDS) is used to sync Active Directory/LDAP users into Cloud Identity/Google Workspace accounts. Workload authentication does not use GCDS.
Programmatic application compatibility: Automated workloads running batch jobs and API calls cannot utilize interactive workforce authentication flows intended for end-user logins.

Key characteristics

Workforce Identity Federation manages corporate human identities.
Workload Identity Federation manages machine and application workloads across cloud platforms and CI/CD pipelines.

This answer would be correct if

Human administrators and engineers in an external enterprise directory needed single sign-on (SSO) access to the Google Cloud Console and Google Cloud CLI.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Federated Access to Cloud Storage Without Service Account Keys

Explanations

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.

What this option does

Why it doesn't meet the requirement

Key limitations

This answer would be correct if

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

How it meets the requirements

Key advantages

Why this is optimal

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.

What Managed Workload Identities are

Why it doesn't meet the requirement

Key characteristics

This answer would be correct if

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.

What Workforce Identity Federation is

Why it doesn't meet the requirement

Key characteristics

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

IAM Service Account Credentials API Methods

Workload Identity Federation with Credential Access Boundaries

Dynamic Groups and Locked Groups

Policy Analyzer IAM Access Analysis

Log Sink CMEK and VPC Service Controls

Artifact Registry Toolchain Version Pinning

Federated Access to Cloud Storage Without Service Account Keys

Explanations

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.

What this option does

Why it doesn't meet the requirement

Key limitations

This answer would be correct if

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

How it meets the requirements

Key advantages

Why this is optimal

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.

What Managed Workload Identities are

Why it doesn't meet the requirement

Key characteristics

This answer would be correct if

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.

What Workforce Identity Federation is

Why it doesn't meet the requirement

Key characteristics

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

IAM Service Account Credentials API Methods

Workload Identity Federation with Credential Access Boundaries

Dynamic Groups and Locked Groups

Policy Analyzer IAM Access Analysis

Log Sink CMEK and VPC Service Controls

Artifact Registry Toolchain Version Pinning