A consultancy's staff are managed in an external identity provider (Okta). They need short-term interactive access to the Google Cloud console and gcloud, and your company does not want to create or synchronise Cloud Identity accounts for them. Which approach fits this requirement?
- ACreate a Cloud Identity user account for every consultant, grant the needed roles, and delete each account when the engagement finishes.
- BConfigure Workforce Identity Federation with an Okta pool so the consultants sign in with their existing Okta identities and receive short-lived Google Cloud access. Correct
- CConfigure Workload Identity Federation to map the consultants' Okta identities onto a service account they use for the console.
- DCreate one shared service account, generate a key for it, and distribute that key to all of the consultants for the duration.
Why A is wrong: Tempting because it clearly works, but it is exactly the account provisioning and lifecycle overhead the requirement rules out, and it duplicates identities already managed in Okta.
Why B is correct: Correct because Workforce Identity Federation is built for external human workforces: users authenticate through the external IdP and receive short-lived credentials, with no Cloud Identity accounts to create or sync.
Why C is wrong: Tempting because it also federates external identities without new accounts, but Workload Identity Federation is designed for workloads and applications, not interactive human sign-in to the console.
Why D is wrong: Tempting because it avoids per-person accounts, but sharing one service account key destroys per-user attribution and is a well-known security anti-pattern that GCP guidance warns against.