Infrastructure automation fails in predictable ways. The code works in a demo subscription. Then it meets naming standards, change windows, missing credentials, and a production network nobody documented. The project is declared “nearly done” for a year.
The first failure is scope. “Automate the datacentre” is not a project. Automating a repeatable pattern (a spoke landing, a Windows image pipeline, a Kubernetes node pool, a firewall rule workflow) is. Until the pattern is boring, do not multiply it.
On one platform project, a Terraform module for spoke networks worked in the demo subscription. In production the first apply failed: the service principal couldn't peer with the hub, the naming policy rejected the resource group name, and the state file sat on an engineer's laptop. None of those were Terraform problems. They were ownership, permissions and change-process questions nobody had answered before the code was written.
The second failure is ownership. Modules without an owner rot. Pipelines without a service principal strategy get personal accounts. State without locking and backup becomes folklore. If operations cannot run a plan/apply with confidence, they will keep clicking in portals and the code will lie.
The third failure is pretending configuration management and provisioning are the same job. Terraform can create the VNet. It should not be the only tool you have for a weekly IIS binding change. Pick the control plane that matches the change frequency.
Successful programs start with a thin vertical slice in production, not a platform rewrite. They include drift detection, secrets, and a rule for when humans are allowed to click. They also include the routine work: documentation, code review, and deleting modules nobody uses. It is engineering discipline, and it matters more than the tooling.
Want your infrastructure built and changed as code? Platform engineering and IaC
All resources