Infrastructure as Code
Infrastructure as Code treats infrastructure definitions as versioned, reviewable source. Instead of clicking resources into existence, teams describe networks, compute, identity, storage, and managed services in code. The result is not only automation; it is a change history and a repeatable model of the system.
State and Drift
Declarative IaC tools compare desired configuration with observed infrastructure and plan changes. State is the memory that connects source definitions to real resources. If state is lost, corrupted, or edited casually, the tool may destroy or duplicate infrastructure. Remote state, locking, access control, and backups are therefore production concerns.
Drift occurs when reality changes outside the IaC workflow. Some drift is emergency repair; some is configuration decay. Mature teams detect drift and reconcile it through code so the repository remains trustworthy.
Modules
Modules are infrastructure APIs. A good module exposes decisions that product teams should make and hides decisions that the platform owns. Overly generic modules recreate the cloud provider in another syntax. Overly narrow modules force copy-paste.
Planning as Review
The plan step is the central review artifact in IaC. It translates source edits into proposed infrastructure actions: create, update, replace, destroy, or no-op. Reviewers should read plans with a production mindset. A harmless-looking variable change may replace a database, recreate a load balancer, or widen a firewall rule.
Plans should be generated from the same code and credentials model that will apply the change. If engineers paste local plans into comments, the organization has weak evidence. A better pipeline posts a machine-generated plan, records the tool version, locks state during apply, and preserves the apply log.
State Ownership
State boundaries are architecture boundaries. Putting every resource in one giant state file makes small changes risky and slow. Splitting state too aggressively creates dependency confusion. A practical boundary often follows ownership and blast radius: networking, shared platform, each application environment, and data services may have separate state.
Remote state outputs should be treated as APIs. If one stack exports a subnet identifier that another consumes, changes to that output can break downstream systems. Versioning and documentation matter even when the interface is “just infrastructure.”
Drift and Emergency Change
Manual emergency repair is sometimes necessary. The DevOps discipline is to capture it afterward. If an operator changes a scaling limit during an incident, the next step after mitigation is to reconcile the IaC definition and document why. Otherwise the next apply may undo the repair without context.
Study Task
Take one planned infrastructure change and write the failure analysis before applying it: what could be replaced, what could be destroyed, which users would be affected, how state is backed up, and what rollback actually means. Infrastructure rollback is often a new forward change, not a simple undo button.
Operational Review
IaC should be reviewed for drift, blast radius, and readability. A reviewer should be able to understand which resources are affected, why the change is needed, and how failure would be contained. If a plan is too large to review, the change is too large or the state boundary is wrong.
The review should include module ownership. Shared modules can improve consistency, but a module bug can affect many services. Version pinning, changelogs, tests, and migration notes are therefore part of infrastructure safety.
Finally, confirm that emergency operations are reconciled. The repository must return to being the source of truth after incidents, provider console changes, or manual repairs.
Desired State
resource "example_server" "api" { replicas = }