This chapter covers GCP Organization Policies, a critical security control for enforcing constraints across your entire cloud hierarchy. For the ACE exam, Organization Policies appear in roughly 5-10% of questions, often mixed with IAM and Resource Manager topics. Understanding how to create, scope, and troubleshoot policies is essential for passing Domain 5: Security & Compliance. By the end of this chapter, you will be able to configure organization policies, understand inheritance, and identify common exam traps.
Jump to a section
Imagine a city government that owns a large office complex with many floors and rooms. Each floor is a folder (project), and each room is a resource (like a VM or storage bucket). The city enforces building codes that apply to the entire complex, not just individual rooms. For example, a code might say: 'No room can have a door that opens outward into a hallway' — this is like a constraint that restricts a specific resource property. The city can also have codes that apply only to certain floors (projects) by using scoping with folder or project IDs. When a tenant (IAM user) tries to add a door that opens outward, the building inspector (the Organization Policies service) checks the code list. If the code denies that action, the inspector prevents the door installation and logs the violation. The inspector does not care who the tenant is — it only enforces the code. The city can also set policies at the city level (organization node) that automatically apply to all floors, or set a policy at a specific floor that overrides the city policy only if allowed by the city (using 'inherit from parent' or 'replace' modes). This hierarchical enforcement ensures that security rules are consistent across the entire complex, preventing a rogue tenant from creating a safety hazard.
What Are Organization Policies?
Organization Policies in Google Cloud are a mechanism to centrally enforce restrictions on resources across your entire organization hierarchy. They are defined using the Organization Policy Service and are applied to resources such as projects, folders, and the organization node itself. Unlike IAM, which controls *who* can do what, organization policies control *what* is allowed to be done — they are constraints on the configuration of resources.
Why They Exist
Without organization policies, individual project owners could deploy resources with insecure settings (e.g., public buckets, unencrypted disks, or non-compliant machine types). Organization policies allow administrators to enforce compliance (e.g., HIPAA, SOC 2) by denying certain resource configurations globally. They are a key tool for governance and security at scale.
How They Work Internally
Organization policies are implemented as a list of constraints. Each constraint is a specific rule, such as "require CMEK for all disks" or "disable public IP addresses on VMs." Constraints are defined by Google (list constraints) or custom (using YAML). When a user attempts to create or modify a resource, the Organization Policy Service evaluates all applicable policies (from the resource's ancestors) and denies the operation if any policy prohibits it.
Key Components
Organization Node: The root of the hierarchy. Policies set here apply to all folders and projects under it.
Folder: Intermediate node. Policies set here apply to all folders and projects under it.
Project: Leaf node. Policies set here apply only to resources within that project.
Constraint: A rule that either lists allowed/denied values or booleans (true/false).
Policy: An instance of a constraint with a specific configuration (allowlist, denylist, or boolean value).
Inheritance: Policies are inherited from parent to child, but can be overridden if the parent policy allows it (using inheritFromParent).
Default Values and Timers
Default state for most constraints is unset (no restriction).
Boolean constraints default to false (disabled).
List constraints default to an empty list (no restrictions).
There is no timer or TTL for policies — they take effect immediately upon creation or update.
Configuration and Verification
Policies are managed via the gcloud resource-manager org-policies command set or the Cloud Console. Key commands:
# List all constraints available
gcloud resource-manager org-policies list-constraints --organization=123456789
# Set a boolean policy on a project
gcloud resource-manager org-policies set-policy --project=my-project policy.yaml
# Get a policy
gcloud resource-manager org-policies describe constraints/compute.disableSerialPortAccess --project=my-project
# Delete a policy (reverts to no policy)
gcloud resource-manager org-policies delete constraints/compute.disableSerialPortAccess --project=my-projectPolicy YAML example:
constraint: constraints/compute.disableSerialPortAccess
listPolicy:
allValues: DENYInteraction with Related Technologies
IAM: IAM grants permissions; organization policies restrict what can be done even if IAM allows it. They are complementary.
Resource Manager: Organization policies are applied at the resource hierarchy level (org, folder, project).
Security Command Center: Can detect violations of organization policies.
Cloud Audit Logs: All policy changes and enforcement denials are logged.
Step-by-Step Mechanism
When a user requests to create a VM with an external IP, the following happens:
1. The user's IAM permissions are checked (e.g., compute.instances.create).
2. If allowed, the Organization Policy Service evaluates all policies in the hierarchy from the project up to the organization node.
3. For each policy with the relevant constraint (e.g., compute.vmExternalIpAccess), the service checks if the requested value (external IP) is allowed.
4. If any policy denies it, the request fails with an error like "Organization policy violation."
5. If no policy denies, the resource is created.
Exam Tip
The ACE exam often tests the difference between list and boolean constraints. Remember: list constraints allow you to specify allowed or denied values; boolean constraints are simple on/off switches. Also, know that policies can be set at the project level, but if a parent policy is more restrictive, it takes precedence unless the parent policy has inheritFromParent set to false (which is rare).
Identify the Constraint Needed
First, determine which constraint applies to the resource you want to restrict. Google provides a list of predefined constraints for common services (e.g., `compute.vmExternalIpAccess`, `storage.publicAccessPrevention`). You can also create custom constraints using YAML. For the ACE exam, focus on predefined constraints like `constraints/compute.requireShieldedVm`, `constraints/iam.disableServiceAccountKeyCreation`, and `constraints/gcp.resourceLocations`.
Define the Policy YAML File
Create a YAML file that specifies the constraint and the desired behavior. For list constraints, you can use `allValues: ALLOW` or `allValues: DENY`, or specify a list of allowed/denied values. For boolean constraints, use `booleanPolicy: true` or `false`. Example: to disable serial port access, set `constraints/compute.disableSerialPortAccess` with `booleanPolicy: true`. Ensure the YAML is valid and references the correct constraint name.
Apply the Policy at the Correct Level
Use the gcloud command to apply the policy to the organization, folder, or project. For example: `gcloud resource-manager org-policies set-policy --organization=ORG_ID policy.yaml`. The policy will be inherited by all children unless overridden. You can also set a policy at a folder or project level to override the parent policy, but only if the parent policy allows it (by default, child policies can override parent policies).
Verify the Policy is Enforced
After applying, test by attempting to create a resource that violates the constraint. For example, if you set `constraints/compute.disableSerialPortAccess` to true, try to create a VM with serial port access enabled. The operation should fail with a permission denied error referencing the organization policy. Use `gcloud resource-manager org-policies describe` to confirm the policy is active.
Monitor and Audit Policy Changes
All organization policy changes are logged in Cloud Audit Logs under the `Organization Policy` service. You can view these logs in the Logs Explorer to audit who changed policies and when. Additionally, the Security Command Center can report on policy violations. For the exam, know that policy changes are auditable and that you can use logs to troubleshoot denied operations.
Scenario 1: Enforcing Data Residency for a Healthcare Company
A healthcare company must ensure that all patient data (stored in Cloud Storage and BigQuery) remains within the United States. They use the constraints/gcp.resourceLocations constraint to restrict resource creation to US regions. They set this policy at the organization level with an allowlist of us-central1, us-east1, us-west1, etc. Any attempt to create a resource in a non-US region (e.g., europe-west1) is denied. This prevents developers from accidentally deploying in non-compliant regions. The policy is applied using a YAML file with listPolicy and allowedValues. In production, they also use folder-level policies to allow specific exceptions for test projects (e.g., a folder for non-PHI data can have a different policy).
Scenario 2: Disabling Public IPs on VMs for a Financial Institution
A financial institution wants to prevent any VM from having an external (public) IP address to reduce attack surface. They set the constraints/compute.vmExternalIpAccess constraint to deny all values at the organization level. This means no VM can be created with an external IP. If a developer tries to create a VM with an external IP, the request is denied. They also set constraints/compute.disableSerialPortAccess to true to prevent attackers from using the serial console. In production, they monitor the Security Command Center for violations and use Cloud Audit Logs to track who attempted to create VMs with public IPs.
Common Misconfigurations
Setting a policy at too low a level (project) when you want organization-wide enforcement.
Forgetting that child policies can override parent policies by default. To prevent this, use inheritFromParent: true in the child policy (or set the child policy to match the parent).
Using the wrong constraint name (e.g., compute.vmExternalIpAccess vs compute.instances.externalIp). Always verify with gcloud resource-manager org-policies list-constraints.
Not testing the policy after applying it — the policy takes effect immediately, but you should verify with a test resource creation.
Scale and Performance
Organization policies are evaluated synchronously during resource creation. For large organizations with many policies, the evaluation can add a few hundred milliseconds to resource creation time. This is usually negligible. There is no hard limit on the number of policies, but best practice is to keep them under 1000 per organization.
What the ACE Exam Tests
The ACE exam (Domain 5: Security & Compliance) tests your ability to:
Identify when to use organization policies vs IAM.
Understand inheritance and scoping (org, folder, project).
Differentiate between list and boolean constraints.
Know specific predefined constraints (especially compute.vmExternalIpAccess, storage.publicAccessPrevention, gcp.resourceLocations, iam.disableServiceAccountKeyCreation).
Troubleshoot organization policy violations.
Common Wrong Answers and Traps
Confusing organization policies with IAM: Candidates often choose IAM when the question is about restricting resource configuration. Remember: IAM controls who can perform actions; organization policies control what configurations are allowed.
Assuming policies cannot be overridden: Many think that an organization-level policy is absolute. In reality, child policies can override parent policies unless the parent sets a specific rule to prevent overrides (using inheritFromParent).
Forgetting that policies apply to all resources in scope: Some candidates think a policy only applies to new resources, but it also applies to existing resources (though existing resources are not automatically modified — you must remediate manually).
Mixing up list and boolean constraints: Boolean constraints are simple true/false; list constraints allow you to specify allowed or denied values. The exam may ask which type to use for a scenario.
Specific Values and Terms
Constraint names: always start with constraints/.
Default inheritance: child overrides parent by default.
To prevent override, set inheritFromParent: true in the child policy (or set the child policy to match the parent).
Boolean constraints: booleanPolicy: true or false.
List constraints: listPolicy with allowedValues, deniedValues, or allValues: ALLOW/allValues: DENY.
Edge Cases
Custom constraints: You can create custom constraints using YAML with a CEL (Common Expression Language) condition. The exam may ask about custom constraints but rarely.
Policy at project level vs folder level: If a policy is set at both folder and project, the project-level policy takes precedence (overrides).
Policy with no effect: If a constraint is not applicable to a resource (e.g., compute.vmExternalIpAccess on a Cloud Storage bucket), it is ignored.
How to Eliminate Wrong Answers
If the answer mentions IAM roles or permissions, it is likely wrong for a question about restricting resource configurations.
If the answer says "policy cannot be overridden," check if the scenario mentions a child policy — it can be overridden.
If the answer uses a constraint name that doesn't exist (e.g., compute.publicIp), eliminate it.
If the answer suggests using a boolean constraint when a list constraint is needed (or vice versa), it is wrong.
Organization policies are separate from IAM and control resource configuration, not user permissions.
Policies can be set at organization, folder, or project level; child policies override parent by default.
Two types of constraints: list (allow/deny specific values) and boolean (true/false).
Common exam constraints: `compute.vmExternalIpAccess`, `storage.publicAccessPrevention`, `gcp.resourceLocations`, `iam.disableServiceAccountKeyCreation`.
To prevent child override, set `inheritFromParent: true` in the child policy.
Policies take effect immediately; existing resources are not automatically remediated.
Use `gcloud resource-manager org-policies` commands to manage policies.
All policy changes are logged in Cloud Audit Logs.
Custom constraints can be created using CEL expressions.
Organization policies are evaluated during resource creation and modification; they do not affect read-only operations.
These come up on the exam all the time. Here's how to tell them apart.
List Constraints
Used when you need to allow or deny specific values (e.g., allowed regions).
Configured with `listPolicy` containing `allowedValues` or `deniedValues`.
Can also use `allValues: ALLOW` or `allValues: DENY` to allow/deny all values.
Example: `constraints/gcp.resourceLocations` with allowed list of regions.
More flexible for granular control.
Boolean Constraints
Used for simple on/off restrictions (e.g., disable serial port access).
Configured with `booleanPolicy: true` or `false`.
Cannot specify individual values; it's all or nothing.
Example: `constraints/compute.disableSerialPortAccess` set to true.
Simpler to configure but less flexible.
Mistake
Organization policies are the same as IAM policies.
Correct
IAM policies control who can perform actions (e.g., create VMs). Organization policies control what configurations are allowed (e.g., VMs cannot have public IPs). They are complementary but distinct.
Mistake
A policy set at the organization level cannot be overridden by a project-level policy.
Correct
By default, child policies override parent policies. You must explicitly set `inheritFromParent: true` in the child policy to prevent overriding, or set the child policy to match the parent.
Mistake
Organization policies affect existing resources automatically.
Correct
Policies only affect new resource creation or modification. Existing resources are not automatically changed; you must manually remediate them to comply.
Mistake
Boolean constraints allow you to specify a list of allowed values.
Correct
Boolean constraints can only be true or false. List constraints allow you to specify allowed or denied values. They are different types.
Mistake
You can set a policy at the project level only, not at the folder or organization level.
Correct
Policies can be set at organization, folder, and project levels. The organization level is the most common for enterprise-wide enforcement.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An IAM policy controls who (which users or service accounts) can perform actions on resources. An organization policy controls what configurations are allowed on resources, regardless of who is performing the action. For example, IAM can allow a user to create VMs, but an organization policy can deny creating VMs with public IPs. Both are needed for comprehensive security.
Yes, by default a child policy (at folder or project) overrides the parent policy. To prevent this, you can set the child policy to inherit from the parent by using `inheritFromParent: true` in the child policy's YAML, or you can set the child policy to match the parent.
Use the command `gcloud resource-manager org-policies list-constraints --organization=ORG_ID`. This lists all predefined constraints available for your organization. You can also view them in the Cloud Console under IAM & Admin > Organization Policies.
The policy does not affect existing resources. It only applies to new resource creation or modification of existing resources. You must manually update or delete existing resources to comply with the policy. The Security Command Center can help identify non-compliant resources.
Yes, you can create custom constraints using a YAML file with a CEL (Common Expression Language) condition. Custom constraints allow you to enforce rules not covered by predefined constraints. They are applied similarly to predefined constraints.
Check the error message, which will include the constraint name that caused the denial. Use `gcloud resource-manager org-policies describe` to view the policy at the relevant level. Also, check Cloud Audit Logs for the denial event. Ensure the policy is not set at a higher level in the hierarchy.
By default, policies are inherited from parent to child, but a child can override the parent's policy. If no policy is set at a level, the parent's policy applies. This is known as 'inheritance with override.' To enforce a policy without override, you must set the child policy to match the parent or use `inheritFromParent: true`.
You've just covered GCP Organization Policies — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?