Org policies in Google Cloud let you set guardrails on what resources can do across your entire organization. They sit above IAM and apply to everyone, including project owners. When you configure a list-based constraint, you have to choose between two modes: allowlist or denylist. The Professional Cloud Architect exam expects you to know which one fits a given scenario.
An allowlist defines what is explicitly permitted, and everything else is blocked by default. You write down the values you want to allow, and any value not on that list is denied.
A common example is external IPs on virtual machines. If your organization has a security posture that says VMs should not be publicly reachable, but you have a handful of edge instances that legitimately need external IPs, you can apply the constraints/compute.vmExternalIpAccess policy as an allowlist. You list the specific VM instances allowed to have external IPs, and every other VM in the org is blocked from getting one.
Allowlists are the right choice when you know exactly what should be permitted and you want to deny everything else by default. They give you a closed posture.
A denylist defines what is explicitly denied, and everything else is permitted by default. You write down the values you want to block, and anything not on that list is allowed.
The classic example here is constraints/compute.resourceLocations. If your compliance requirement is that resources cannot be deployed in a specific set of regions, you put those regions on a denylist. Every other region remains available. You are not trying to lock the org down to a small approved set of regions, you are just blocking the ones that are off-limits.
Denylists fit when you have a known set of risks or restrictions to block but you want to keep the rest of the surface area open.
The decision comes down to which side of the rule has fewer items.
If the set of permitted values is small and well-defined, use an allowlist. You list the few things you want to allow and the org policy denies the long tail.
If the set of denied values is small and the rest should stay open, use a denylist. You list the few things you want to block and everything else continues to work.
For the Professional Cloud Architect exam, the question is usually framed as a business scenario. Read carefully for whether the policy is meant to be restrictive (only these are permitted) or exclusionary (these specific items are blocked). That phrasing tells you which list type to choose.
Org policies are inherited down the resource hierarchy from organization to folder to project. A policy applied at the org level flows down to every folder and project beneath it.
Lower levels can override an inherited policy, but only to make it stricter. They cannot relax it. If the org sets an allowlist of three approved regions, a project under that org cannot add a fourth region. It can only narrow the list further, say down to two regions.
The effective policy at any node is the combination of all inherited policies, with the strictest rule winning. This is the opposite of how IAM permissions combine, where the most permissive role wins. For org policies, restrictive always beats permissive. The Professional Cloud Architect exam will test this distinction directly, so make sure you have it crisp before sitting the exam.
My Professional Cloud Architect course covers allowlists and denylists in org policies alongside the rest of the IAM and governance material.
