Custom Organization Policies and Inheritance Enforcement

Custom organization policy constraints are administrator-defined rules that restrict specific resource fields when predefined constraints are not precise enough. A custom constraint defines the condition to check, and a custom organization policy attaches that constraint to an organization, folder, or project so create and update requests must satisfy it. Together they enforce consistent security, compliance, and governance controls across the resource hierarchy.

1.1Purpose of Custom Constraints

Custom constraints provide field-level control over settings that predefined policies do not cover, such as specific restricted fields or non-standard configurations. Memorystore for Valkey (opens in a new tab) uses custom organization policies to enforce consistent instance configurations and restrictions. Every new or changed instance is checked against the same centralized rules:

• security controls that require approved configurations
• compliance requirements that limit allowed field values
• governance standards that keep instances consistent across teams

Custom constraints do not replace predefined policies; they extend predefined policies for cases that need precise allow or deny logic.

1.2Defining Custom Constraints With YAML and CEL

A custom constraint definition names the service resource, the field to control, and the allowed or denied condition for that field. The definition is written in YAML and uses a Constraint Template Language (CEL) expression to evaluate the resource value in the request, such as requiring a setting to be present or prohibiting a risky value. The organization policy then references that custom constraint and sets enforcement for the attached resource node.

The policy depends on the constraint, and the resource request depends on the policy. First the administrator defines the constraint, then the administrator creates the policy that uses it, and only after both exist does the control plane evaluate new requests against the CEL condition. Because the logic lives in the constraint, the same reusable rule can support different policies in different parts of the organization.

1.3Applying Policies at the Organization, Folder, or Project Level

A custom organization policy attachment controls which configurations are allowed below the point where the policy is attached. A policy attached at the organization node flows down to every folder and project beneath it, while a policy attached at a folder flows down only to the projects and resources in that folder, and a policy attached at a project applies only inside that project. This hierarchy lets security owners set broad guardrails at the top and add stricter rules lower down without rewriting the constraint.

Choose the attachment point by blast radius and ownership. Use the organization level when the requirement applies to all workloads, such as mandatory encryption or location limits. Use the folder level when different business units or environments need different rules, and use the project level for exceptions or tighter controls owned by a single team.

1.4Enforcement Behavior and Limitations

Enforcement of a custom organization policy happens when the service evaluates an incoming request against the active policy before the resource is created or changed. Memorystore for Valkey enforces organization policies on two operations: creating an instance and updating an instance. Traffic flows from the user or automation to the service API, the Organization Policy check evaluates the custom constraint condition, and the request is allowed only when the field values satisfy the policy.

Policy evaluation is not retroactive. Changes to organization policies do not apply retroactively to existing instances, and a new policy has no effect on existing instances until those instances are created or updated. Existing non-compliant resources continue to run and must be identified by audit and remediated by an update or recreation.

Evaluation of policy inheritance determines the effective policy that actually enforces on a resource after combining policies from every ancestor level. The Organization Policy Service (opens in a new tab) provides centralized control through an organization policy, which is built from a constraint plus optional conditions, and that policy can be attached at the organization, folder, or project level. By default the attachment cascades downward from organization to folder to project, so a lower resource inherits every applicable policy from above unless a local rule changes the result.

2.1How Policies Cascade From Organization to Project

The cascade model applies a parent organization policy to a resource and all of its descendants in the Google Cloud resource hierarchy. For example, if enforcement is placed on a folder, Google Cloud enforces the same policy on all projects in that folder and on resources inside those projects. Enforcement happens when a CREATE or UPDATE operation is attempted, so a noncompliant create or update fails while the policy is enforced. Changes to organization policies can take up to 15 minutes to be fully enforced across the hierarchy, and any project added later under an organization or folder automatically inherits the constraints already enforced there.

2.2List Constraints: Merge Behavior and Subtree Strings

List constraints use allowed values and denied values to control which services or resources can be used, and a child policy merges with the policy inherited from its parent. The merged set of values is then evaluated under hierarchy evaluation rules to produce the new effective policy for that resource. Organization policies using list rules cannot have more than 500 individual allowed or denied values and cannot be more than 32 KB in size.

Some list constraints also support hierarchy subtree strings that expand enforcement to a whole branch with one value. A value with the under: prefix, such as under:folders/VALUE_A, under:organizations/VALUE_X, or under:projects/VALUE_Y, acts on the named root resource and all of its children. For example, using projects/PROJECT_ID with constraints/compute.storageResourceUseRestrictions allows or denies Compute Engine storage use for that project and all of its children. Applying a subtree denial follows an ordered workflow:

1. Describe the current policy: Run gcloud org-policies describe with CONSTRAINT_NAME and --organization, --folder, or --project to see whether a policy is already attached.
2. Set the policy with a subtree value: Create a policy file that contains deniedValues with - under:folders/VALUE_A and apply it with gcloud org-policies set-policy.
3. Verify the effective result: Run gcloud org-policies describe CONSTRAINT_NAME --effective to confirm the resolved policy denies the folder and all child resources.

Only after the set operation completes does the 15-minute enforcement delay begin, during which descendants converge on the new effective policy.

2.3Boolean Constraints: Override Behavior

Boolean constraints use a simple enforce: true or enforce: false rule to turn a restriction on or off, and a child resource resolves conflict by overriding the parent rather than merging. In the console this is configured by selecting Override parent's policy on the child resource, adding a rule, and choosing whether enforcement is on or off. The override replaces inherited enforcement for that branch, so a project can relax or tighten a folder or organization boolean policy for its own scope.

Boolean policies support conditional rules scoped by tags, but a tagged policy must still include at least one unconditional rule or the policy cannot be saved. Policies can first be enforced in dry-run mode through dryRunSpec and then promoted to live enforcement through spec with gcloud org-policies set-policy, with each change requiring up to 15 minutes to take effect. The same override pattern applies to custom constraints such as custom.enforceLoggingEnabled or custom.deleteProtectionRequired, which are defined once at the organization level and then enforced with enforce: true at the organization, folder, or project level.

2.4Determining the Effective Policy for a Resource

The effective policy for a resource is the final enforcement decision after inherited policies and any local merge or override are resolved together. The describe --effective command returns that resolved view, while a plain describe returns only the policy directly attached to the named resource. Policy Analyzer (opens in a new tab) for Organization Policy provides the same resolution at scale through an analysis query composed of a scope and a constraint, where the scope is an organization and the constraint is the resource name of the constraint being checked.

For each organization policy detected in the scope, Policy Analyzer returns a result entry with related ancestry context:

• consolidatedPolicy: names the resource to which the organization policy is attached and the effective enforcement on that resource under hierarchy evaluation rules
• project: identifies the project resource to which the consolidated policy belongs
• folders: identifies any folder resources that are ancestors of the attached resource

The difference between merge and override controls how conflicts resolve when both levels define the same constraint:

Manage Policy Lifecycle and Enforcement States is the practice of moving an organization policy from testing to live enforcement without breaking production workloads. In Google Cloud, the Organization Policy Service (opens in a new tab) stores two parallel definitions for the same constraint on the same resource: spec for the live policy that denies violating actions, and dryRunSpec for the test policy that only audit-logs violations. The lifecycle moves in order from simulation to dry run to live enforcement, with updates applied separately to each definition.

3.1Enforcement States for Organization Policies

Enforcement states control whether a violating CREATE or UPDATE request is blocked, observed, or ignored by the Organization Policy Service. The live spec uses enforce: true to deny violations and enforce: false to disable enforcement, while dryRunSpec runs the same rules in observation mode where violations are audit-logged but the requesting action is still allowed.

The disabled state is useful when a policy must be retained on an organization, folder, or project but temporarily turned off, while dry run is useful when impact must be measured before blocking work.

3.2Policy Definitions in spec and dryRunSpec

Policy definitions in spec and dryRunSpec are the two versioned rule sets that define one organization policy on one resource in the hierarchy. Both definitions name the same resource path, such as projects/PROJECT_ID/policies/CONSTRAINT_NAME or organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME, and both contain a rules list with enforce and optional parameters and condition blocks. The Organization Policy Service evaluates the live spec against incoming requests for denial decisions, and evaluates dryRunSpec separately for audit-logging without denial.

A policy YAML file can carry both definitions at once, which lets an administrator stage a future rule in dryRunSpec while the current rule remains live in spec. Changes to either definition require up to 15 minutes to be fully enforced across Google Cloud. If a rule uses a tag-based condition to scope enforcement, the policy must also include at least one unconditional rule or the Organization Policy Service will reject the policy on save.

3.3Testing Impact Before Enforcement

Testing impact before enforcement uses Policy Simulator and dry-run mode to reveal violations before they block production changes. Policy Simulator for Organization Policy scans current resource configurations in an organization scope and reports where a proposed constraint and policy would already violate, so administrators see the blast radius before any enforcement begins. Dry-run mode then extends that insight forward in time by audit-logging new violating actions as they occur, without denying them.

This two-stage test boundary sits between the administrator and production enforcement. First, simulation reads existing state and reports violations with no effect on traffic. Then, dry-run policy observes live request flow from callers to services and writes audit log entries for requests that would have been denied. Only after both stages confirm acceptable impact should the same rules be promoted to the live spec.

3.4Promoting and Updating Policies Across the Hierarchy

Promoting and updating policies across the hierarchy is the ordered workflow that moves a rule from draft to dry run to live enforcement on an organization, folder, or project. The child resource depends on its parent by inheritance, so an override at a lower level requires selecting Override parent's policy before adding rules.

1. Test changes: Run Test changes in the console with Policy Simulator, or run gcloud policy-intelligence simulate orgpolicy --organization=ORGANIZATION_ID --policies=POLICY_PATH, to preview violations against current resources.
2. Set dry run: Click Set dry run policy in the console, or run gcloud org-policies set-policy POLICY_PATH --update-mask=dryRunSpec, to start audit-logging violations without denial.
3. Verify behavior: Review audit logs and dry-run findings over time to confirm that legitimate create, update, restore, and clone operations are not flagged unexpectedly.
4. Set live policy: Click Set policy in the console, or run gcloud org-policies set-policy POLICY_PATH --update-mask=spec, to begin denying violating actions, with full effect after up to 15 minutes.

The same update path handles later lifecycle changes, such as tightening a condition, changing enforce from true to false, or replacing parameters through the organizations.policies.create API. Because each update is applied with an explicit update mask to either spec or dryRunSpec, dry-run testing can continue on a new revision while live enforcement remains stable on the old revision.

3.5Auditing and Maintaining Ongoing Compliance

Auditing and maintaining ongoing compliance is the continuous review of enforced and dry-run policies to keep security constraints aligned with operational reality. Policy Analyzer for Organization Policy queries a scope, such as an organization, for a specific constraint and returns each attached policy with its consolidatedPolicy and effective enforcement after hierarchy evaluation, including the project and ancestor folders. Dry-run audit logs complement that point-in-time view by recording which new actions would have violated policy during the observation window.

Together, Policy Analyzer results and dry-run audit logs let administrators decide whether to keep, update, or delete a policy at each level of the resource hierarchy. When a dry-run revision proves safe, its rules are copied into the live spec for enforcement; when live enforcement causes unexpected failures, such as blocked service-agent role grants, the policy can be narrowed with tag conditions or temporarily disabled while the issue is resolved.

Key Facts

• Custom organization policy constraints use YAML and CEL expressions to control specific resource fields, and the attached policy enforces on create and update operations without retroactively fixing existing resources.
• A policy attached at the organization flows to all folders and projects, a folder policy flows only to projects in that folder, and a project policy applies only inside that project.
• List-constraint child policies merge with inherited values, while boolean-constraint child policies override the parent enforcement for that branch.
• The live policy is stored in spec and the test policy is stored in dryRunSpec, and changes to either take up to 15 minutes to be fully enforced.
• The effective policy is the resolved result after inheritance, shown by gcloud org-policies describe CONSTRAINT_NAME --effective and by Policy Analyzer results with consolidatedPolicy, project, and folders context.