Infrastructure as Code

Overview

Infrastructure as code replaces manual provisioning with files that describe networks, clusters, databases and permissions. The same definitions create development, staging and production, which removes a large class of it-works-here bugs.

How it works

The workflow has three stages: write, plan, apply. The plan compares code against recorded state and the real provider, then lists creates, updates and destroys. A human or policy engine reviews it.

code --> plan --> review/policy --> apply --> state backend
  ^                                   |
  +------ drift check (scheduled) ----+

A minimal resource looks like this:

resource "aws_s3_bucket" "logs" {
  bucket = "acme-logs-prod"
}

State must live in a remote backend with locking so two applies cannot run concurrently.

Pitfalls

• Local state files that get lost or diverge between engineers.
• Giant monolithic stacks where one change plans thousands of resources. Split by lifecycle and blast radius.
• Renaming resources without a move declaration, which destroys and recreates data stores.
• Leaving console access open, so drift accumulates. Run scheduled plans to detect it.
• Secrets stored in state in plain text. Treat the backend as sensitive.
• No lifecycle protection on databases and buckets.

Key takeaways

• Plan before apply, and review the plan, not just the code.
• Remote locked state is mandatory for teams.
• Split stacks by blast radius and change frequency.
• Detect drift on a schedule.
• Protect stateful resources against accidental destruction.