Infrastructure as Code — Environments in Git

What you'll learn

• IaC from the DevOps angle: whole environments as code
• Terraform vs configuration tools (Ansible)
• Idempotency — the property that makes IaC safe
• How IaC completes the automation story

The last piece of the automation puzzle 🧩

DevOps automates code (CI/CD) and packages it (Docker). But what about the servers, networks, and databases the code runs on? Setting those up by clicking is slow, inconsistent, and undocumented. Infrastructure as Code (IaC) automates that final piece: your entire environment defined in text files, versioned in Git, built by a tool.

(You saw IaC in the cloud track — here's the DevOps framing and one crucial new concept.)

Two flavors of "as code" tools, often used together:

• Provisioning (Terraform) — creates the infrastructure itself: "make 3 servers, a database, and a network." Declarative — you describe the end state.
• Configuration management (Ansible, Chef, Puppet) — sets up what's inside each server: "install nginx, copy these config files, start the service."

Together: Terraform builds the houses, Ansible furnishes them.

The crucial concept: idempotency. This is what makes IaC trustworthy. An operation is idempotent if running it once or ten times gives the same result. "Ensure exactly 3 servers exist" is idempotent — run it repeatedly and you always end with 3, never 6 or 30. Compare a non-idempotent "add a server" script: run it three times and you accidentally have three extra servers. Good IaC declares the desired end state (idempotent), not a list of actions (dangerous to re-run). It's the same declarative safety as Kubernetes' desired state.

Why this completes DevOps: now everything — the app code, its container, its tests, its deployment pipeline, AND the infrastructure it runs on — lives in Git, reviewed and reproducible. You can destroy your entire production environment and rebuild it identically from text files in minutes. A new team member can read the repo and understand the whole system. That is the DevOps dream: the entire path from a developer's idea to running production is automated, versioned, and repeatable.

Plan before apply, and configuration drift 📐

Real IaC tools never just blindly change your infrastructure — they follow a plan → apply workflow, which is the safety mechanism that makes declarative infrastructure trustworthy in production:

terraform plan   # "Here's exactly what I WOULD change: +2 servers, ~1 modified, -0"
terraform apply  # only after a human (or a pipeline gate) reviews and approves the plan

plan compares your code's desired state against the real, current state of your infrastructure, and prints a preview — additions, changes, deletions — without touching anything. Only apply actually executes it. This two-step dance means nobody is ever surprised by what a deploy is about to do; the plan output is often attached to a Pull Request for teammates to review, exactly like reviewing code.

Configuration drift is the problem this whole workflow guards against: it happens when someone changes real infrastructure outside of the IaC tool — clicking around in a cloud console to "quickly fix" something. Now your Terraform files (the declared desired state) and reality have diverged. The next terraform plan will notice the mismatch and may try to "correct" the manual change back to what the code says — which is exactly why the rule in serious DevOps teams is: all infrastructure changes go through the IaC code, no exceptions, no console-clicking. Reality must always match the versioned, reviewed text file — never the other way around.

Real-world case study: the console-click that broke the build 🔍

A pattern familiar to almost every team that adopts IaC: everything is humming along, infrastructure defined neatly in Terraform, until an engineer under time pressure needs a "quick fix" in production — a firewall rule, a bumped disk size — and just clicks it directly in the cloud provider's web console to save time. It works, the incident is resolved, everyone moves on.

Weeks later, someone runs terraform plan for an unrelated change, and it proposes reverting that manual fix back to the old, broken configuration — because as far as the code is concerned, that manual click never happened. If nobody notices the plan output carefully, apply silently undoes the fix and reintroduces the very problem it solved. This exact "drift" scenario is one of the most common IaC incidents reported across the industry, and it's precisely why the discipline in this lesson — all changes go through code, plan output is always reviewed, never click fixes directly into production — exists. The tool did exactly what it was told; the failure was a process failure, not a technology one.

Summary

• IaC automates infrastructure setup: whole environments as versioned code
• Terraform provisions; Ansible/Chef/Puppet configure inside servers
• Idempotency (declare desired state) makes IaC safe to re-run
• The plan → apply workflow previews changes safely; configuration drift is why all changes must go through code, never manual console clicks
• You built a plan-diff calculator that spots what needs adding vs removing
• Now the entire system lives in Git — the DevOps dream

Next: Monitoring & Observability — knowing what your automated systems are actually doing in production.