Teams adopt infrastructure as code for the wrong reason. They want a script that creates a server. What they actually get — if they do it properly — is a permanent, reviewable record of every change to their production estate.
The provisioning is the easy part. The review is where the value lives, and it's the part most teams quietly skip by letting one person with the credentials apply changes from a laptop.
A plan nobody reads is a script with extra ceremony
Terraform, Pulumi, CloudFormation — the tool barely matters. What matters is that every change is proposed as a diff, reviewed before it runs, and applied by a system rather than a human with too much access.
The failure mode is familiar. CI runs terraform apply automatically on merge. Nobody reads the plan, because the plan is 400 lines of noise. Then someone bumps an AMI and the plan quietly destroys and recreates a database because a field changed that forces replacement. The diff was right there. Nobody looked.
Make the plan legible
If a plan is too large to read, it's too large to merge. Break the change up. Put the destructive actions at the top. Fail the pipeline on any plan that deletes or replaces a stateful resource unless it carries an explicit override label, reviewed by a second person.
Review the plan, not the syntax
Two reviewers looking at HCL formatting are adding nothing. The useful review question is: what does this do to the running system? That means the plan output is the artefact under review, posted on the pull request, not a log line buried in a job.
Five things that break in real IaC repos
- State is a single point of failure. One remote state file shared by everything, no locking, and a corrupted write takes out the whole estate. Split state by lifecycle, and enable locking before you need it.
- Manual changes. Someone fixes an outage in the console at 2am and never back-ports it. Drift accumulates until the next apply silently reverts the fix — and the outage returns.
- Secrets in the repo. Variables file with an access key committed once and never rotated. It's in the history forever, even after you delete the line.
- No environment parity. Staging is hand-built and production is code. The first deploy proves they were never the same thing.
- Everyone has apply rights. No separation between proposing a change and approving it. The review is theatre when the same person can merge and apply.
The workflow that actually holds up
A change starts on a branch. CI runs a speculative plan against the real state and posts it as a comment. A human reads it, not the code. Merge triggers an apply that is gated — either an approval step or a policy check that blocks destructive actions on protected resources.
Drift detection runs on a schedule, and any divergence from code is itself an incident with an owner. That's the part teams neglect: without drift detection, your code describes an intention, not reality, and the gap only surfaces during the next emergency.
Prove it from scratch
Once a quarter, stand up an environment from the repository alone, with no manual steps and no tribal knowledge, and time it. That single exercise finds undocumented dependencies, hard-coded values, and the credentials someone pasted into a console six months ago. A repo that can't rebuild its own environment isn't infrastructure as code — it's documentation that happens to run.
Infrastructure as code isn't valuable because it automates a server. It's valuable because it makes every change to production something a human can read, question, and reject.
How we approach it at Weeltec
We restructure infrastructure repositories so that state is split, locking is enforced, secrets live in a managed store, and applying is something the pipeline does and nobody does by hand. Almost always the first deliverable isn't new code — it's making the existing plan small enough that a reviewer can actually catch the change that matters.
Permissions get the same treatment. Engineers propose through pull requests; the apply role is held by the CI system, scoped per environment, and auditable.
The rule
If your infrastructure changes don't pass through a diff that someone reads before it touches production, you don't have infrastructure as code. You have infrastructure as a habit, and habits don't survive a bad Tuesday.
Weeltec builds and reviews infrastructure-as-code setups for teams that want every production change to be a decision, not an accident. If your applies go straight to production unreviewed, get a quote and we'll put the review back where it belongs.