What Terraform Is & Why It Exists

cloud1-11 gave Infrastructure as Code a first look — declarative vs. imperative, Terraform named as the cross-provider option, plan/apply and configuration drift introduced at a conceptual level. This course goes deep specifically on Terraform itself: not IaC in general, but this one tool, in real depth.

The Configuration Drift Problem

A server gets provisioned by hand through a cloud console. Six months later, nobody fully remembers which settings were changed, when, or why — a firewall rule added during an incident, a instance size bumped up "temporarily" during a traffic spike and never reverted. Staging quietly stops matching production. This is configuration drift, and it's the exact problem cloud1-11 named but didn't solve: infrastructure that exists only in a console, with no record of its own history, and no reliable way to reproduce it.

Declarative vs. Imperative Infrastructure

An imperative script says exactly what steps to run, in order: "create a VM, then attach a disk, then open port 443." Run it twice and it may fail the second time (the VM already exists) or duplicate resources. A declarative tool like Terraform instead says what the end state should look like — "there should be one VM, with this disk, with this port open" — and lets Terraform figure out what actions are needed to get there, including doing nothing if reality already matches.

That block doesn't say "run these commands" — it says "this instance should exist, with these properties." Terraform compares that declared intent against what's actually running and works out the difference itself.

Terraform vs. the Cloud-Native Alternatives

Each cloud-native tool is genuinely well-integrated with its own provider — but locked to it. Terraform's core value, especially relevant given cloud1-2's own cross-provider terminology map, is expressing infrastructure across providers (or a multi-cloud environment) using one consistent language and workflow.

Terraform vs. Ansible — Two Different Jobs

Terraform provisions infrastructure — it creates the VM, the network, the database instance. It has no concept of "log in and install a package." Ansible configures infrastructure that already exists — installing software, editing config files, restarting services, on machines Terraform (or something else) has already brought into being. They're complementary, not competing: a real pipeline commonly runs Terraform first to create the servers, then Ansible to configure them.

The Terraform Workflow: Write → Plan → Apply → Destroy

• Write — describe desired infrastructure in .tf configuration files
• Plan — Terraform compares desired state against actual state and shows exactly what it intends to change, before touching anything
• Apply — Terraform executes that plan, creating/updating/deleting only what's needed
• Destroy — Terraform tears down everything it manages, cleanly, in dependency order

The plan step is the single biggest practical difference from clicking through a console: you see the change before it happens, every time.

When Terraform Fits — and When It Doesn't

A one-off resource for quick local testing, or a genuinely single, tiny, rarely-touched environment, often isn't worth the ceremony. Terraform earns its keep once infrastructure needs to be reproducible, reviewed by a team, or exist in more than one environment (dev/staging/prod) — exactly the scenarios where console-driven drift becomes a real, recurring problem.

Hands-On Exercises