Infrastructure as Code — A First Look

Every chapter so far has covered individual services. This chapter steps back to look at how those resources actually get created and managed in practice, at real scale — deliberately a first look, not a deep dive: this site's own bucket list has a separate, dedicated Terraform course planned for genuine hands-on depth.

The Problem With Manual (Console-Driven) Provisioning

Clicking through a web console to create resources is genuinely fine for learning and experimentation — Chapter 2's own free-tier advice assumed exactly this. It doesn't scale to real production use, though: there's no record of exactly what was created or why, it's hard to reproduce identically (dev, staging, and production environments quietly drift apart over time — configuration drift), there's no history or audit trail of changes, it's error-prone for repetitive tasks, and it simply doesn't scale to hundreds or thousands of resources.

What Infrastructure as Code Actually Means

Rather than a sequence of manual click-steps, infrastructure is described in config files defining the desired state — the config file itself becomes the single source of truth for what should exist. Because it's just text, it can be version-controlled exactly like application code — this site's own git1-git3 courses apply directly, and git2-7's code review process now applies equally to infrastructure changes, not just application code.

Declarative vs. Imperative

Most IaC tools are declarative — you describe the desired end state ("I want 3 web servers and 1 load balancer"), and the tool figures out what changes are needed to get there. This contrasts with an imperative approach — a sequence of manual steps ("create server 1, create server 2, create server 3...") that doesn't inherently know how to safely reconcile drift or a partial failure the way a declarative tool's plan/apply cycle does. Terraform, CloudFormation, and ARM/Bicep are all declarative.

The Big Three's Native Tools

Terraform — The Cross-Provider Option

HashiCorp's Terraform works across all three major providers (and many others) using one consistent language (HCL) and workflow, rather than three separate provider-specific tools — directly echoing this course's own cross-provider framing since Chapters 1 and 2. This is exactly why Terraform is such a common real-world choice for organizations working across multiple clouds.

The Plan/Apply Workflow

The standard declarative IaC cycle:

To compute that difference between current and desired state, the tool needs to track what it currently believes exists — a state file, in Terraform's case.

Why This Matters for Support Work

Even without writing IaC configs day to day, knowing that infrastructure might be managed this way genuinely changes the right troubleshooting approach: a manual emergency fix applied through the console can get silently overwritten — or conflict outright — the next time the IaC tool runs. The right emergency practice is usually to make the fix and update the IaC config to match it, not just the console alone.

Hands-On Exercises