Policy, Registry, and Governance

Scenario: Every team at a growing company independently writes its own version of a "create a network" module, and a year later the company has a dozen subtly different modules applying inconsistent encryption settings, inconsistent tagging, and no shared cost controls at all.

As an organization scales past one or two teams using Terraform, purely social conventions ("please remember to tag your resources") stop being enough, and this is where platform-level governance tooling earns its place. A private module registry is the direct fix for the scenario above: it gives every team one shared, versioned, documented place to find and consume the company's own approved building blocks - a network module, a certificate module - rather than each team quietly reinventing (and subtly breaking) the same wheel.

Policy as code - tools like Sentinel or Open Policy Agent (OPA) - lets an organization write rules that automatically evaluate every proposed plan against real, codified requirements before it's ever allowed to apply: deny any plan that opens a public ingress rule on an administrative port, require an owner and cost-center tag on every resource, cap which instance classes are approved for use. Every policy you write should distinguish clearly between advisory (a warning, but a human can still proceed) and mandatory (the plan is hard-blocked) - and should explain, in its own error message, exactly what the author needs to change to comply, not just that something failed.

Analogy: Good platform governance functions like a paved road with guardrails on a highway, not a checkpoint at every intersection. Teams actually move faster on the paved road, because sensible defaults and automatic warnings are built directly into the route they'd naturally take anyway - the guardrails only become visible right at the moment someone's about to drive off a genuinely dangerous edge.

A worked configuration

# Policy intent expressed conceptually:
# - deny public ingress on administrative ports
# - require owner and cost-center tags
# - cap unapproved instance classes

Actively measure your policy suite's false-positive rate, and provide a documented, legitimate exception workflow for the rare case a rule genuinely shouldn't apply. A mandatory policy that teams have quietly learned to route around through some workaround isn't governance anymore - it's theater that gives a false sense of control while providing none. The strongest production setups combine policy-as-code with good module design (making the safe, compliant path also the easiest path to take) and provider-level or cloud-native controls, rather than relying on any single layer alone.

Common mistakes in production

• Letting every team independently author its own version of a common module (networking, certificates) instead of maintaining one shared, versioned module in a private registry.
• Writing a mandatory policy so strict or poorly explained that teams routinely find workarounds to bypass it - a rule nobody actually follows provides no real governance.

Goal: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it. Reinforce this lesson in the tf-lifecycle-safety Terraform lab. Open /labs/terraform and choose slug tf-lifecycle-safety; the lab runs real Terraform against the offline FakeCloud provider.