Infrastructure as code (IaC) defines cloud resources, networks, permissions, and platform services in versioned files instead of manual console changes. Infrastructure changes become reviewable, repeatable, and automatable.
IaC is not only about creating resources. It is about making the desired environment explicit enough that teams can reason about change before it reaches production.
Plan and apply
flowchart LR Code["Infrastructure code"] --> Plan["Plan"] Plan --> Review["Review"] Review --> Apply["Apply"] Apply --> State["State"] State --> Drift["Drift detection"] Drift --> Code
Most IaC tools compare desired configuration with current state, produce a plan, then apply the difference. Reviewing the plan is where teams catch accidental deletes, permission expansion, and environment drift.
Benefits
- Reproducible environments across development, staging, and production.
- Peer review for infrastructure changes.
- Audit history for who changed what and why.
- Drift detection when reality diverges from declared state.
- Faster recovery because environments can be recreated from source.
State and drift
IaC tools need a record of managed resources. Terraform uses state files. CloudFormation uses stacks. Pulumi tracks state through its backend. Losing or corrupting state can make safe changes difficult, so state needs access control, locking, backups, and clear ownership.
Drift happens when someone changes infrastructure outside the IaC workflow. Some drift is urgent, such as an emergency production fix. Unreviewed drift should be folded back into code or reverted.
Modules and boundaries
Reusable modules are useful when they encode real platform decisions, for example a standard service, queue, or database module. They become harmful when they hide every provider feature behind an abstraction nobody can debug.
Keep boundaries aligned with ownership. A product team should not need to apply the whole platform stack to change one service. A platform team should not need every product repository to change a shared network rule.
Secrets and environments
Do not store secrets in IaC source. Store references to secrets and let the runtime fetch values from a secret manager. Separate environments through accounts, projects, workspaces, or explicit naming conventions rather than conditionals that make one file behave like several unrelated systems.
Tooling
Terraform, Pulumi, CloudFormation, Bicep, and CDK all trade off portability, language model, ecosystem, and operational fit. Pick one primary tool per layer and standardize how modules, state, reviews, and applies work.
Trade-offs
IaC adds process around infrastructure change. That process pays off when environments matter, but it can slow teams if every small experiment requires platform ceremony. The goal is not maximum abstraction. The goal is understandable, recoverable infrastructure.