The usual justification for infrastructure as code is automation, and that undersells it. The real value is that the environment you are debugging matches the one you deployed, and that the reason a thing exists is recorded in a file somebody can read. Manual infrastructure fails not because clicking is slow, but because knowledge of what was clicked, and why, leaves with the person who clicked it.
State is the part that surprises teams new to these tools. Declarative systems keep a record mapping the resources they manage to what exists in the provider, and that record becomes the most sensitive artefact you have. Two people applying changes at once, or a state file sitting on a laptop, produces destroyed resources and days of recovery. Remote state with locking is not an advanced practice to adopt later; it is the first thing to set up, before the second engineer arrives.
Drift is the failure mode that quietly undermines the whole approach. Somebody resolves an incident by changing a setting in the console, does not bring it back into code, and now the definition and the reality disagree. The next apply either reverts the emergency fix or fails confusingly. The remedy is procedural rather than technical: emergency console changes are legitimate, and reconciling them the next working day is part of the incident rather than an optional follow-up.
Module abstraction should come later than instinct suggests. The urge to build a reusable internal module before the second or third real use case produces an abstraction shaped by one situation, with parameters accreting until reading the module is harder than reading the resources it wraps. Write the resources plainly, notice the genuine repetition, then extract. An abstraction over infrastructure you have written once is a guess.
Separate environments by state and by blast radius, not by copied directories with slightly different values. Production, staging and development should be the same definitions applied with different inputs, and no single apply should be able to alter more than one of them. Teams get badly burned by a shared state file spanning environments, where a change meant for development reaches production because the plan touched both.
Read the plan. This sounds too obvious to write down, and skipping it is the most common cause of infrastructure incidents among teams who have adopted these tools. The plans to stop and study are those proposing to destroy and recreate something rather than update it in place, particularly for databases, load balancers and anything holding an address other systems depend on. Requiring the plan output on the review, not just the code diff, catches this reliably.
The unfashionable conclusion is that partial adoption is often worse than none. Half the infrastructure in code and half in the console gives you the ceremony of the workflow without the guarantee that the code describes reality, and it produces false confidence during an incident. Either bring an environment fully under management or accept that it is manual and document it as such - the middle state is where the expensive surprises live.
