DEVOPS-05-001-P · Primer — What Is Infrastructure as Code?

The idea in one sentence

Infrastructure as Code (IaC) means you describe your servers, networks, and databases in text files that live in version control, then let a tool build exactly what you wrote — instead of clicking buttons in a cloud console by hand.

Why it exists

Picture the "old way." You need a web server, so you log into the AWS or Azure console and start clicking: pick a machine size, attach some storage, open a firewall port, wire up a load balancer. It works. Three months later you need an identical server for staging, and you try to remember every click. You miss one firewall rule. Now staging behaves differently from production, and you spend a day hunting the difference.

That hand-driven approach is called click-ops (or manual provisioning). It has three chronic problems:

• It's not reproducible. The knowledge lives in someone's memory or a stale wiki page, not in a file a machine can replay. Two people clicking the "same" setup produce two slightly different environments — a phenomenon called configuration drift.
• It's not reviewable. No teammate can read a diff of "what changed and why" before it ships. A risky firewall change looks the same as a harmless one: invisible.
• It's not recoverable. If the environment is deleted or a region goes down, you rebuild from memory, slowly, under pressure.

IaC exists to convert that fragile, human process into a durable artifact. When the desired state of your infrastructure is written down as code, it becomes something you can version, review, test, and replay — the same disciplines software engineers already use for application code.

How it works

The core move is simple: you write a file that declares the end state you want, and a tool figures out how to make reality match it.

1. You write a configuration file. In a declarative tool, you describe what should exist — "one virtual machine of this size, with this disk, in this network" — not the step-by-step clicks to create it. HashiCorp's Terraform, AWS CloudFormation (JSON/YAML templates), and Azure's tooling all work this way. The tool's job is to compute the steps needed to reach your declared state.

2. You commit that file to version control (Git). This is what makes infrastructure version-controlled. Every change is a commit with an author, a timestamp, and a message. Every change can go through a pull request so a teammate reviews it before it touches anything real. You can see the full history and revert a bad change.

3. The tool reconciles desired state with actual state. You run the tool (e.g., terraform apply). It compares what you declared against what currently exists and makes only the changes needed to close the gap. Run it once, you get the environment. Run the same file a second time and nothing happens — the world already matches. This property is called idempotency: applying the same configuration repeatedly converges on the same result instead of stacking up duplicate resources.

Because the file is the source of truth, reproducibility falls out for free. Point the tool at a new account or region, run the same code, and you get a byte-for-byte equivalent environment. Staging and production stop drifting apart because they're built from the same declared blueprint.

The one gotcha

IaC does not magically know about changes you make by hand. If someone opens the console and clicks to add a firewall rule that isn't in the code, you now have drift: the real world and the code disagree. The next time the tool runs, it may "helpfully" delete that out-of-band change to restore the state your file declares — because your file, not the console, is the source of truth.

The rule that keeps you safe: once infrastructure is codified, change it only through the code. No more sneaking into the console for "just one quick tweak." If you must inspect drift, most tools offer a plan/preview step (like terraform plan) that shows you the difference before anything is applied. Treat that preview like a code review diff — read it every time.

See it — click-ops vs codified provisioning

flowchart TB
  subgraph Manual["Click-ops (manual)"]
    H["Human clicks in<br/>cloud console"] --> R1["Environment exists<br/>(steps not recorded)"]
    R1 --> D["Drift + guesswork<br/>on the next rebuild"]
  end
  subgraph Codified["Codified provisioning (IaC)"]
    F["Config file<br/>declares end state"] --> G["Commit to Git<br/>(reviewed in a PR)"]
    G --> T["Tool applies<br/>(idempotent)"]
    T --> R2["Reproducible<br/>environment"]
  end

The one-line takeaway

Infrastructure as Code turns "remember how you clicked it" into "read the file and replay it" — reproducible, reviewable, version-controlled provisioning.

Where you'll meet it

• Your first Terraform or CloudFormation file, where you declare a resource and watch the tool create it — then run it again and see nothing change (idempotency in action).
• Pull requests on infrastructure changes, where a firewall or scaling tweak gets reviewed as a diff before it reaches production.
• Disaster recovery and new environments, where you rebuild an entire stack in a fresh region by re-running the same code instead of clicking for hours.
• A drift alert, where the tool's plan step warns you that reality no longer matches the code because someone edited by hand.

Named concepts: infrastructure as code, reproducibility, version-controlled infrastructure, manual provisioning vs codified provisioning