Policy guardrails#

Policy guardrails check the exact Terraform plan before Apply. Tenant guardrails add organisation-specific controls to the platform safety rules that are always active.

Navigate: left navigation → Provisioning → Policy guardrails.

Create a guardrail#

Select New guardrail. The panel guides you through three choices.

1. Condition#

Choose what the plan must be checked for. The form asks only for values required by that condition.

Condition

When it matches

Limit the size of a change

Total changed Resources exceed the chosen maximum.

Limit resource deletions

Planned deletions exceed the chosen maximum. Set 0 to require a deletion-free plan.

Block specific resource types

The plan contains an exact Terraform type on the deny list.

Allow only specific resource types

The plan contains a type outside the allow list.

Prevent resource replacements

Terraform proposes replacing any Resource.

Use Terraform resource types such as azurerm_storage_account, not product display names.

2. Outcome#

  • Block apply prevents the exact plan from running until it complies.

  • Warn only records a visible advisory without blocking Apply.

The preview restates the rule in plain language before you save it.

3. Identity#

Enter a clear name such as block-all-deletes and leave the guardrail enabled. Open Evaluation order only when order matters; lower priority values run first.

New policy guardrail panel with condition, outcome, identity, preview and enabled switch

The live preview shows exactly what will happen when the condition matches.#

Select Create guardrail.

Start with a small baseline#

A practical initial set is:

  1. block-all-deletes — maximum deletions 0, Block apply;

  2. warn-large-plans — a change limit that matches your review process, Warn only;

  3. block-replacements — Block apply for stateful workloads;

  4. provider-specific deny lists for resource types your organisation never permits.

Use allow lists only for genuinely narrow environments. An incomplete allow list can block valid module updates.

Versioning and evaluation#

Creating or editing a guardrail creates a new immutable version. Previous versions remain available with their author and timestamp.

For every Plan, Reply CMP records:

  • the guardrail versions evaluated;

  • each result and outcome;

  • a deterministic policy fingerprint;

  • the exact plan, plan JSON and source-manifest hashes.

Changing a guardrail or Resource after Plan requires a fresh Plan. An approval or override for one saved plan never applies to another plan.

Platform safety rules cannot be edited by tenant users. They protect runner identity, state custody, immutable source and exact-plan execution even when no tenant guardrail exists.

Respond to a denied Plan#

  1. Open Deployment → Operations.

  2. Expand the newest operation and review every blocking result.

  3. Correct the Resource input or guardrail.

  4. Start a fresh Plan.

When organisation policy permits it, an authorised superuser can override only the displayed saved plan and must record a meaningful reason. The identity, reason and plan binding remain audit evidence.

Treat state-adoption-required as a migration signal, not a normal policy to override. Follow Adopt an existing Deployment.