Infrastructure as code: the one test that proves it actually exists

The test is simple: can you destroy a complete environment and rebuild it identically from your repository, with no manual intervention?

Until the answer is yes, you have Terraform files, not infrastructure described as code. The difference is not semantic: it determines what happens on the day you need it.

The three usual reasons it fails

Configuration drift. Someone changed a resource in the console to resolve an incident, without carrying the change back into the code. Six months later nobody knows what differences exist between the code and reality.

The fix is organisational before it is technical: write access to the console is removed in production, and drift detection runs nightly with an alert when a gap appears.

Resources created by hand and never adopted. A bucket created for a one-off need, a firewall rule added in a hurry, a DNS record set by someone who has since left. They exist nowhere in the code and the rebuilt environment does not work without them.

Data and secrets. An empty rebuilt environment is not a working environment. The rebuild procedure must include reloading a dataset and retrieving secrets from a vault — and that part is almost always missing from runbooks.

What the test really reveals

It does not measure the quality of your Terraform. It measures your ability to handle four situations that always eventually occur:

• Rebuilding after a major incident or a compromise.
• Creating a realistic test environment, without improvisation.
• Changing region or provider, for a regulatory or commercial reason.
• Audit: proving production matches what was approved.

How to get there progressively

You do not need to redo everything. The progression that works:

1. Bring the existing estate under managed state, however imperfectly, by importing hand-created resources.
2. Close manual writes in production, with a documented exception procedure for emergencies — and an obligation to carry the change back into code within forty-eight hours.
3. Enable daily drift detection, with a named alert.
4. Test the rebuild on the staging environment, once a quarter, with a stopwatch.

That last step is the only one that really counts. A rebuild never tested is a hypothesis, not a capability.

The number to know

How long does a full rebuild of your most critical environment take? If you do not know that number, you do not know your real recovery time after a major incident, whatever your continuity plan says.