If you are studying for the Professional Cloud Architect exam, you need to be comfortable with how IAM behaves at the organization level and how permissions accumulate when a principal has bindings at more than one node in the resource hierarchy. This article walks through the org-level roles you should recognize on exam day and explains exactly how the effective IAM policy is calculated at any given resource.
The Google Cloud resource hierarchy starts at the organization, then flows down through folders and into projects, and finally into the resources inside those projects. When you bind a role to a principal at the org level, that binding cascades down to every folder and every project beneath it. That cascading behavior is what makes org-level role assignments so powerful and so easy to misuse, which is why the exam expects you to know which roles belong at the top of the hierarchy and what they actually grant.
There are many predefined roles you can grant at the organization node, but a few show up often enough that they are worth memorizing for the Professional Cloud Architect exam.
The Organization Administrator role grants full access to all resources within the organization. A principal with this binding at the org level can manage every folder, every project, and every resource that lives under them. The permissions cascade down through the entire hierarchy, so this is the role you reach for when someone genuinely needs control over the whole tenant. It is also the role you should be most careful about handing out.
The Organization Policy Administrator role manages organization policies, the constraints applied to them, and the conditions under which those constraints take effect. Organization policies are the mechanism for setting guardrails across the org, things like restricting which regions resources can be created in or which external IPs can be assigned. Because those policies flow down to all folders and projects, the person who can author them needs scoped, deliberate access. This role gives that access without granting full administrative control.
The Viewer role at the org level grants view-only access across the organization. It is useful for auditors, security reviewers, or anyone who needs to monitor what exists without being able to change it. Like every other org-level binding, the read access cascades down to every project under the org, so a single binding gives the principal visibility into the entire tenant.
Browser is a narrower read-only role. Instead of granting visibility into the contents of resources, it grants read access to the structure and metadata of projects and folders. If you want someone to be able to navigate the resource hierarchy and understand how the org is organized without being able to read the data inside resources, Browser is the right role.
The behavior to internalize is that roles bound at a higher node automatically apply to every resource beneath that node. If you grant a user the Viewer role at the organization, that user has Viewer access on every folder and every project in the org. If you grant a service account the Storage Admin role at a folder, that service account has Storage Admin on every project inside that folder.
This is what makes the hierarchy useful. You design your folder structure to mirror how you want access to flow, then you bind roles at the level that matches the scope of the access. A team that should have access to everything in the production environment gets a binding at the production folder, not project by project.
Once you have bindings at multiple levels of the hierarchy, the question becomes: what does a principal actually have permission to do at a specific node?
The answer is that the effective IAM policy at any node is the union of every policy inherited from higher nodes plus every policy bound directly to that node. Picture a Venn diagram where one circle is the set of permissions a user gets from a binding at the org level and another circle is the set of permissions they get from a binding at a specific project. Some permissions may overlap. Some are only granted at the org level. Some are only granted at the project level. The user's effective permissions at that project are the entire diagram, every permission from every applicable binding combined.
If you add a folder binding into the picture, that folder's permissions are also part of the union. The same logic applies to as many levels as you have bindings on. There is no override. There is no most-specific-wins. IAM in Google Cloud is purely additive across the hierarchy, which is why a careless org-level binding can quietly give someone far more access than the local project binding suggests.
The Professional Cloud Architect exam will ask you a version of this question. Read carefully, list every binding that applies to the principal at the node in question, and compute the union. That is the effective IAM policy.
Two takeaways are worth holding onto. First, before granting any role at the org level, ask whether the principal really needs that access on every project that exists today and every project that will be created in the future. Cascading is the feature, but it is also the failure mode. Second, when troubleshooting access, do not stop at the project's IAM page. The principal may have permissions inherited from a folder or from the org that are silently expanding what they can do.
My Professional Cloud Architect course covers org-level IAM roles and effective IAM policy alongside the rest of the IAM and governance material.
