What Is IaC Governance?

IaC governance is how a team decides which infrastructure changes are allowed to run, who is allowed to run them, and what evidence remains after they do.

It sits above style guides and module conventions. A repo can follow every Terraform lint rule and still have no governance if anyone with a cloud key can apply from a laptop.

The four controls that actually matter

1. Identity. Applies are done as a role, not a personal long-lived key. SSO and group membership decide who can request a change. SCIM keeps that list honest when people leave.
2. Plan policy. Automated rules run against the plan: public ingress, unencrypted stores, forbidden regions, missing owners. Blocking vs warning vs informational — see policy-as-code patterns.
3. Human review when risk is high. A person sees the same plan the robot will apply, plus blast radius and policy output. That is approval design, not a ticket that says “LGTM.”
4. Exceptions with an expiry. Temporary exceptions are fine. Permanent silent exceptions are how production drifts out of policy.

If you only have (2), you have a linter. If you have all four, you have a control plane.

What IaC governance is not

• A module catalog. Reuse helps, but a catalog without apply rules is a library.
• A wiki of “thou shalt not.” If the rule is not evaluated on the plan, it is documentation.
• Stopping all ClickOps by memo. Console changes will happen. Governance includes detecting that drift and routing a reconcile.

A minimum viable loop

For one production account:

1. Remote state with locking.
2. CI that runs fmt, validate, and a saved plan.
3. Five to ten blocking policies on the highest-risk resource types.
4. A named approver group for IAM, network, and data stores.
5. Drift scan on a schedule, with a classified report.

That is enough for one production account. More teams and clouds add policy packs, approval workflows, and SSO + SCIM so the same rules travel with the plan — not a PDF of standards.