Why Infrastructure as Code Exists

Infrastructure as Code is the practice of representing infrastructure in files that can be reviewed, versioned, tested, and replicated. Terraform is one implementation of that practice. To use Terraform well, you need to know what it is replacing.

Four ways to provision a server

Pick an imaginary task: stand up a new Linux database server for a production application. There are at least four ways to do it.

Manual provisioning
   ↓
Shell and API scripts
   ↓
Configuration management
   ↓
Infrastructure as Code

Each step down removes a category of failure.

Manual provisioning

A human opens a portal, clicks Create VM, fills in the form, waits, opens the console, runs a few commands, configures the network, installs the database. The result is a server that an experienced colleague could, but probably could not exactly, recreate.

What breaks. Manual work does not scale. It does not survive the absence of the person who did it. It does not produce an audit trail beyond “Ed saw it happen”. A year later, when five servers need to be replaced, the team discovers that nobody knows why the disk layout is the way it is.

Shell and API scripts

The same task, but written down as a bash script that calls the provider API. The script is checked into Git. Runs faster than the manual version. Has the same eventual problem: the script describes the steps, not the state. If the script fails at step 7, the production environment is in an undefined half-state, and rerunning the script from the top is not safe.

What breaks. Scripts do not converge. They do not know what exists; they do what they are told. They do not handle drift. They do not provide a way to ask “what would this change?”. The script does not know what the script did last time.

Configuration management

Tools like Ansible, Puppet, and Chef take the scripts approach and add idempotency. The script describes a desired state; the tool checks what exists and applies only the differences. A package module declares that nginx should be installed; the CM tool inspects the host and installs only if nginx is missing.

The CM tool still assumes the host exists. Where the host comes from is a separate problem, and in many shops the host comes from a manual portal click.

Infrastructure as Code

A descriptive file declares the desired state of infrastructure. A tool reads the file, compares it to the current state, and applies the difference. The tool records the current state, so the next run can detect changes that happened outside the tool.

Configuration file  →  Terraform  →  Real infrastructure
                              ↑
                          State file
                       (Terraforms record of what exists)

This is the level Terraform operates at. The leap forward is that the file describes rather than scripts. The tool decides what to do. The state file makes subsequent operations safe.

Provisioning vs configuration

Two distinct operations, two distinct tools:

                Terraform
                    |
                    v
        Provision infrastructure
                    |
                    v
        Operating systems, packages, files, services
                    |
                    v
                Ansible
                    |
                    v
        Configure and operate systems

A common production mistake is to use Terraform for both. Terraform can install packages (remote-exec), write files (local-exec), and run shell commands. None of those responsibilities are Terraforms core competency. A remote-exec against a freshly-created VM is the canonical “last resort” pattern, and the course teaches it explicitly as such.

Reproducibility and immutability

Two production properties that IaC makes easier:

Reproducibility. With the configuration file and the state file, a new engineer can recreate the production environment in a disposable account on demand. Without either, the environment is dependent on the memory of the team that built it.

Immutability. IaC encourages replacing infrastructure rather than modifying it in place. Rather than ssh into a server and patch it, the IaC workflow is:

Edit the configuration
   ↓
terraform plan
   ↓
Review the plan
   ↓
terraform apply
   ↓
Validate the new infrastructure
   ↓
Tear down the old infrastructure

The essential property is that the replacement is described in a file before it happens. The file is reviewable. The replacement is reproducible. The old infrastructure is destroyed by the same mechanism, not by a manual cleanup.

Where Terraform fits in the IaC ecosystem

Terraform is the most widely adopted IaC tool in August 2026, but it is not the only one. A short map of the landscape:

The course focuses on Terraform because it is the most widely deployed in 2026 and because the lessons about state, drift, and blast radius carry over to every other tool. Most of the operational lessons do not change when you switch to OpenTofu.

What Terraform is not

• A configuration management tool. Use Ansible, Puppet, or Chef for that.
• A deployment tool. Use Spinnaker, Argo CD, or your CI/CD pipeline for that.
• A state engine. Terraform records state, but it is not a replacement for the source of truth in your monitoring, CMDB, or inventory system.
• A policy engine. It can call policy engines (OPA, Sentinel), but it does not enforce policies on its own.
• A workflow engine. It can be invoked from a workflow engine, but it does not orchestrate pipelines.

What comes next

The next lesson is the architecture: what the CLI does, what providers do, what state is, and how the resource graph is constructed. Every later lesson depends on that mental model.

Verification

Verification

Verification

Verification