1. A company uses Workload Identity Federation to allow an on-premises application (using an OIDC-compatible identity provider) to access Google Cloud APIs without service account keys. The application is intermittently receiving PERMISSION_DENIED errors even though the Workload Identity Pool and provider are configured correctly. Which configuration issue is MOST likely causing the problem?
- A. The on-premises OIDC token has expired before being exchanged for a Google OAuth 2.0 token at the Security Token Service (STS)
- B. The service account that the federated identity impersonates does not have the roles/iam.workloadIdentityUser role granted to the correct principal identifier from the pool✓ Correct
- C. Workload Identity Federation requires a VPN connection between on-premises and Google Cloud for the STS endpoint to be reachable
- D. The attribute mapping in the Workload Identity Pool provider does not include google.subject, causing identity resolution to fail completely for all requests
Explanation
The most common misconfiguration in Workload Identity Federation — especially when setup appears correct but access is denied — is the service account impersonation binding. The federated identity must be granted roles/iam.workloadIdentityUser on the target service account, and the principal must be specified using the exact format: principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE. A mismatch in this principal identifier (e.g., wrong attribute mapping or pool ID) causes PERMISSION_DENIED. A (Token expiry) is wrong — While OIDC tokens do expire, an expiry would cause the STS exchange to fail with an authentication error or a more specific token-related error, not an intermittent PERMISSION_DENIED on the final Google API call. The STS exchange is a separate step. C (VPN required) is wrong — Workload Identity Federation uses the public STS endpoint (sts.googleapis.com); no VPN is required. This is a fundamental misunderstanding of how WIF works. D (Missing google.subject mapping) is wrong — A completely missing google.subject mapping would cause all authentications to fail consistently, not intermittently. The question specifies intermittent failures, pointing to a binding/attribute-matching issue, not a total configuration failure.