Professional Cloud Security Engineer

Evaluate Policy Inheritance and Hierarchy Enforcement

The Google Cloud resource hierarchy allows security teams to set policies at three main levels: the organization at the top, folders in the middle, and projects at the bottom. When a policy is set at a higher level, it automatically flows down to all child resources through policy inheritance, so you do not have to repeat the same rule for every project. The effective policy on any specific resource is determined by combining inherited rules from parent nodes with any local rules applied at that level.

When a parent policy and a child policy conflict, administrators choose whether the child merges with or overrides the parent. Setting a policy to override stops the inheritance and enforces only the local rules defined at that hierarchy node. For list-based constraints, the under: prefix lets you target an entire folder or all projects under a parent in one command. When merging is selected, the system builds an effective policy that combines allowed and denied values from all ancestor resources, where denied values take precedence over allowed ones.

Before deploying policies to production, teams use dry-run mode to monitor violations without blocking operations. A dry-run configuration includes a dryRunSpec alongside the live spec, and violations appear in audit logs for review. Dry-run policies follow the same inheritance rules as live policies, so changes to parent policies automatically affect the dry-run behavior. The Policy Analyzer and Cloud Asset Inventory tools help teams see the exact enforcement state across complex resource trees and resolve conflicts before they cause security gaps.

Design and Apply Custom Organization Policy Constraints

Organization Policy Constraints are rules that define what configurations are allowed or denied on Google Cloud resources. While Google provides many pre-built constraints, security teams can also create custom constraints using YAML or the Constraint Template Language (CEL) to meet specific compliance requirements that pre-built options do not cover.

To build a custom constraint, you specify which resource types it applies to, such as Compute Engine instances or Cloud Storage buckets, and write a CEL expression that evaluates a condition. For example, you could write a constraint that checks whether a virtual machine has its external IP disabled or whether a storage bucket uses a specific encryption standard. This granularity lets you enforce security rules that match your organization's exact needs.

Custom constraints can be applied at any level of the resource hierarchy. Applying one at the organization level enforces it across the entire enterprise, while applying it at a folder targets a specific department, and applying it at a project targets a single application. Policies set at higher levels cascade down to child resources, but lower levels can override higher ones when more specific rules are needed. When a user attempts to create or modify a resource, the constraint is evaluated automatically, and any request that violates the constraint is denied before the change takes place.

Manage Policy Lifecycle and Enforcement States

Organization policies move through a lifecycle that includes creation, testing, enforcement, and updates. You begin by creating a policy using either a managed constraint (a pre-built rule from Google) or a custom constraint (one you define yourself). After creation, you can test the policy in dry-run mode to see how it would impact your environment without blocking legitimate operations.

Organization policies support three enforcement states. The first state is enforced, which actively blocks any operations that violate the constraint. The second state is dry-run mode, which logs violations in audit logs without blocking the operations, giving teams visibility into non-compliant configurations before they cause problems. The third state is disabled, where the policy exists in the system but does not actively enforce any restrictions. Choosing between these states depends on whether you are testing a new rule, rolling out a verified control, or temporarily suspending a constraint.

After testing in dry-run mode, you set the live policy using the spec flag, and it takes effect within approximately 15 minutes. Throughout the policy lifecycle, the Policy Analyzer helps you understand how policies interact across your resource hierarchy and identify compliance gaps. The hierarchical nature of policies means that a policy set on an organization automatically applies to all folders and projects beneath it, but you can override inherited policies at lower levels to create more specific restrictions when needed.