5.1.1. IAM Policies and Role Inheritance
💡 First Principle: An IAM policy is a binding between a member (a user, group, or service account) and a role, attached at some level of the resource hierarchy — and because policies are inherited downward, the same binding effectively applies at every level beneath where it was set, without needing to be repeated.
Viewing and creating IAM policies is done through the console's IAM page, gcloud projects get-iam-policy/set-iam-policy, or Infrastructure as Code. Attaching roles happens at whichever hierarchy level makes sense for the access being granted — a role granted at the Organization level applies to every Folder and Project beneath it, while a role granted at a single Project applies only there. This policy inheritance through the Organization hierarchy is the mechanism that makes centralized access management possible at scale — grant a role once at the right level, and it silently applies everywhere beneath it going forward, including to resources that don't exist yet at the time the policy was set.
⚠️ Exam Trap: A policy set at a lower level in the resource hierarchy can revoke a permission inherited from above — a natural but incorrect assumption, since learners expect hierarchy overrides to work symmetrically in both directions. Ordinary IAM allow-policies at a lower level cannot strip an inherited grant from a higher level; only the dedicated IAM Deny policy feature can explicitly block an inherited permission.
Reflection Question: A Folder-level IAM binding grants a group the Viewer role across every project inside it. A team lead tries to set a stricter policy on one specific project inside that Folder to remove that access for their project alone using a standard allow-policy. Does that work, and if not, what feature would actually achieve it?
