Policy-as-Code Patterns for IaC Governance Teams

Infrastructure governance fails when policy lives in documentation, tribal knowledge, or ad-hoc scripts.

Policy-as-code makes governance executable: you can run it on every plan, show results in reviews, and ensure the same rules apply across teams and clouds.

Start with policy tiers

Most policy catalogues benefit from three tiers:

• Blocking policies: fail the pipeline when violated.
• Warning policies: surface a review requirement, but allow controlled overrides.
• Informational policies: track hygiene and risk trends without blocking deployments.

This tiering prevents “all red” pipelines that people learn to ignore.

Write policy with meaningful messages

A good policy failure tells the reviewer:

• what resource and field failed,
• what the rule is trying to protect,
• what remediation is expected.

Ambiguous “policy failed” messages create friction and eventually lead to exceptions that are never revisited.

Test both deny and allow

Policy tests should cover:

• examples that must fail (denies),
• examples that must pass (allows).

You should also test for edge cases where input structure changes, such as new resource fields added by providers.

Integrate policy evaluation into the pipeline

A typical safe ordering:

1. Validate and generate the plan artefact.
2. Evaluate policies against plan output.
3. Require human review for warning-level issues.
4. Apply the approved plan (the plan reviewed is the plan applied).

OrchesTerra’s governed workflows are built around this model. See policy packs for a starting point.

Common pitfalls

1. No policy tests.
2. Only testing the happy path.
3. Blocking on policies that should be warning-tier.
4. Writing policies without a remediation story.
5. Letting exception processes become permanent.

Start small: pick 5–10 rules that cover your highest-risk misconfigurations, then evolve with feedback from real plans.

Policy-as-code is one control. The broader frame is what IaC governance is.