Why manual infrastructure stops working

You could set up your infrastructure by clicking around a cloud console — create a server here, a database there, a load balancer, some networking. It works, once. Then you need to do it again for staging, or recreate it after a disaster, or explain why production differs from staging, or hand it to a teammate — and clicking falls apart. Infrastructure as Code (IaC) describes your infrastructure in files, so it is version-controlled, reviewable, repeatable and automatable, like any other code. This module teaches it with Terraform. This first lesson is why manual infrastructure stops working.

The problem with clicking

Setting up infrastructure by hand in a web console — "ClickOps" — has problems that compound as you grow:

• It is not repeatable. Setting up staging to match production means clicking through the same dozens of screens again, from memory, and getting something slightly different. The environments drift, and "it works in staging but not production" becomes a mystery rooted in a setting nobody remembers changing.
• It is not recorded. There is no history of what was set up or why. Six months later, nobody knows why that security group allows that port, or whether it is safe to remove.
• It is not reviewable. A change to production infrastructure — opening a port, resizing a database — happens with a click, with no review, no second pair of eyes, no record. A single wrong click can cause an outage or a security hole.
• It does not scale. Managing three servers by hand is tedious; managing three hundred, across environments, is impossible.
• It is a disaster-recovery nightmare. If an environment is lost, recreating it from memory and console clicks is slow and error-prone — exactly when you can least afford it.

Manual infrastructure works for a demo and fails for a real system. The same reasons you version-control code — history, review, repeatability — apply to infrastructure, and IaC is how you get them.

What Infrastructure as Code is

Infrastructure as Code means describing your infrastructure — servers, networks, databases, load balancers, DNS, Kubernetes clusters — in declarative configuration files, and using a tool to create and manage the real infrastructure to match. You write, in a file, "I want a server of this size, in this network, with this security group", commit it to Git, and the tool makes it so.

The gains are exactly the gains of treating infrastructure like code:

• Version-controlled — the files live in Git, so you have a full history: what changed, when, by whom, and (via commit messages and PRs) why. You can git blame a firewall rule.
• Reviewable — an infrastructure change is a pull request, reviewed like any code change before it is applied (the Git module). No more unreviewed clicks on production.
• Repeatable — the same files create the same infrastructure every time, so staging and production are identical by construction, and you can spin up a new environment from the files.
• Automatable — because it is files and a command, it fits into CI/CD (the previous module): infrastructure changes can go through a pipeline like application changes.
• Documented — the files are the documentation of what your infrastructure is. There is no "what's actually deployed?" gap, because the code is the source of truth.

Declarative: describe the what, not the steps

The key idea — and the one that connects to Kubernetes (the previous modules) — is that IaC is declarative. You describe the desired state ("a server of this size, this database, this network"), not the steps to create it. The tool figures out what to create, change, or destroy to make reality match your description.

This is exactly the Kubernetes mental model, applied to all infrastructure: you declare what you want, and a tool reconciles reality toward it. Change the file to say "3 servers" instead of "2", and the tool adds one; remove a resource from the file, and the tool destroys it. You manage the description; the tool manages the doing. If you understood desired state in Kubernetes, you already understand the heart of IaC.

The main tools

A few tools dominate, and it helps to know the landscape:

• Terraform (by HashiCorp) — the most widely used, cloud-agnostic tool. It works across AWS, Google Cloud, Azure and hundreds of other providers with one language (HCL). This course teaches Terraform because it is the standard and its concepts transfer everywhere. (OpenTofu is an open-source fork with the same language.)
• CloudFormation — AWS's own IaC service, AWS-only.
• Pulumi — IaC using real programming languages (TypeScript, Python) instead of a dedicated config language.
• Ansible — more focused on configuring servers (installing software, setting up files) than provisioning them, though there is overlap.

The concepts — declarative desired state, providers, resources, plan-then-apply, state — are common across all of them, so learning Terraform teaches you IaC generally. The rest of this module builds a real (small, runnable) Terraform configuration and takes you through the workflow you will use on the job.

Check your work

Why clicking fails: not repeatable (environments drift — "works in staging not prod"), not recorded (no what/why), not reviewable (unreviewed clicks on prod), doesn't scale (hundreds of resources), and a disaster-recovery nightmare (recreate from memory). Works for a demo, fails for a real system.

IaC = describe infrastructure in declarative config files and use a tool to make reality match. Gains (same as version-controlling code): version-controlled (history, git blame a rule), reviewable (infra change = a PR), repeatable (identical environments by construction), automatable (fits CI/CD), documented (the files are the source of truth).

Declarative: describe the desired state, not the steps; the tool reconciles reality toward it — exactly the Kubernetes model applied to all infrastructure. Manage the description; the tool does the doing.

Tools: Terraform (most used, cloud-agnostic, HCL — what this course teaches; OpenTofu is its fork), CloudFormation (AWS-only), Pulumi (real languages), Ansible (server config). Concepts transfer across all.

Practice

1. List four problems with setting up infrastructure by clicking in a console, and how IaC fixes each.
2. Explain how IaC brings the benefits of version control (history, review, repeatability) to infrastructure.
3. Explain "declarative desired state" for infrastructure and connect it to the Kubernetes model.
4. Give a scenario (disaster recovery, a new environment) where IaC clearly beats manual setup, and why.
5. Compare Terraform, CloudFormation and Pulumi, and say why this course teaches Terraform.
6. Explain why "the code is the source of truth" removes the "what's actually deployed?" problem.

Official documentation

• HashiCorp — What is Infrastructure as Code? — IaC and what Terraform does.
• AWS — What is Infrastructure as Code? — The concept and its benefits.
• HashiCorp — Terraform use cases — Where IaC is applied.

Next: Terraform — providers, resources and state.