What Terraform is & how it works

Declarative, cloud-agnostic provisioning.

Beginner12 min · lesson 1 of 15

Terraform is the industry-standard tool for Infrastructure as Code: you describe the cloud and infrastructure you want — servers, networks, databases, DNS records, Kubernetes clusters — in text files, and Terraform creates and updates the real resources to match. Instead of clicking through a cloud console that nobody can repeat exactly, you write the desired state once, review it like code, and apply it. The infrastructure becomes reproducible, reviewable, and versioned, exactly like software.

What makes Terraform dominant is that it is declarative and cloud-agnostic. Declarative: you state the end result you want, and Terraform figures out the actions needed to get there from wherever things currently are. Cloud-agnostic: the same tool, language, and workflow manage AWS, Azure, Google Cloud, Kubernetes, GitHub, Cloudflare, and hundreds of other platforms through plugins called providers. Learn Terraform once and you can provision almost anything that has an API.

How Terraform works

1write

desired state in HCL

2plan

Terraform diffs code vs reality

3apply

it makes only the needed changes

4repeat

edit code, re-apply

The code is the source of truth; the running infrastructure is derived from it — never the other way around.

Idempotence: run it as often as you like

Because Terraform converges reality toward your declared state, applying the same config repeatedly is safe: if everything already matches, it does nothing; if one resource was deleted out of band, it recreates just that one. This is idempotence, and it is what separates Terraform from a shell script. A script that says “create a server” run twice makes two servers; a Terraform config that says “one server” run twice still means one. You are not issuing commands that might double-execute — you are asserting a desired state the tool reconciles toward.

Provisioning, not configuration

Terraform’s job is provisioning — creating the infrastructure itself. It is not primarily for configuring what runs inside a server (installing packages, editing files); that is configuration management (Ansible and friends), a separate course. Many real setups use both: Terraform builds the machine and the network, then something else configures the software on it. Keeping that boundary clear stops you from trying to make Terraform do a job it is not designed for.

The console is for looking, not for changing

The cardinal rule of adopting Terraform: stop making changes by hand in the cloud console. A manual change creates drift — reality no longer matches your code, so the next apply may revert it or behave unpredictably, and your source of truth becomes a lie. Use the console to observe and debug; make every change through the code. A team half-committed to IaC, still clicking “just this once,” gets the worst of both worlds.

HCL: providers, resources &…