GCP Organization Policy: Constraints and Guardrails Guide

Google Cloud Organization Policy lets you set guardrails on what resources can be configured to do, across your whole organization, folder, or project hierarchy. IAM controls who can act, while Organization Policy controls what is allowed to exist, which makes it one of the strongest preventive controls in Google Cloud.

What is Organization Policy Service?

The Organization Policy Service gives administrators centralized, programmatic control over resources by applying constraints to the resource hierarchy. A constraint is a rule such as "VMs cannot have external IP addresses." A policy is the configuration of that constraint on a specific organization, folder, or project.

The easiest way to remember the difference from IAM:

Question	Tool	Example
Who can do this?	IAM	Alice can create Compute Engine instances
What is allowed to be created?	Organization Policy	No instance may have a public IP

Both apply at the same time. A user with full IAM permissions still cannot break an enforced organization policy. That is what makes it valuable for preventing mistakes and limiting the damage from a compromised account. If you are new to the IAM side, start with our cloud IAM fundamentals guide.

How constraints and policies work

Google documents several kinds of constraints:

• Managed constraints: Google-managed constraints that support list or boolean parameters and are meant to replace older legacy constraints.
• Legacy managed constraints: The original constraints, using either boolean rules (enforced or not enforced) or list rules (allow or deny specific values).
• Custom constraints: Constraints your organization defines itself to allow or restrict resource creation and updates for supported services.

Inheritance through the hierarchy

Policies set on a parent resource are inherited by default by all child folders and projects. If you enforce a constraint at the organization level, every project below it receives that rule. Child resources can be configured to behave differently when the design requires it, but the safest pattern is to set strict defaults at the top and grant exceptions narrowly and with documentation.

Dry-run mode

Before you enforce a policy, you can use dry-run mode. In dry-run, violations are audit-logged but the violating actions are not denied. This is how you find out what would break before you break it. It is one of the most useful habits you can build, because turning on a restrictive policy in production without testing is a common cause of outages.

Tags for conditional enforcement

Tags let you apply a policy conditionally based on resource attributes. For example, you might enforce a stricter rule on resources tagged as production while allowing a relaxed rule in a sandbox folder.

Who can manage policies

Configuring constraints across the hierarchy requires the Organization Policy Administrator role. Treat this role like a privileged security role. Limit who holds it, require strong authentication, and review changes through audit logs, because anyone who can edit policy can weaken your guardrails.

Essential constraints every Google Cloud security engineer should know

Google's enterprise security foundations blueprint implements a set of preventive constraints. These are a strong starting point for a real organization:

Constraint	What it does
iam.disableServiceAccountKeyCreation	Blocks creation of service account keys, which are high-risk persistent credentials
iam.disableServiceAccountKeyUpload	Prevents uploading service account keys
iam.allowedPolicyMemberDomains	Limits IAM grants to managed accounts from your own domain
storage.publicAccessPrevention	Prevents ACLs and IAM from granting access to allUsers and allAuthenticatedUsers
storage.uniformBucketLevelAccess	Enforces IAM-only access control instead of legacy ACLs
compute.vmExternalIpAccess	Denies external IP addresses on VMs unless explicitly allowed
compute.requireOsLogin	Enforces OS Login instead of SSH keys stored in metadata
compute.skipDefaultNetworkCreation	Skips creating the default VPC network and its permissive firewall rules
compute.disableSerialPortAccess	Blocks serial port access to VMs
sql.restrictPublicIp	Prevents Cloud SQL instances from having public IP addresses

Notice the pattern. Each constraint removes a common attack path: leaked keys, public buckets, exposed VMs, and open databases. Together they cover many of the real-world misconfigurations behind cloud breaches. For a deeper look at the key problem, read our guide on GCP service account security and Workload Identity Federation.

A practical rollout plan

Do not enable every constraint on day one. A safer sequence:

1. Inventory current state. Identify existing service account keys, buckets with public access, VMs with external IPs, and Cloud SQL instances with public IPs.
2. Start in dry-run. Apply your target constraints in dry-run mode at the organization level and review the audit logs for violations.
3. Fix or document exceptions. Remediate real problems. For legitimate exceptions, create a narrowly scoped folder or project policy and record the business reason.
4. Enforce in stages. Move to non-production folders first, then production, watching for failed deployments and pipelines.
5. Monitor changes. Alert on policy modifications, since a policy change is a security-relevant event.
6. Automate with code. Manage policies in Terraform so changes go through review and version control.

This approach follows a principle we teach throughout the program: inspect before changing, test before enforcing, and keep a rollback path.

Organization Policy vs related controls

Organization Policy is one layer. It does not replace the others:

• IAM decides who has access. See our least privilege guide.
• VPC Service Controls limit data movement across service perimeters. See VPC Service Controls and data exfiltration.
• Security Command Center detects misconfigurations and threats after they exist.

Preventive controls stop bad configurations from being created. Detective controls find the ones that slip through. Mature teams use both.

Common mistakes to avoid

• Enforcing without testing. Skipping dry-run can break pipelines and applications.
• Granting the admin role broadly. The Organization Policy Administrator role should be tightly held.
• Setting policy only on projects. Policies at the organization or folder level scale better and are harder to bypass.
• Treating exceptions as permanent. Review every exception on a schedule.
• Assuming policy replaces monitoring. You still need logging and detection.

Why this matters for your career and the exam

If you are preparing for the Google Cloud Professional Cloud Security Engineer certification, expect to reason about resource hierarchy, inheritance, and preventive guardrails. Hiring managers also look for candidates who can explain not just what a control does, but how to roll it out safely. Our Google Cloud security and PCSE exam guide covers the wider exam picture. For official details, see the Organization Policy Service documentation.

Frequently asked questions

What is the difference between IAM and Organization Policy in Google Cloud? IAM controls who can perform actions on resources. Organization Policy controls what configurations are allowed, regardless of who is acting. Both are evaluated together, so an enforced constraint can block an action even for a user with broad IAM permissions.

Do organization policies apply to child folders and projects? Yes. By default, a policy set on a parent resource is inherited by all descendant folders and projects. You can configure child resources differently when needed, but strict defaults at the organization level are the safest starting point.

What is dry-run mode for organization policies? Dry-run mode audit-logs violations of a policy without denying the violating actions. It lets you see what would break before you enforce the policy, which reduces the risk of outages.

Which role is needed to manage organization policies? The Organization Policy Administrator role is required to configure constraints across the resource hierarchy. Because it can weaken your guardrails, grant it to as few people as possible.

Which constraints should I enable first? Common starting points include blocking service account key creation, preventing public access on Cloud Storage, denying external IPs on VMs, and restricting public IPs on Cloud SQL. Test each in dry-run before enforcing.

Can I create my own constraints? Yes. Custom constraints are defined by your organization and let you allow or restrict resource creation and updates for supported services, which is useful for company-specific rules.

Build real cloud guardrails with PrimeSec

Reading about guardrails is not the same as building them. In the PrimeSec program you implement policy controls in hands-on labs across AWS, Azure, and GCP and document them in portfolio projects. Explore the curriculum or enroll today to start building job-ready skills.