2.1.2. IAM Roles and Cloud Identity for Users and Groups
💡 First Principle: Granting access to a project is really two separate problems — first, does the identity exist at all (Cloud Identity), and second, what is that identity allowed to do once it's recognized (IAM) — and conflating the two is how "the user can log in but can't do anything" tickets happen.
Cloud Identity is where user and group accounts actually live — it's Google's identity management layer, usable standalone (without Workspace) purely to manage who exists in your organization. Users and groups can be provisioned manually through the Admin console, or automated via directory sync tools that mirror an existing on-premises identity provider (like Active Directory) into Cloud Identity, so a new hire's existing corporate account automatically gains Google Cloud access without a parallel manual step.
Once an identity exists, IAM roles determine what it can do — and granting a role to a group rather than to individual users one at a time is the practice the exam consistently rewards, because it means onboarding and offboarding become a matter of group membership rather than repeated per-user IAM edits.
⚠️ Exam Trap: IAM roles must be granted directly on each individual resource, the way access lists work in some other systems — that's a common assumption, but it's backwards for Google Cloud. IAM policies are set at the Organization, Folder, Project, or resource level and are inherited downward; a role granted at the project level applies to every resource inside it unless a more specific policy overrides it.
Reflection Question: A company's HR system already manages which employees belong to which department in an on-premises directory. What approach lets that existing structure drive Google Cloud group membership automatically, instead of manually recreating it in Cloud Identity?
