Policy as Code

Policy as code enforces your organization's rules on Terraform changes automatically, by evaluating the plan against policies before apply. "No public S3 buckets." "Every resource must carry a cost-center tag." "Only approved instance types in production." Each is a rule a human used to enforce by reading every plan; policy as code turns it into a check that runs on every change and blocks the ones that violate it.

This is governance that scales past the point where a human gatekeeper can read every diff. The two main paths are Sentinel, HashiCorp's policy language built into the paid HCP Terraform and Enterprise platform, and OPA with Conftest, the open-source alternative that evaluates Rego policies against the plan in any pipeline. Both work on the plan's JSON representation, so they judge what Terraform is actually about to do — not the source text, the real proposed change.

What Policy as Code Enforces

The rules fall into a few buckets: tagging (every resource has the required keys), security (no public access, encryption required), cost (no instance type above an approved size, no more than N of an expensive resource), and approved-resource lists (only the regions, types, or services the org sanctions). The check evaluates the plan, so it sees the concrete values about to be created — a bucket with public-access blocks disabled, a security group with an open ingress — and decides pass or fail before any of it reaches AWS.

Sentinel

Sentinel is HashiCorp's own policy framework, integrated directly into HCP Terraform and Terraform Enterprise. You write policies in the Sentinel language, attach them to a workspace, and every run evaluates them between plan and apply. Its advantage is the tight integration: no wiring, the enforcement levels are built in, and policy results show up in the run UI alongside the plan. Its constraint is that it is tied to the paid HashiCorp platform — you do not run Sentinel in a bare open-source pipeline.

OPA and Conftest

The open-source path is Open Policy Agent and its Conftest wrapper, using the Rego policy language. You export the plan to JSON with terraform show -json, then evaluate Rego policies against it in any CI system. Nothing is tied to a vendor platform — it runs in GitHub Actions, GitLab CI, or a shell script. The cost is that you wire it up yourself: export the plan, run the evaluation, decide how a failure blocks the pipeline.

package terraform.s3

# deny any S3 bucket whose ACL makes it public
deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket_acl"
  resource.change.after.acl == "public-read"
  msg := sprintf("S3 bucket %s must not be public-read", [resource.address])
}

The policy reads resource_changes from the plan JSON, matches any bucket ACL set to public-read, and returns a deny message naming the exact resource. Run with conftest test plan.json in CI, it fails the build on a match and prints the message — the engineer sees precisely which bucket and why.

Enforcement Levels

Not every policy should block. The enforcement levels — advisory, soft-mandatory, and hard-mandatory — let you choose the consequence per policy. Advisory warns and lets the run continue, the right setting for a new rule you are rolling out. Soft-mandatory blocks but allows an authorized override, for rules with legitimate exceptions. Hard-mandatory blocks with no override, for the guardrails that must never bend — no public data store, no unencrypted database. Setting every policy to hard-mandatory is a mistake: it blocks legitimate exceptions with no escape hatch and pushes people to disable the system entirely.

Policy vs Static Analysis

Policy as code and the security scanners from the previous topic overlap but are not the same. Scanners ship generic, industry-standard rules — they know a public bucket is generally bad. Policy as code encodes your org's specific rules: your tagging schema, your approved instance types, your cost ceilings, your sanctioned regions. Use scanners for the generic security baseline and policy as code for the rules that are particular to your organization. Duplicating a scanner's generic rules in policy code is wasted effort; the point of policy code is the rules no off-the-shelf scanner could know.