Organization Policy (GCP)
A constraint applied at the Organization, Folder, or Project level that restricts what resources are allowed to look like across everything beneath that level - for example, blocking external IP addresses on VMs or restricting allowed regions. Unlike IAM, which controls who can act, Organization Policy controls what configurations are permitted.
Frequently Asked Questions
How does GCP Organization Policy differ from IAM if both can restrict what happens in a project?
IAM answers 'who can perform this action' by granting roles to identities, while Organization Policy answers 'what configurations are allowed to exist at all,' regardless of who's making the request — even an Owner-level IAM identity can't create a resource that violates an active Organization Policy constraint, like `constraints/compute.vmExternalIpAccess` blocking external IPs. This makes Org Policy the layer for guardrails that must hold even against a misconfigured or overly permissive IAM grant.
What's a common mistake teams make when applying Organization Policy constraints?
Applying a restrictive constraint at the Organization root without first checking which existing projects would break is a frequent cause of outages — a policy blocking external IPs, for instance, can immediately strand VMs that legitimately need public access, like a bastion host or a public-facing service. Testing constraints at a Folder level against a subset of projects, and using dry-run/audit mode where available, is the safer rollout path before enforcing organization-wide.