Enforcing Organization Policies Across Projects

Overview and What You Will Learn

In this lab, you will view the default state of an Organization Policy constraint, apply a constraint blocking external IP addresses on VMs at the Folder level, and confirm it automatically applies to every project inside that Folder without needing to configure each one individually.

Why This Matters in Production

A security team asks every engineer to "please avoid assigning public IPs to VMs unless genuinely necessary," and despite good intentions, inconsistent adherence means some VMs end up with unintended public exposure anyway. An Organization Policy constraint turns that request from a matter of individual discipline into an automatically enforced rule that applies the moment a new project is created under the same Folder, with no reminder needed.

Core Principles

Organization Policies let you set constraints that apply across an entire Organization, Folder, or Project - and like IAM permissions, a constraint set at a higher level automatically applies to everything beneath it, unless a lower level explicitly overrides it (where the policy allows overrides at all).

Detailed Step-by-Step Practical Lab

1. Create a Folder to scope this lab's policy to:

2. Check the current, default state of the constraint that controls whether VMs can have external IP addresses:

3. Apply a constraint blocking external IP addresses on VMs, at the Folder level:

4. Create a Project inside that Folder to see the constraint automatically apply:

5. Attempt to create a VM with an external IP address, and confirm it is blocked by the inherited policy:

6. Confirm creating the same VM without an external IP succeeds normally, since that does not violate the constraint:

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Setting an Organization Policy constraint directly at the Organization level for a rule that should genuinely only apply to production environments, then discovering it also blocks a legitimate need in a dev or sandbox Folder. Apply constraints at the most specific level (Folder, not Organization) whenever the rule's intent doesn't genuinely apply everywhere.

Tip

Set Organization Policies at the Folder level when a rule should apply to every project within a specific team or environment, rather than configuring the same constraint individually on each project. Policy inheritance means you only need to set it once at the right level.

• Not every constraint supports being overridden at a lower level. Some Organization Policy constraints are strictly enforced from wherever they're set, with no ability for a child Folder or Project to loosen them - check a constraint's specific documentation before assuming it can be selectively relaxed further down the hierarchy.
• Test a new constraint in a sandbox Folder first, before applying it broadly at the Organization level, to confirm it doesn't unexpectedly block a legitimate, existing workflow somewhere in the hierarchy.

Quick Reference & Troubleshooting Commands