DEVOPS-01-005-P · Primer — Infrastructure as Code (IaC)

The idea in one sentence

Infrastructure as Code means you define your servers, networks, and cloud resources in version-controlled text files, and a tool builds them — instead of clicking through a console by hand.

Why it exists

For years, infrastructure was built by hand: someone logged into the AWS console, clicked "launch instance," set a few dropdowns, and a server appeared. That server became a snowflake — unique, undocumented, and impossible to reproduce exactly. When it died, or when you needed a second one for staging, nobody could rebuild it the same way, because the only record of how it was made lived in one engineer's memory. IaC exists to kill the snowflake: the console clicks become a file, the file goes in git, and the truth about your infrastructure is now something you can read, diff, and rebuild on demand. Think of it like a recipe book versus cooking by instinct: a recipe lets anyone recreate the same dish step‑by‑step, while cooking by instinct produces a one‑off meal that no one else can duplicate.

How it works

You write a declarative description of the desired end state — "I want one load balancer, three web servers of this size, in this network" — in a file like Terraform's HCL. The tool reads that file, compares it against what actually exists in the cloud, computes the difference, and makes only the changes needed to close the gap. The two-step ritual is plan then apply: terraform plan shows you the diff ("+ 3 instances, ~ 1 security group") as a dry run, and terraform apply executes it against the provider's API. Because you declared an end state rather than a script of steps, running it twice is safe — this is idempotence: applying an already‑satisfied config changes nothing.

Worked example:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}
resource "aws_subnet" "web" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
}
resource "aws_instance" "web" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.web.id
}
resource "aws_lb" "app" {
  name               = "app-lb"
  internal           = false
  load_balancer_type = "application"
  subnets            = [aws_subnet.web.id]
}

Running terraform plan on this 20‑line file reports:

Plan: 1 to add, 0 to change, 0 to destroy
  + aws_vpc.main
  + aws_subnet.web
  + aws_instance.web[0]
  + aws_instance.web[1]
  + aws_instance.web[2]
  + aws_lb.app

When you execute terraform apply, the provider creates a VPC, a subnet, three t3.micro EC2 instances, and an application load balancer—all in under five minutes. Deleting the file and running terraform destroy tears down every resource in the same deterministic order.

See it — commit to git, plan the diff, apply to the cloud

flowchart LR
  A["Write desired<br/>state in code"] --> B["Commit +<br/>open a PR"]
  B --> C["Peer review<br/>+ merge"]
  C --> D["terraform plan<br/>(show the diff)"]
  D --> E["terraform apply<br/>(call cloud API)"]
  E --> F["Real infra<br/>matches code"]
  F -.->|"drift detected"| D

The one gotcha

Your infra is a reviewed repo, not a hand‑clicked snowflake nobody can reproduce — and the moment someone bypasses that repo, the whole promise breaks. The classic failure is configuration drift: an engineer hot‑fixes a production box in the console at 2 a.m. to stop an outage, and now reality no longer matches the code. The next terraform apply will happily revert that emergency fix, or worse, the two states silently diverge until a rebuild produces something subtly different. The real gotcha is assuming the repo is the source of truth without enforcing a strict policy that every change, even emergency ones, must be captured back into the code and reviewed before the next apply. Otherwise the snowflake sneaks back in and the safety net collapses.

The one-line takeaway

Infra you can't rebuild from a repo is a liability, not an asset.

Where you'll meet it

You will meet IaC the first time you touch OpenTofu, Ansible, Terraform, Pulumi, or AWS CloudFormation — and again every time a platform team asks you to open a pull request instead of a console tab. It underpins GitOps (where a controller like Argo CD or Flux reconciles a Kubernetes cluster to a git repo), it is one of the continuous‑delivery capabilities DORA links to elite performance, and it is why your staging and production environments can finally be twins instead of distant cousins.

Named concepts: infrastructure as code, declarative configuration, idempotence, configuration drift, plan and apply