Infrastructure as Code
Infrastructure as code defines servers, networks, and cloud resources in versioned files, so environments are reproducible, reviewable, and provisioned by automation.
Definition
Infrastructure as code is the practice of declaring infrastructure such as networks, compute, and managed services in machine-readable configuration files, then applying those files through an automated tool that converges real resources to the declared state.
Context and scope
Teams adopt it when manual console changes cause drift, when environments must be recreated reliably, and when infrastructure changes need review and audit like application code.
Common misconceptions
- IaC means the cloud is fully declarative — many tools still execute imperative steps, and some resources require scripts.
- Applying code guarantees the declared state — drift, manual changes, and partial failures still need detection and reconciliation.
- IaC removes the need to understand infrastructure — it makes mistakes reproducible at scale, not harmless.
Anti-patterns
- Clicking in the console for urgent fixes and never importing the result back into code
- Storing plaintext secrets in the repository instead of a secret manager
- One giant state file shared by every team and environment
Related concepts
Authoritative source
Declare, plan, apply
Infrastructure as code turns environment definitions into files stored in version control. A typical workflow has three steps: describe the desired resources, generate a plan that diffs desired against actual state, and apply the plan. The tool records what it created in a state file so later runs know which real resources correspond to which declarations. Code review then covers infrastructure changes just as it covers application changes.
resource "aws_s3_bucket" "logs" {
bucket = "acme-logs-prod"
tags = { Environment = "prod", ManagedBy = "terraform" }
}When to use it
Use IaC whenever an environment must exist more than once, be rebuilt after failure, or be audited. It pays off for cloud networks, managed databases, IAM policies, and CI runners. For a single throwaway virtual machine, the setup cost may exceed the benefit. Compared with console changes, IaC is slower for the first change and far faster for the hundredth.
Trade-offs
State becomes critical: it must be stored remotely, locked during applies, and protected because it can contain sensitive values. Providers drift from the cloud API, so upgrades need testing. Teams must resist out-of-band changes, or the next plan will propose destructive surprises.
Example and misconceptions
A startup defines staging and production from one module with different variables. Rebuilding staging after an incident becomes one command plus a review. The frequent misconception is that IaC is automatically idempotent and safe; a plan that replaces a database is still destructive if nobody reads it. Related concepts: immutable infrastructure, GitOps, and CI/CD.