101: The Problem With Clicking

Why IaC? The Case Against Clicking in the Console

The Problem With Clicking

You spin up a VM. You click through the console, pick the right region, set the firewall rules, attach the disk. It works. You close the browser tab feeling productive.

Six months later: “Can you set up another one exactly like that?”

You have no idea what you clicked. The colleague who set up the original one left the company. The console UI has been redesigned twice since then. You click around for 2 hours and end up with something almost identical. Almost. The difference between “almost identical” and “identical” is what causes production outages at 3 AM.

That’s the core problem. Infrastructure built by hand is invisible, unrepeatable, and fragile. There’s no record of decisions. No way to reproduce them. No way to review them. And when things break — and they will break — nobody can explain how the system got into its current state because the knowledge walked out the door with the person who clicked the buttons.

What IaC Actually Is

Infrastructure as Code means you describe your infrastructure in text files — code — that a tool can read and execute. Instead of clicking, you write:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

That file is the source of truth. You store it in Git. You review it in pull requests. You can repeat it. Destroy it and bring it back. Every single time, exactly the same result. The infrastructure definition is the documentation — no separate runbook needed, no wiki page that’s six months out of date.

This matters more than most people realize when they first encounter it. IaC isn’t just about convenience. It fundamentally changes the relationship between teams and their infrastructure. Instead of tribal knowledge trapped in people’s heads (“ask Dave, he set up the database”), the knowledge lives in code that anyone can read, review, and modify.

Declarative vs. Imperative — Two Philosophies

This is a fundamental concept in infrastructure automation, and understanding why they’re different matters more than memorizing definitions.

Imperative means you write step-by-step instructions: “Create a VPC. Then create a subnet. Then attach an internet gateway.” You’re telling the tool how to get there. Bash scripts and Ansible playbooks work this way. The problem? If the VPC already exists, the script either errors out or creates a duplicate. You have to handle every edge case yourself.

Declarative means you describe the desired end state: “I want a VPC with this CIDR, a subnet in this AZ, and an internet gateway.” The tool figures out the steps. If the VPC already exists and matches, it does nothing. If the subnet is missing, it creates only the subnet. You never think about ordering or conditionals.

Terraform is declarative. This is its most important property. You describe the world you want, and Terraform reconciles reality with your description.

Why does this matter practically? Because in production, you’re never starting from scratch. You’re always modifying existing infrastructure. A declarative tool handles the “what already exists” problem for you. An imperative script requires you to write that logic yourself — and getting it wrong means duplicate resources, orphaned infrastructure, or worse.

Idempotency: The Property That Makes Automation Safe

If your infrastructure already matches what you declared, Terraform does nothing. Run terraform apply on an unchanged config: No changes. Infrastructure is up-to-date.

This is idempotency — running the same operation multiple times produces the same result. It sounds academic until you need it, and then it’s the most important property your automation can have.

Consider this scenario: your CI/CD pipeline runs terraform apply and crashes halfway through — maybe the network drops, maybe the runner runs out of memory. You fix the issue and run it again. With an idempotent tool, the second run picks up where the first left off. Resources that were already created are left alone. Resources that weren’t get created. No duplicates, no partial states, no manual cleanup.

Bash scripts are not idempotent. Run mkdir foo twice — the second run errors. Run apt install nginx on a system that already has nginx — it works, but now you’re depending on apt’s internal idempotency, not yours. With Terraform, idempotency is guaranteed by design.

This is also what makes emergency re-runs safe. Production is broken, you push a fix, your pipeline runs. If it fails partway through, you don’t have to figure out what got applied and what didn’t. You just run it again.

Day 0, Day 1, Day 2 — The IaC Lifecycle

The industry talks about infrastructure in three phases, and IaC plays a role in all of them:

Most people think of IaC as a Day 1 tool — “I used Terraform to build my infrastructure.” But its real value shows up on Day 2. When you need to scale from 2 instances to 10, you change a number in a file and apply. When you need to add a new subnet for a new service, you write three lines of HCL and apply. The change is reviewed, tested, and applied through the same pipeline as every other change.

Without IaC, Day 2 operations involve someone logging into a console, making manual changes, and hoping they documented what they did. They didn’t. They never do.

The Real Benefits — Why Experienced Teams Refuse to Work Without IaC

• Version Control — Every infrastructure change lives in Git. You get full history, blame annotations, and the ability to roll back. “Who changed the security group last Tuesday?” becomes a git log query, not an investigation.

• Collaboration — Pull requests for infrastructure changes. Code review before anything touches production. Junior engineers can propose changes; senior engineers review them. Nobody makes unilateral infrastructure decisions anymore.

• Consistency — Dev, staging, and prod built from the same code with different parameters. No more “works in my environment” because all environments are structurally identical. When a bug doesn’t reproduce in staging, you know it’s a data issue, not an infrastructure discrepancy.

• Speed — Provision a full environment in minutes. Tear it down when you’re done testing. Spin up a fresh one for the next sprint. Stop paying for idle infrastructure that exists only because nobody remembers what it’s for.

• Self-Documentation — The code is the documentation. When someone new joins the team, they read the Terraform configs to understand the infrastructure. No stale wiki pages. No outdated architecture diagrams. The code is always current because it’s what’s actually deployed.

• Auditability — Every change has a Git commit with an author, timestamp, and description. In regulated industries, this is table stakes. Even outside regulated environments, it’s invaluable when doing post-incident analysis.

Design Scenario: The Three-Environment Problem

Context: A startup needs dev, staging, and prod environments. Each needs a VPC, some VMs, and a database.

Without IaC:
– Three people build three environments manually over a few weeks.
– After 6 months, they’re all different. Prod has a firewall rule nobody remembers creating. Staging is missing a parameter that prod has. Dev has an extra subnet that was “temporary” three months ago.
– A bug in staging doesn’t reproduce in prod because the environments have diverged. The team spends two days comparing configurations by hand before finding the discrepancy.

With IaC:
– One Terraform config. Three terraform apply runs with different variable files.
– Dev, staging, and prod are structurally identical — same VPC layout, same security groups, same database config, just scaled differently.
– A bug in staging either reproduces in prod (you catch it early), or it doesn’t (because it’s a data issue, not infrastructure). Either way, you save two days of investigation.

That’s the promise of IaC. Infrastructure that behaves like software — versioned, tested, reviewed, and reproducible.

Key Takeaways

When someone asks “what’s the advantage of IaC over manual provisioning,” the answer isn’t just “automation.” It’s the entire package: consistency, repeatability, version control, auditability, and collaboration. Any one of these alone justifies the investment. Together, they fundamentally change how teams operate.

Idempotency isn’t just a nice property — it’s what makes IaC safe in CI/CD pipelines, emergency scenarios, and multi-team environments. If your automation isn’t idempotent, you can’t safely re-run it, which means every failure requires manual investigation and intervention.

The declarative vs. imperative distinction matters because it determines who handles complexity — you or the tool. With declarative IaC, the tool handles ordering, dependency resolution, and the “what already exists” problem. With imperative automation, that burden falls on you. In production environments with hundreds of resources, that burden becomes unsustainable.