Infrastructure as code is not primarily about automation — scripts automated things perfectly well. It is about making infrastructure reviewable, reproducible and auditable, which are properties of version control rather than of automation. Once you hold that, the design decisions make sense.

The practical division most estates land on: declarative tooling provisions the resources, and a configuration or orchestration tool handles what happens inside and across them. The two are complementary and the argument about which is ‘better’ usually means the arguers have different problems.

One thing worth understanding about the imperative side: idempotency is a property you have to design for. A configuration tool's modules are written so that ‘ensure this package is installed’ is safe to run a hundred times, and the moment you drop to running a raw shell command you have left that guarantee behind. A playbook full of shell commands is a script with extra syntax.

The state file is the design decision that everything else follows from. It maps the resources in your configuration to the real objects that exist, by their provider-assigned identifiers. Without it the tool has no way to know that web_server in your code is that particular instance in the account — and it is not derivable, because names are not unique and tags can be edited.

This is the practice that separates teams who trust their infrastructure automation from teams who are frightened of it. Review the plan, not only the code.

Code expresses intent. The plan expresses what will actually happen to production, and the two differ more often than anyone expects — because of drift, because a module version moved, because a data source resolved differently, or because a provider changed a default. A pipeline that posts the plan onto the pull request, so a human reads the diff before approving, catches a whole class of accidents.

And the single most important thing to look for in a plan is destroy and replace. Many resource changes are updates in place; some force replacement, and for a database or a stateful volume that means deleting the real thing. The word to search for is ‘forces replacement’, and a plan containing it against anything stateful should stop the pipeline and require a second reviewer.

One state file for the entire estate means one lock, one plan, one apply — and one mistake that can take down everything. Splitting reduces blast radius and introduces coordination cost.

• Split by blast radius and by change cadence. Networking changes rarely and is catastrophic to break; application infrastructure changes daily and is cheap to fix. They do not belong in the same apply.
• Reference across boundaries by data lookup, not by sharing state. Have the downstream configuration query for the network it needs rather than reaching into another state file, so the coupling is a read rather than a shared mutable object.
• The counterweight is real: too many small states and a single logical change requires six coordinated applies in the correct order, which is its own kind of fragility and which people underestimate. The split is a judgement about your organisation, not a rule.
• Environments should be the same code with different inputs, so that ‘it works in staging’ means something. A separate copy of the code per environment guarantees they will diverge, and the divergence will be discovered during a production incident.

Modules are how infrastructure code is reused, and the failure mode is over-abstraction. A module with forty input variables, half of which exist to handle one team's exception, is harder to understand than the resources it wraps and impossible to change safely.

The test worth applying: can someone read the module and predict what it creates? If it takes longer to understand the module than to write the resources directly, the abstraction is costing more than it saves. Small, composable modules that do one thing beat one module that does everything conditionally — and pinning module and provider versions explicitly is what stops a rebuild eighteen months later producing a different estate.

The last step is enforcing rules on the plan before it applies: no public storage buckets, encryption required, mandatory tags, no unrestricted security-group rules, cost thresholds requiring approval.

This is the mechanism that converts infrastructure standards from documentation into something that cannot be violated — and it is a much better answer to ‘how do you enforce cloud standards’ than a review checklist, because the check runs on every change without a human being available. The related pattern is drift detection running on a schedule and raising a ticket rather than silently correcting, so a human decides whether the console change was an emergency fix worth keeping.