Test Your Infrastructure: Policy-as-Code and Guardrails

Quickstart

These are the highest-impact guardrails you can add in a day. The goal is not to “boil the ocean” — it’s to block the most expensive misconfigs and make safe changes easy.

Overview

Infrastructure-as-Code gives you repeatability. But it also makes it easy to repeat mistakes at scale. A single wrong variable, a permissive security group, or an “it’s just staging” shortcut can turn into a production incident once that pattern is copied everywhere.

Testing your infrastructure is about catching those mistakes early, before they become real resources. The techniques in this post apply whether you use Terraform, Kubernetes manifests, Helm charts, or cloud-native templates: the core idea is the same — treat infrastructure changes like code changes with automated checks.

Core concepts

To “test infrastructure,” you need a few shared definitions. These help you choose tools and design policies that survive real-world change (new services, new providers, new teams).

Policy-as-code

Policy-as-code is the practice of expressing rules (security, compliance, cost, reliability, naming, tagging) as code that can be executed automatically. Policies live in version control, are reviewed via pull requests, and run in CI/CD or at deploy time.

Guardrails

Guardrails are the enforcement mechanism: they make sure policy is applied consistently. Some guardrails are “hard” (deny the change), others are “soft” (warn, create a ticket, require approval). Mature organizations typically use both, depending on risk.

Shift-left vs. fail-safe

What to test: intent, not implementation details

The most durable policies test intent (“no public DB access”) rather than fragile implementation details (“this specific resource name must exist”). Intent-based policies survive refactors and module changes.

Step-by-step

This walkthrough builds a concrete workflow: generate a Terraform plan, run policy tests against the plan, and block merges when rules are violated. The same pattern works for other IaC inputs (Kubernetes manifests, Helm output, etc.) — you just swap the “thing to evaluate.”

Step 1 — Decide what you’re enforcing (and at which layer)

Don’t start by choosing a tool. Start by choosing rules and enforcement points. Your first goal is coverage of high-risk mistakes, not a perfect policy platform.

Step 2 — Generate a plan artifact you can test

For Terraform, the most reliable “input” to policy testing is the plan (what Terraform intends to change), not raw HCL. Convert the plan to JSON so a policy engine can evaluate it deterministically.

# 1) Initialize and create a plan file (do not apply)
terraform init -input=false
terraform plan -input=false -out=tfplan

# 2) Convert the plan into machine-readable JSON
terraform show -json tfplan > plan.json

# 3) Run policy tests against the plan (example: Conftest/OPA)
conftest test plan.json -p policy

Step 3 — Write one policy rule that blocks a real incident

The best starter rule is something your team has tripped over before. A classic example: “Don’t allow public ingress to sensitive ports.” Below is a tiny policy sketch that denies changes introducing public ingress on port 22 (SSH) to 0.0.0.0/0. Adapt the idea to your cloud/provider and your ports.

package terraform.guardrails

default deny = []

# Deny when a security rule allows 0.0.0.0/0 to port 22.
# This is intentionally conservative and meant as a starting point.
deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "aws_security_group_rule"
  rc.change.after.cidr_blocks[_] == "0.0.0.0/0"
  rc.change.after.from_port <= 22
  rc.change.after.to_port >= 22
  lower(rc.change.after.protocol) == "tcp"
  msg := sprintf("Public SSH ingress is not allowed: %s", [rc.address])
}

Step 4 — Wire policies into CI so unsafe changes can’t merge

The workflow is: run formatting/validation, create a plan, convert to JSON, test policies, and fail if denied. The key guardrail: treat policy test failures like unit test failures — no merge until fixed or approved via exception.

name: iac-guardrails

on:
  pull_request:

jobs:
  terraform-policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.7.5

      - name: Terraform fmt + validate
        run: |
          terraform fmt -check -recursive
          terraform init -input=false
          terraform validate

      - name: Create plan and convert to JSON
        run: |
          terraform plan -input=false -out=tfplan
          terraform show -json tfplan > plan.json

      - name: Policy tests (fail PR if denied)
        run: |
          conftest test plan.json -p policy

Step 5 — Define an exception process that doesn’t rot

Exceptions are normal. “Permanent exceptions” are how guardrails die. A good exception process is explicit, time-bound, and auditable — and ideally makes the risky decision visible.

Step 6 — Add a second enforcement layer for “must not happen” rules

CI reduces risk dramatically, but it’s not absolute. For the highest-risk categories (public exposure, privileged access, unencrypted storage), add deploy-time enforcement where possible. In Kubernetes, this is often admission control. In cloud orgs, it might be org policies / service control rules / centralized constraints.

Common mistakes

Guardrails fail for predictable reasons. Avoid these pitfalls and your policy-as-code program will feel like a productivity boost instead of a bureaucracy generator.

FAQ

What is policy-as-code in simple terms?

Policy-as-code means writing infrastructure rules as executable code and running those rules automatically on every change. Instead of relying on a checklist or a wiki page, your CI/CD pipeline enforces requirements consistently and produces clear failures when a change violates policy.

Where should guardrails run: pre-commit, CI, or deploy-time?

Ideally, in multiple places. Pre-commit is fastest but easiest to bypass. CI is the best default gate for most teams. Deploy-time enforcement is the “seatbelt” for high-risk rules where bypass is unacceptable. Runtime checks catch drift and out-of-band changes.

Should policies block merges, or just warn?

For low-risk rules (style, naming), warnings can be enough. For high-risk rules (public exposure, encryption, privileged access), blocking is usually the right end state. A good rollout starts with warnings for adoption and flips to blocking once teams have a clear path to comply.

What’s the best way to test Terraform with policy-as-code?

Test the plan. Generate a plan file, convert it to JSON, and evaluate it with your policy engine. Plan-based testing aligns policy with what Terraform intends to do, reducing false positives and catching real risky diffs.

How do we handle legitimate exceptions without weakening security?

Use time-bound, reviewed exceptions with explicit mitigations. Store exceptions in version control, require approvals for high-risk categories, and regularly review expired or unused exceptions. If exceptions keep appearing for the same reason, update the standard workflow or the policy itself.

How do we prevent drift if people change infrastructure manually?

First, limit manual changes by using least-privilege and clear operational paths. Second, add drift detection: scheduled plan checks, cloud audit alerts, or runtime policy monitoring depending on your platform. Drift isn’t just “messy” — it makes plans unreliable, which makes deployments risky.

Cheatsheet

A scan-fast checklist for policy-as-code and infrastructure guardrails that actually work.

Wrap-up

Infrastructure breaks in boring ways: a CIDR that’s too wide, a policy flag that got turned off, a secret that ended up in the wrong place. Policy-as-code and guardrails move those failures to where they belong — the pull request — and make safe infrastructure changes routine.

The end goal isn’t to add friction. It’s to create confidence: every merge is safer, every deployment is more predictable, and “security checks” become part of normal engineering hygiene.

Related posts

• Terraform Mistakes: State, Modules, and the ‘One Big Plan’ Trap
• Secrets in CI/CD: The Right Way to Store and Rotate Keys
• Kubernetes Security Basics: RBAC, Network Policies, and Images
• Docker for Developers: Images, Layers, and Caching Explained
• Kubernetes Without Tears: Pods, Services, Ingress in One Story
• CI/CD That Stays Green: Pipeline Patterns That Scale