Interactive lesson

Why Terraform? What it really does in production

Lesson player Chapter 1

Why Terraform?

What it really does in production.

From clicks, to code, to the real thing.

Words you'll meet

InfrastructureThe networks, servers, databases and permissions your apps run on.
ConsoleThe cloud's website, where you can click to build things.
APIThe doorway programs use to ask the cloud to do things.
Infrastructure as codeDescribing infrastructure in files, so a tool can build it.

Building by hand

Cloud consoleeu-west-2 (London)
VPCEC2RDSS3IAM
Console home

Signed in to the production account. Nothing has been built yet.

Your VPCs
NameVPC IDStateIPv4 CIDR
shop-vpcvpc-0f3c9a1b2d4e5f607Available10.0.0.0/16
Instances (2)
NameInstance IDStateTypeZoneStatus checks
web-1i-0a1b2c3d4e5f60718Runningt3.smalleu-west-2achecks passed
web-2i-09f8e7d6c5b4a3921Runningt3.smalleu-west-2bchecks passed
Databases
DB identifierStatusEngineClass
shop-dbAvailablePostgreSQLdb.t3.micro

Illustration: the fields match what AWS shows; the layout is simplified. Not a real screenshot.

It works. So what's the problem?

What goes wrong with clicking

Clicking works once. The problems show up over months.

1
No record of whyWho opened that firewall port, and why?
2
Hard to repeat exactlyStaging built by hand never quite matches production.
3
No whole-picture previewOne change at a time, with no view of the knock-on effects.
4
Rebuild from memoryAfter a disaster, someone must remember every setting.

Describe it in a file

main.tf trimmed example the record · kept in Git
resource "aws_vpc" "shop" {
  cidr_block = "10.0.0.0/16"
}
resource "aws_instance" "web" {
  count         = 2
  instance_type = "t3.small"
}
resource "aws_db_instance" "shop" {
  engine         = "postgres"
  instance_class = "db.t3.micro"
}

Plan: see it before it happens

 terminal (trimmed illustration)
!p $ terraform plan
!m Terraform will perform the following actions:
!g   # aws_vpc.shop will be created
!g   # aws_instance.web[0] will be created
!g   # aws_instance.web[1] will be created
!g   # aws_db_instance.shop will be created
!p Plan: 4 to add, 0 to change, 0 to destroy.
Nothing has changed in AWS yet
In a team, reviewers read this plan before anything is approved.

Apply: what really happens

Terraform
terraform apply
Provider
the AWS plugin
AWS API
creates real things
Network needs nothing else
2 servers need the network
Database needs the network
can run in parallel
Cloud consoleeu-west-2 (London)
VPCEC2RDSS3IAM
Console

Waiting for apply…

Instances (2)
NameInstance IDStateTypeZoneStatus checks
web-1i-0a1b2c3d4e5f60718Runningt3.smalleu-west-2achecks passed
web-2i-09f8e7d6c5b4a3921Runningt3.smalleu-west-2bchecks passed
VPC shop-vpc: AvailableDB shop-db: Available

Illustration: the fields match what AWS shows; the layout is simplified. Not a real screenshot.

Plus what clicking never left you: a reviewed file, a plan you read, and a state file.

Why teams rely on it

✓
Review and previewA colleague checks the plan before it happens.
✓
RepeatOne design builds dev, staging and production; inputs set the differences.
✓
RecordGit shows who changed what and when; pull requests record why.
✓
RebuildRecreate the infrastructure from code. The data needs backups.

When Terraform isn't the answer

!
Learning curve, and state to protectEpisode 2 shows why state matters.
!
It deletes as fast as it buildsSee the real failures page.
✓
Sandbox tests and emergenciesSandbox: clicking is fine. Emergency fix: record it, then code it.
≈
Other toolsCloudFormation (AWS) · Bicep (Azure) · Pulumi · OpenTofu

Servers come and go. Data stays.

Load balancer
↓ requests
Server Aapp
Server A ✕ failed
Server Bapp
Server Cnew, same image
↓ reads and writes
Auto Scaling: keeps 2 servers → starts C
Databasecustomer orders
File storageuploaded files

The customer data is untouched.

High availability isn't backup

A server or zone fails
Primary ✕synchronous copy →Standby
Failover: the standby becomes the primary
Someone deletes a table at 14:05
Primarycopies the deletion →Standby
Both copies lose it
Backups + logsrestore to 14:04 →New database→Check it→Switch the app

High availability keeps you running. Backups let you go back.

One common production split

Terraform builds network · servers · database service · storage · permissions
Image toole.g. Packer: builds the image, before
Server cloud-init: first boot e.g. Ansible or Systems Manager: ongoing setup the app, released by CI/CD
CI/CDreleases the app
Your customers' datathe app writes it to the database and storage; backups protect it

Recap

  1. Clicking works once, but leaves no record, no whole-picture preview, and no easy rebuild.
  2. Terraform: describe it in a file, plan, then apply through the cloud's API.
  3. The result is the same real infrastructure, plus a reviewed record.
  4. Terraform builds the infrastructure. Other tools handle images, setup, releases and data.
write→plan→apply

Press play for narration, animated diagrams and quick checks.

0:00 / 0:00

Lesson map

Chapters

    How our diagrams speak: Teal: focus or current concept Green: desired or successful Brick red: risk or conflict Slate blue: a relationship or link
    Build it for real: your first resourceoptional · about 5 min

    Your first real Terraform run: write a file, plan, apply, look at state, change something, and clean up. terraform_data, which is built in, stands in for a real resource, so you need no cloud account and it costs nothing.

    You need: Terraform 1.4 or newer (install guide) or OpenTofu (install guide), and a terminal.

    1. Make a folder with one file, main.tf

    resource "terraform_data" "hello" {
      input = "my first resource"
    }
    
    output "message" {
      value = terraform_data.hello.output
    }

    2. Set up, then preview

    terraform init
    terraform plan

    This is the real plan output from our test run, in full:

      # terraform_data.hello will be created
      + resource "terraform_data" "hello" {
          + id     = (known after apply)
          + input  = "my first resource"
          + output = (known after apply)
        }
    
    Plan: 1 to add, 0 to change, 0 to destroy.

    Notice (known after apply): the ID doesn't exist until the resource is really created.

    3. Make it real, and see what state remembers

    terraform apply
    terraform state list

    Type yes. You'll see message = "my first resource", and state lists terraform_data.hello.

    4. Change your mind

    Edit the input to "my changed resource", then:

    terraform plan

    # terraform_data.hello will be updated in-place and Plan: 0 to add, 1 to change, 0 to destroy. Terraform works out the difference between your file and what exists.

    5. Clean up

    terraform destroy

    Type yes: Destroy complete! Resources: 1 destroyed.

    Outputs above are real, captured with OpenTofu 1.12.6 on 3 October 2026, where the header line says "OpenTofu will perform the following actions" instead of "Terraform will…". Not run with the Terraform program itself, whose download is blocked in our test environment.

    How to use this lesson

    Glossary. Tap any dotted-underlined term for a plain-English explanation. Playback pauses while you read.

    Keyboard. Space or K plays/pauses, left and right arrows change chapter, and 1–4 answer a quick check.

    Narration. The lesson currently uses your device's speech engine. The content is already segmented so recorded or cloned voice clips can replace it later without redesigning the lesson.