During an incident, an engineer changes a network rule in the cloud console and restores service. A routine deployment a week later restores the old rule and the problem returns. Both engineers acted reasonably in their own moment, but the working infrastructure and its recorded definition had diverged.
Infrastructure as Code, or IaC, makes resource definitions versionable and reviewable. To be useful, those definitions must participate in actual changes, including emergency fixes. A configuration folder applied once and forgotten is not an authoritative model of production.
What becomes repeatable
The team describes networks, compute, storage and their relationships instead of relying on manual clicks. Changes can be reviewed, linked to a task and tested elsewhere. Tools differ: some express a desired state, while others describe a sequence of operations.
The first scope need not include everything the company owns. A clearly bounded area with one owner is a workable start. Two automation systems independently managing the same resource are more dangerous: each may try to restore its own definition. Ownership boundaries matter between tools as well as teams.
Repeatability also depends on tool, module and provider versions. Old configuration with newly changed dependencies may produce different proposed actions. Pin and deliberately update those dependencies rather than assuming that a recorded recipe remains valid forever.
A plan describes intent, not guaranteed success
Declarative tools can preview creations, updates, replacements and deletions. Terraform builds a plan from configuration, known resources and information from providers. Its plan reference explains the modes and boundaries.
Review the consequences. Changing a parameter may require replacing a database or disk. Removing something apparently unused may break an external integration. Diff length is a poor measure of risk; reviewers need the purpose, target environment and justification for destructive actions.
A plan does not reserve all future capacity or guarantee that permissions remain valid. Quotas, availability and external state can change. If execution generates another plan, review that plan rather than relying on approval of a different set of actions.
Definitions, resources and state are different
Some tools maintain state describing which real resources correspond to their definitions. In Terraform, this includes bindings between configuration addresses and provider objects. State is neither a replacement for configuration nor a backup of database contents. The state documentation describes its purpose.
Shared work needs controlled storage and protection against conflicting runs. State locking, when supported, helps coordinate updates to that record. It does not stop an administrator changing a resource directly in the console or make all cloud operations transactional.
Plans and state may contain sensitive values. Marking a value sensitive usually hides it in ordinary output; it does not by itself guarantee its exclusion from stored files. Omission capabilities depend on the tool and resource. Access, encryption and handling policies remain necessary, as the sensitive-data guidance explains.
Reconciling an emergency change
Return to the network rule. Was it a temporary workaround or the new correct setting? After recovery, either incorporate the approved change into the managed definition or prepare a safe reversal. Preserving every manual change blindly is as risky as removing every one blindly.
Divergence is called drift. A check can expose it, but the owner must decide what it means. Refreshing recorded state may acknowledge reality without changing the desired configuration. A subsequent normal run may still propose reverting the manual change. The Terraform drift tutorial demonstrates the distinction.
Emergency access needs authorised owners, an action record and a defined reconciliation step. Banning every manual intervention may obstruct recovery. Never reconciling interventions undermines automation. The procedure has to be usable after a difficult incident, not only on a quiet training day.
A failed run can leave successful changes behind
A tool creates networking and storage but cannot obtain permission for the next resource. Failure at the end does not mean a return to the beginning. Terraform, for example, records completed changes and supports continuing after the cause is addressed; its apply tutorial explains recovery.
Inspect actual resources and the next plan before retrying. Reverting a commit changes the desired definition; it does not recover deleted data or undo external effects. Important resources need appropriate deletion protection, backups and a tested recovery path.
Bound the scope of each change. Production should not change alongside every test environment merely because describing them in one run is convenient. Smaller operational boundaries reduce the impact of mistakes, while requiring explicit management of dependencies between them.
A test that exposes unwritten knowledge
Ask another engineer to create an agreed test environment from the definition, using documented access and instructions rather than the author's verbal help. Check application access, network restrictions and removal of temporary resources. Introduce an authorised manual change in the test and confirm that the workflow detects it and offers a clear decision.
Also test state-storage unavailability and interrupted application of changes. Recovery should not depend on credentials held only by an absent colleague. For disaster recovery, include application data, keys and dependencies: creating empty infrastructure is not restoring the business process.
The exercise reveals which tasks have genuinely become repeatable. Extend those working practices to the next environment. Module complexity, file counts and the percentage of resources declared as code are poor substitutes for an ordinary change that no longer requires guessing what somebody once did.