Infrastructure as Code: Terraform, State and Drift

Infrastructure as code (IaC) manages servers, networks, databases, permissions and other cloud resources through version-controlled definition files instead of manual clicks. A tool such as Terraform (or OpenTofu, Pulumi, CloudFormation) compares the code with what exists, shows a plan of changes, and applies them. The result is infrastructure that's reviewable, repeatable across environments, and recoverable.

Declarative vs imperative

Declarative tools are idempotent by design, which is what makes repeated applies, drift correction and new environments safe.

Plan, apply and state

• State maps each resource in code to the real object it manages (its cloud ID and attributes). Without it, the tool can't tell what it created.
• Remote state with locking: store state in shared, versioned storage and lock it during applies so two people can't change the same infrastructure concurrently and corrupt it.
• State is sensitive: it can contain secrets and resource details, so encrypt it and restrict access.
• Apply only reviewed plans: CI should apply the exact plan that was reviewed, not recompute a different one later.

Modules and structure

• Modules package a reusable pattern (a service's database with backups, alarms and access policies) with a small set of inputs, so teams don't copy hundreds of lines.
• Version modules and upgrade consumers deliberately, like library dependencies.
• Split state by blast radius: one giant state file means every plan touches everything and one mistake can affect production broadly. Separate by environment, region and component (network, data, services).
• Same code, different variables per environment, so staging is a faithful rehearsal of production.

Drift

Drift is when reality no longer matches the code, usually because someone changed a resource by hand during an incident. The next apply might silently revert the fix or fail. Detect drift by running scheduled plans and alerting on unexpected differences; resolve it by updating the code to match (if the change was right) or re-applying (if it wasn't). Reduce it by limiting write access in the console to break-glass roles.

Guardrails

• Policy as code: automated checks on plans, for example no public buckets, encryption required, approved instance types, tags for cost ownership.
• Destructive change protection: flag plans that delete or replace stateful resources such as databases, and require extra approval.
• Least-privilege CI credentials: the pipeline that applies changes uses short-lived credentials scoped to what it manages. See secrets management.
• Import before managing: bring existing resources under IaC by importing them into state, not by recreating them.

IaC is how you get disaster recovery for infrastructure: if a region or account is lost, the same code can rebuild it, as long as it's been exercised recently.