LEARN. PRACTICE. GROW.Concept and mechanism
Workload Identity Federation connects an external identity to Google Cloud access without distributing a long-lived JSON key. Trust must identify the authorized origin and execution context. Accepting every repository in an organization can include labs that should not publish to production. Workforce Identity Federation addresses users; do not use the two names interchangeably. Impersonation obtains temporary service-account credentials when the caller has suitable authorization. The target operation then uses permissions of the represented identity. Successful token issuance does not prove the account can read a bucket or publish to the intended service.
Guided application
For a release pipeline, write two contracts: who may obtain access and which actions that identity may perform. Restrict attributes and conditions to approved context, using stable and verifiable attributes where available. Also limit roles and target resources. The rehearsal must confirm the correct pipeline and reject a similar but unauthorized origin. If a lab has already acted in production, correcting trust does not replace investigating earlier actions or still-valid credentials. Coordinate response with the incident team and preserve authorized publishing, using an approved temporary suspension when needed. Document results so later changes do not reintroduce broad trust.
An acceptance matrix includes the authorized production repository, allowed branch or environment, and denied lab origins, with evidence for each result.
Common pitfalls
Short-lived tokens treated as sufficient authorization; Workforce confused with Workload; only positive tests; broad trust disguised by account names.
Related topics: Projects, context, quotas, and costs · Compute, interruptions, and declarative changes
Temporary credentials help lifecycle management; trust and authorization still need boundaries.
Reference: Workload Identity Federation · Standard exam guide linked 2026-09-29; edition date unconfirmed