One of the recurring patterns on the Professional Cloud Architect exam is a company moving an application to Google Cloud while needing to keep using whatever identity system it already has. Active Directory, Okta, Ping, ADFS, some other SAML provider. The exam keeps coming back to this because it is what most real migrations look like. The company already has thousands of users, password policies, MFA enrollment, and HR processes that create and offboard accounts. None of that gets thrown away just because workloads are moving to GCP.
This article walks through how Cloud Identity fits into that picture, what federated authentication with SAML 2.0 actually means in practice, and how to recognize the right answer on the exam when you see one of these scenarios.
Cloud Identity is Google's standalone identity service. It gives you a place to manage users, groups, and devices that need to access Google Cloud resources. If your organization uses Google Workspace, you already have a Cloud Identity tenant baked in. If you do not use Workspace, you can sign up for Cloud Identity on its own at no cost for the basic tier.
The thing to understand is that Cloud Identity is the source of truth for who exists in Google's view. Every IAM binding on a GCP project ultimately points at a principal that lives in Cloud Identity or a Workspace domain. When you grant roles/storage.objectViewer to alice@example.com, that email has to resolve to an identity Google knows about.
That last point is what makes federation interesting. The identity has to exist in Cloud Identity, but the password does not have to live there.
Federation means delegating authentication to an external system. The user goes to log in to a Google service, Google says I do not handle the password for this account, and redirects the browser to the company's identity provider. The IdP authenticates the user using whatever method it is configured for, then sends a signed SAML assertion back to Google saying yes, this is alice. Google trusts the assertion because it has the IdP's signing certificate on file, and the user is logged in.
SAML 2.0 is the protocol that defines how those redirects and assertions work. It has been the standard for enterprise SSO for over a decade, and every serious IdP supports it. Cloud Identity supports SAML 2.0 as the federation protocol when you set up SSO.
The practical effect is that passwords never leave the existing IdP. Google never sees them, never stores them, never resets them. Password policies, MFA challenges, conditional access rules, and account lockouts all happen at the IdP. From the user's perspective, they go to a Google login page, get bounced to their company's existing login page, sign in the way they always have, and end up logged into Google Cloud.
The PCA exam keeps testing the same pattern. A company is moving some application to GCP. It already has an identity provider. It has constraints like:
The right answer to all of these is the same. Set up federated authentication using SAML 2.0 between Cloud Identity and the existing IdP. The wrong answers tend to be:
The OAuth versus SAML distinction is worth slowing down on. The exam often pairs them in the same question to see if you can tell them apart. SAML 2.0 answers who is this user. OAuth answers what is this app allowed to do on behalf of a user. Both are standards. They solve different problems.
Once federation is set up, the user accounts still need IAM bindings to actually do anything in GCP. Federation gets them logged in. IAM decides what they can touch.
The clean pattern is to provision groups in the IdP, sync them to Cloud Identity using Google Cloud Directory Sync or a similar tool, and bind IAM roles to those groups. When someone joins the engineering team in the IdP, they automatically pick up the engineering Google group, which already has the IAM bindings it needs across the GCP organization. When someone leaves, the IdP removes them, the sync removes them from the group, and their access disappears.
This is the structure the exam expects you to recognize. Authentication via SAML 2.0, identity sync via Cloud Directory Sync, authorization via IAM bindings on groups. Each piece has a clear job.
One small detail that occasionally shows up. Cloud Identity and Workspace are not separate products in the way it sometimes sounds. Workspace includes Cloud Identity as the underlying identity layer plus the productivity apps like Gmail, Drive, and Docs. Cloud Identity on its own is just the identity layer without the apps.
For PCA purposes, what matters is that both give you the same federation, group sync, and IAM integration. If a scenario mentions Workspace, you can assume Cloud Identity capabilities are available. If a scenario mentions Cloud Identity, do not assume Workspace apps are part of the picture.
When you see a question about migrating an app to GCP and authenticating users, look for these signals. Existing IdP that should keep handling auth. No new passwords. Minimal user disruption. Compliance constraint about not storing credentials in GCP. The answer is SAML 2.0 federation between Cloud Identity and the existing IdP.
When you see a question about a third-party app or external developers needing access to an API on behalf of users, the answer shifts to OAuth. That is delegated authorization, not user login.
The Professional Cloud Architect exam rewards you for matching protocols to problems. Federation for who, OAuth for what, IAM for the actual permissions on GCP resources. Once those three roles click into place, the identity questions on the exam become straightforward.
My Professional Cloud Architect course covers Cloud Identity and Workspace integration alongside the rest of the architecture and compliance material.
