Phase 1 · Lesson 1.3 3 of 20

Organization policies

Analogy: The fire code for your whole building

If IAM (Lesson 1.2) was the bouncer checking VIP badges, Org Policies are the city zoning laws.

The difference is everything. IAM dictates who is allowed to do something. Org Policies dictate what is allowed to exist in your cloud at all — regardless of who’s asking.

Imagine you give a lead developer the Owner role on a Project. Technically, according to IAM, they have the power to spin up a server anywhere in the world and open it to the public internet. That’s a lot of trust.

But what if your company is a European bank? By law, your customer data cannot leave Europe. You cannot rely on every developer to perfectly remember this — at 11pm, on their fifth deploy of the day, when the on-call rotation flipped two hours ago. One mistake and you’re in front of a regulator.

This is where you drop the hammer with an org policy.

Organization policies in the GCP hierarchy Three policy guardrails attached to the Organization node, flowing down to all folders, projects, and resources below. Organization The whole city — yourcompany.com — where zoning laws attach 🚫 No public buckets storage.publicAccess Prevention 🌍 Region lock resourceLocations Data residency 🔒 Domain-only IAM allowedPolicyMembers Identity boundary Every folder, project, and resource below Policies inherit downward — even Owners cannot violate them The architect's "why" Trust the architecture, not the engineers' good intentions
→ Click any policy above to read what it does and when you'd use it
Quick check Your security team is terrified

Your security team won't sleep. They're worried about three things at once:

  • A developer accidentally making a Cloud Storage bucket public and leaking customer data
  • Customer data ending up outside the EU (GDPR violation)
  • An engineer granting access to a personal Gmail account for "convenience"

Pick the org policies that would technically prevent each of these — not just discourage them.

How it actually works

At the Organization or Folder level, you set a policy constraint. For example:

  • gcp.resourceLocations — only allow resources in europe-west1 and europe-west4
  • storage.publicAccessPrevention — no Cloud Storage bucket can be made public, ever
  • compute.vmExternalIpAccess — no VM can have a public IP address

These aren’t suggestions. They’re enforced by GCP’s API itself, before the resource is even created.

Once the policy is in place, it becomes the ultimate law of the land. If the CEO of the company logs in with roles/resourcemanager.organizationAdmin — the most powerful role that exists in GCP — and tries to build a Compute Engine VM in Tokyo, the org policy will physically block them. The API returns an error before the resource exists. Not “you don’t have permission” — the request itself is invalid.

That’s the difference. IAM says “you can’t.” Org policies say “this isn’t a thing that’s allowed to happen here.”

Architect’s note — the audit conversation

When a SOC 2, ISO 27001, or PCI-DSS auditor asks “how do you prevent X,” there are two acceptable answers and one unacceptable answer.

Unacceptable: “We have a policy that says we don’t do X” — (written, but not enforced. Useless to an auditor.)

Acceptable: “We have alerting that fires when X happens” — (detective control. Better than nothing, but the breach already happened.)

What auditors love: “We have a technical control that makes X impossible — here’s the org policy enforcing it” — (preventive control. Nothing to detect because nothing can happen.)

Org policies move you from the second category to the third. For regulated finance, healthcare, and government work, this is not a nice-to-have — it’s the difference between “audit passed” and “remediation plan required by Q2.”

The deny-by-default pattern

Here’s the architectural pattern you’ll use over and over: deny dangerous things at the Organization level, then carve out exceptions only where genuinely needed.

For example: set storage.publicAccessPrevention to enforced at the Org level, blocking public buckets everywhere. But your marketing team genuinely needs one public bucket to host static website assets. You create a Marketing/PublicAssets folder, attach an org policy override on that folder relaxing the constraint, and place exactly that one bucket in there. Everywhere else in the company, the deny still applies.

This is the inverse of how IAM works. IAM is grant-by-default — no access until you explicitly grant. Org policies for the constraints you set are deny-by-default — no exceptions until you explicitly carve them out. Combining both gives you defense in depth: IAM controls who would be allowed, and org policies make the dangerous things undoable in the first place.

The Governance-as-Code connection

Here’s the mental shift that separates architects from senior engineers: you stop trying to train good behavior, and start making bad behavior impossible.

A senior engineer’s instinct, when asked “how do we prevent public buckets,” is: write a runbook, do code reviews, set up alerting. These all help, but they’re all reactive — they catch the mistake after it happens. The architect’s answer is: set the org policy. Then it’s not even possible to make the mistake. The IAM screen for allUsers returns an error before any data leaks.

This is the principle behind Governance-as-Code — the idea that your governance posture (what’s allowed, what’s required, what’s forbidden) should be expressed as machine-checkable rules, not human-checkable guidelines. Org policies are the GCP-native primitive for this. They turn “we have a policy” (a sentence in a Word doc) into “we have a control” (a technical mechanism that enforces the policy automatically, on every request, forever).

Coming up

In Lesson 1.4 we shift from blueprints and bouncers into the actual physical layer — VPCs and subnets. We’ve talked a lot about who can do what; now we start talking about where the wires actually run.

← Back to curriculum