Federated authentication shows up on the Professional Cloud Architect exam as a question about how an organization moves to Google Cloud without re-issuing every user a new identity. The scenario is almost always the same: a company has an existing identity system, they want to keep using it, and they do not want passwords stored in GCP. Federated authentication is the answer.
Federated authentication lets users access GCP resources using credentials they already have at a trusted Identity Provider, or IdP. Instead of creating a new GCP-native account for every employee, you tell GCP to trust an external system like Okta, Microsoft Entra ID (formerly Azure Active Directory), or any IdP that speaks SAML 2.0 or OpenID Connect.
The flow is straightforward once you walk through it:
The password itself never reaches GCP. Only the signed token does. That is the property that makes federated authentication a clean answer to "do not store passwords in the cloud."
GCP supports both SAML 2.0 and OpenID Connect. For the Professional Cloud Architect exam you do not need to implement either protocol from scratch, but you do need to know that both exist and that GCP works with any IdP that speaks one of them. SAML 2.0 is the older, XML-based standard and is what most enterprise IdPs use for workforce identity. OIDC is the newer JSON-based standard built on top of OAuth 2.0 and is more common for consumer or mobile-style flows. If a question mentions Okta, Azure AD, ADFS, or "the corporate IdP," SAML is usually the implied protocol.
The exam scenario is consistent. An organization is migrating something to Google Cloud (a CRM, an internal app, a data warehouse) and the requirements include some combination of:
When you see those requirements together, the answer is federated authentication using SAML 2.0 with the existing IdP. It satisfies all four constraints in one configuration. Passwords stay at the IdP. Users log in with the credentials they already know. No retraining, no new accounts. And the IdP remains the authoritative source for identity, which means lifecycle events like joiners, movers, and leavers continue to flow from a single system.
One detail that trips people up: federated authentication only handles the "who is this user" question. It does not grant any permissions on its own. After the token is accepted, GCP still evaluates IAM policies to decide what the user can do. The federated identity gets mapped to a Google identity (or to a group), and IAM bindings on that identity or group determine access. So a typical setup pairs federated authentication with IAM groups, where group membership is also synced from the IdP.
Three things will get you through any federated authentication question:
If a question gives you a "no passwords in the cloud" constraint and an existing IdP like Okta or Azure AD, federated authentication using SAML 2.0 is the answer. Every time.
My Professional Cloud Architect course covers federated authentication alongside the rest of the IAM and governance material.
