Lesson: What Infrastructure as Code Means

What you'll learn

The difference between configuring servers by hand and defining them in code.
What "declarative" and "imperative" mean, and why declarative tools dominate IaC.
Why idempotency and state matter, with plain-language definitions.
The three jobs IaC tools do: provisioning, configuration management, and bootstrap.
How keeping infrastructure in Git ties back to version control (Module 4).

Skill gained: you can explain what Infrastructure as Code is, why teams use it, and which kind of tool does which job — the vocabulary you need for the rest of this module.

The lesson

1. The problem: "works on my server"

Imagine you set up a web server by hand. You SSH in, install packages, edit config files, open firewall ports, and reboot. It works. Six months later it crashes, and nobody remembers the exact steps. You rebuild it from memory and miss one setting. Now it behaves differently from before. This is configuration drift — the slow, invisible divergence of a system from what you think it is.

Infrastructure as Code (IaC) solves this by writing down what the infrastructure should be in plain text files that you store, review, and version like any other source code. Instead of remembering steps, you run a tool that reads the file and makes reality match it. Rebuilding becomes "run the tool again," not "try to remember."

   Manual way (clicks & SSH)          IaC way (files + a tool)
   --------------------------         --------------------------
   human -> server (by hand)          human -> code file
            |                                    |
            v                                    v
       undocumented              tool reads file -> makes server match
       state, drift                     |
                                        v
                              same result every time

2. Codified infra vs manual infra

"Codified" just means written as code/text. The benefits flow from that one idea:

Repeatable: the same file produces the same result on machine 1, 2, and 100.
Reviewable: a teammate can read your change before it touches production (a pull request — see Module 4).
Auditable: Git history shows who changed what, when, and why.
Recoverable: lost a server? Re-run the code.

The lab you work in already does this. Every lab VM is created from one golden template and then configured on first boot by a small cloud-init snippet — a text file unique to that VM. That snippet is Infrastructure as Code you can read and copy. We'll dig into cloud-init in Chapter 4.

3. Declarative vs imperative

Two styles of telling a computer what to do:

Imperative = you list the steps. "Install nginx. Then create this folder. Then start the service." Like a recipe. A shell script is imperative.
Declarative = you describe the desired end state. "There should be an nginx server, running, with this config." The tool figures out the steps needed to get there.

Imperative:  step 1 -> step 2 -> step 3   (you own the "how")
Declarative: "I want THIS end state"       (tool owns the "how")

Most modern IaC tools are declarative (Terraform, much of Ansible, Pulumi, cloud-init). Declarative is powerful because the tool can compare what is to what you declared and change only the difference. You don't have to write "if it already exists, skip it" everywhere — the tool handles that.

4. Idempotency

Idempotent means: running the operation once or many times gives the same result. Press an elevator button five times — the elevator still comes once. Good IaC is idempotent: run it again on an already-correct server and nothing changes. Run it on a half-built server and it fixes only what's missing.

This is what makes IaC safe to re-run. A non-idempotent script that does useradd bob fails the second time ("user exists"). A declarative tool that says "user bob should exist" simply sees bob is already there and moves on.

5. State: how the tool knows reality

To make reality match your file, a tool must know what reality currently is. Tools handle this differently:

Terraform keeps a state file — a record of every resource it created and its real-world ID. On the next run it reads state, checks the real world, and plans the difference. (More in Chapter 2.)
Ansible is usually stateless: each run it logs into the machine and checks the actual current condition of each item live, then fixes what's off.
cloud-init runs once, at first boot, so it tracks only "have I run on this instance already?"

Understanding "where does the tool keep its memory?" is one of the biggest differences between tools.

6. The three jobs (and one extra)

IaC is not one tool — it's a category. Map each tool to the job it's best at:

  PROVISIONING        CONFIG MANAGEMENT      BOOTSTRAP
  (create the box)    (set up what's inside) (first-boot setup)
  e.g. Terraform      e.g. Ansible           e.g. cloud-init
        |                    |                     |
        v                    v                     v
  "make a VM/network"  "install & configure"  "run once on launch"

  GENERAL-PURPOSE: Pulumi (provisioning, but in a real language)

Provisioning = creating the raw infrastructure: virtual machines, networks, disks, load balancers, DNS records. Terraform is the classic choice.
Configuration management = setting up the software inside a machine that already exists: packages, files, services, users. Ansible is the classic choice.
Bootstrap = the very first setup a fresh machine needs at boot. cloud-init is the standard on Linux cloud images. This is what your lab uses.
General-purpose / code-native = Pulumi does provisioning like Terraform, but you write it in Python, TypeScript, or Go instead of a special config language.

These combine. A common real-world pipeline: Terraform creates the VM, hands it a cloud-init snippet for first-boot basics, then Ansible logs in to do detailed configuration. Chapter 5 covers how to choose and combine them.

7. Why this connects to version control

Because IaC is just text files, you put them in Git (Module 4). That means infrastructure changes get the same workflow as code changes: branches, pull requests, review, and history. "Infrastructure changed unexpectedly" turns into "show me the commit." This single habit — infra lives in Git — is the cultural core of IaC.

Dig deeper

Search terms

infrastructure as code explained for beginners
declarative vs imperative infrastructure
what is idempotency in devops
terraform vs ansible vs cloud-init
configuration drift explained

Check yourself

In your own words, what does "Infrastructure as Code" mean and what problem does it solve?
Give one example each of an imperative and a declarative instruction.
What does "idempotent" mean, and why does it make IaC safe to re-run?
Name the three core IaC jobs and one tool commonly used for each.
How does the lab let you see real IaC in your own environment today?