Stop 09 · Infrastructure as CodeTopics · 9/9

IaC Testing & Validation

In short

A one-character typo in infrastructure code can open a database to the internet or delete a production network. Cheap automatic checks catch most of these before anyone types apply.

Validating infrastructure code before applying it to real environments — syntax checks, policy checks (e.g. 'no public S3 buckets'), and plan review as a lightweight but essential testing layer.

The mascot, as a tailor with a measuring tape, pins a trial shirt onto a dress form.

Think of it like this

The tailor's trial fitting

A good tailor doesn't cut the costly fabric straight away. They tack a trial shirt, check the fit on you, adjust, and only then do the final stitching. IaC checks are that trial fitting: format, validate, lint and plan before the real apply.

Watch it happen

Checks on every pull request

fmt

validate

lint

policy

plan

review

1/6terraform fmt -check fails the build if code isn't formatted. Cheap, and it ends style debates.

The big ideas

What you need to know

Fast checks first

Formatting and validation take seconds and need no cloud access. Run them before anything slower.

Policy as code

Write rules like 'no public S3 buckets' once, and let tools enforce them on every change.

terraform test

Terraform has a built-in test command with .tftest.hcl files to check module outputs and behaviour.

The plan is the real test

Most bad changes are visible in the plan. Make reading it a required step, not a formality.

See it in code

Walk through the code

bash

1terraform fmt -check -recursive   # style2terraform validate                # syntax and references3tflint                            # provider-aware lint rules4trivy config .                    # misconfig scan, e.g. public buckets5terraform plan -out=tfplan        # what will really change6terraform show -json tfplan > plan.json  # feed to policy checks

1/3Seconds-fast checks that catch typos and broken references.

terraform validate needs terraform init first, but no cloud credentials. Wire these into CI so they run on every pull request.

Save yourself the pain

Common mistakes

Oops

Testing infrastructure changes for the first time in production.

Do this instead

Apply to a dev or staging environment built from the same modules first, then promote the same code.

Oops

Approving pull requests without opening the plan output.

Do this instead

Look for destroys and replacements every time. They're where the outages hide.

Your mission

Catch a bad bucket

~30 min

Quick check

terraform validate passes, but the code makes a database publicly reachable. Which check is most likely to catch it?

Go deeper

1Run a linter or validator against a Terraform configuration before applying it.
2Learn the concept of policy-as-code (e.g. Open Policy Agent) for enforcing infrastructure rules automatically.
3Practice treating a terraform plan output as a required review step, not something to skip.