IAM & Cloud Identity

GCP Fundamentals

Chapter 2 · IAM & Cloud Identity

AWS Fundamentals Chapter 2 covered IAM's own user/group/role/policy structure; Azure Fundamentals Chapter 2 covered Entra ID's tenant-wide identity model and RBAC. GCP's own real IAM system shares the same underlying goal — controlling who can do what, on which resource — through a genuinely distinctive real vocabulary and mechanism.

Real Principals

GCP calls any identity being granted access a principal, split into two real categories:

Human users — Google Accounts, Google groups, and federated identities in workforce identity pools.
Workloads — service accounts (below), and federated identities in workload identity pools.

Real Three Role Types

Role Type	Real Description
Basic (Primitive)	Owner, Editor, Viewer — real, highly permissive, broad access
Predefined	Google-managed collections of permissions for common real tasks (e.g. the Pub/Sub Publisher role)
Custom	User-created, containing only the specific real permissions you define — most control, most maintenance

A Real, Direct Warning From Google Itself

Google's own real, official documentation states plainly that basic roles "shouldn't be used in production environments." Owner and Editor grant sweeping, broad access across a Project — genuinely the same real category of risk AWS's own root account and Azure's own Owner role represent, and exactly the kind of role least privilege exists to steer you away from by default.

Real IAM Policy Bindings

GCP's own real, distinctive mechanism is the IAM policy binding — a real, direct association between one role and a list of principals, attached to a specific resource. A resource's own "allow policy" contains a real list of these bindings; when a principal attempts an action, GCP checks that policy to confirm the principal holds a binding granting the required real permission.

# A real IAM policy binding, conceptually
{
  "role": "roles/storage.objectViewer",
  "members": [
    "user:alice@example.com",
    "serviceAccount:app-sa@my-project.iam.gserviceaccount.com"
  ]
}
  

Exactly as Chapter 1's own resource hierarchy promised, a binding applied at a Folder or Organization level cascades automatically to every Project and resource beneath it — the same real inheritance principle, applied here specifically to access control.

Service Accounts

A service account is a real identity for an application or workload, not a person — each with its own real, unique email address, commonly attached directly to a Compute Engine instance (Chapter 3) so that instance's own code can make authorized API calls.

The Same Real Lesson, GCP's Own Words

Google's own real, official guidance is direct: "Service account keys are a security risk if not managed correctly." The recommended real alternatives — attached service accounts (automatically obtaining short-lived credentials), Workload Identity Federation (for external workloads), and domain-wide delegation (for Google Workspace integration) — all avoid ever creating or storing a long-lived private key file at all. This is genuinely the same real lesson as AWS's own IAM-role-over-embedded-keys guidance (AWS Fundamentals Chapter 2) and Azure's own Managed Identity guidance (Azure Fundamentals Chapter 2) — three different real providers, the same underlying real principle.

AWS IAM vs. Azure RBAC vs. GCP IAM

Property	AWS	Azure	GCP
Identity term	User / Role	Security principal	Principal
Broadest built-in role	Root account (avoid daily use)	Owner	Basic roles — Owner/Editor/Viewer (avoid in production)
Service identity mechanism	IAM role	Managed Identity	Service account (avoid long-lived keys)
Permission-grant mechanism	Policy attached to identity	Role assignment at a scope	Policy binding (role + principals) on a resource
Inheritance	None (flat, per-identity)	Downward through RBAC scope	Downward through resource hierarchy

Hands-On Exercises

Exercise 1

A developer is granted the Editor basic role on a Project so they can "do everything they need" quickly. Explain, in your own words, why Google's own real guidance recommends against this in production, and what real alternative they should use instead.

📄 View solution

Exercise 2

A team downloads a service account key file and embeds it directly in their application's own source code, later accidentally committing it to a public repository. Explain, in your own words, what real, standard alternative would have avoided this specific risk entirely, using the chapter's own real guidance.

📄 View solution

Exercise 3

A team binds a Viewer role to a specific principal at the Folder level. Explain, in your own words, what real access that principal has to a Project created later inside that same Folder, and why.

📄 View solution

Chapter 2 Quick Reference

Principals — human users (Google Accounts, groups) vs. workloads (service accounts, federated identities)
Three role types — Basic/Primitive (Owner/Editor/Viewer, avoid in production), Predefined, Custom
IAM policy binding — a role + a list of principals, attached to a resource; inherits down the Chapter 1 hierarchy
Service accounts — real identities for workloads; Google's own real, official warning against long-lived keys
Real alternatives to keys: attached service accounts, Workload Identity Federation, domain-wide delegation