5.1.2. IAM Role Types and Custom Roles
💡 First Principle: Google Cloud's three IAM role types — primitive, predefined, and custom — represent decreasing breadth and increasing precision, and the exam consistently rewards recognizing when a scenario's least-privilege requirement rules out the broader options entirely.
Primitive roles (Owner, Editor, Viewer) predate Google Cloud's more granular IAM system and grant sweeping permissions across every service in a project — convenient, but almost always broader than any real task requires. Predefined roles are curated, service-specific role bundles (like roles/compute.instanceAdmin) designed around common job functions, offering meaningfully narrower scope than primitive roles while still being ready-made. Custom roles let you assemble an exact set of individual permissions when even the narrowest predefined role still grants more than a specific task needs — the highest-precision option, at the cost of needing to build and maintain the role definition yourself.
| Role Type | Scope | Maintenance Burden | Best For |
|---|---|---|---|
| Primitive | Broad, project-wide | None | Rarely appropriate outside small sandboxes |
| Predefined | Service-specific bundle | None | Most common production access needs |
| Custom | Exact permission set | You maintain it | Least-privilege requirements predefined roles can't satisfy |
⚠️ Exam Trap: A scenario emphasizing an unusually narrow permission requirement — say, a role that can restart Compute Engine instances but cannot create or delete them — that no predefined role matches exactly, is pointing at a custom role, not the "closest" predefined one. Settling for a predefined role that grants more than the scenario asks for isn't the least-privilege answer the exam wants.
Reflection Question: A support team needs to view VM details and restart instances but must never be able to create, delete, or modify instance configurations. If no predefined role matches that exact boundary, what's the correct approach?
