Org Policies are how you enforce organization-wide rules on what resources can be created and how they can be configured in Google Cloud. They sit alongside IAM in the governance toolkit. IAM controls who can do things, while Org Policies control what can be done at all, no matter who is doing it. The Professional Cloud Architect exam tests whether you understand how these policies flow through the resource hierarchy and what happens when teams need exceptions at lower levels.
This article focuses on inheritance and exceptions. Allowlist versus denylist enforcement is its own topic and gets covered separately.
An Org Policy is a constraint applied to part of the resource hierarchy. Common examples include constraints/compute.resourceLocations to restrict which regions resources can run in, constraints/compute.vmExternalIpAccess to block VMs from getting public IPs, constraints/iam.allowedPolicyMemberDomains to restrict which user domains can be added to IAM bindings, and constraints/compute.requireOsLogin to force SSH access through IAM-managed OS Login.
You can attach any of these constraints at the organization, folder, or project level. That choice is what determines the scope of the rule.
Policies set at a higher level are inherited by everything underneath. If I attach constraints/compute.resourceLocations at the organization and limit it to US regions, every folder and every project under that organization picks up the same restriction by default. A team spinning up a new project does not have to opt in. The constraint is already there because it was inherited from above.
This is the mechanism that makes centralized governance practical. You set the rule once at the top, and the entire org inherits it without anyone having to remember to apply it on each project.
The part that trips people up is what happens when a lower level wants to override an inherited policy. The override is allowed, but only in one direction. A project or folder can make the policy stricter than what it inherited. It cannot make it looser.
Concretely, if the organization restricts resources to US regions, a folder underneath cannot override that and allow EU regions. The folder can override and restrict further to a single region like us-central1, but it cannot expand the allowed set. The same logic applies to every other constraint. If the organization blocks external IPs on VMs, no project under it can override that to permit them.
The effective policy at any node in the hierarchy is the combination of every inherited policy plus whatever is set locally, with the strictest rule winning. That last point is the one to lock in for the Professional Cloud Architect exam. For Org Policies, strictest wins. This is the opposite of how IAM behaves, where the union of bindings applies and lower levels can grant additional access. Org Policies and IAM look similar on the surface because both attach to the hierarchy, but the inheritance semantics are different and the exam will test whether you know that.
A common pattern is to set baseline restrictions at the organization, then let folders represent business units that may need stricter rules. The finance folder might inherit the org-wide US-only constraint and additionally pin resources to a specific region for auditability. A regulated workloads folder might inherit the same baseline and additionally enforce constraints/compute.requireOsLogin on every project under it.
Projects under those folders inherit the combined policy. If a single project inside the regulated folder needs even more restriction, say blocking external IPs entirely, the project owner can attach that constraint at the project level. Everything above stays in place, and the project ends up with the strictest combination of all of it.
The questions you are likely to see are scenario-based. A company has a data residency requirement and wants to make sure no team can deploy resources outside approved regions, even by accident. The right answer is an Org Policy at the organization level using constraints/compute.resourceLocations. A subsidiary needs to be even more restrictive than the parent. The right answer is a tighter constraint applied at the folder or project level, not a request to relax the parent policy, because relaxing inherited policy is not possible.
If you remember three things going into the exam, make them these. Org Policies inherit from organization down to folders down to projects. Lower levels can override only by tightening. The effective policy is the strictest combination across the chain.
My Professional Cloud Architect course covers Org Policy inheritance and exceptions alongside the rest of the IAM and governance material.
