Infrastructure as Code with Terraform, Start Here

Why clicking in consoles stops working

Your first cloud resources come from clicking. You open the AWS console, click through a wizard, create a server. It works, and clicking feels productive. Then reality arrives: you need an identical staging environment and can't remember the 14 settings you picked. A teammate asks how the network is configured and the only honest answer is "let me click around and check." Something breaks and nobody knows what changed, because clicks leave no record. Clicking doesn't scale, doesn't repeat, and doesn't remember.

The fix is to describe your infrastructure in text files, commit them to Git, and let a tool build exactly what the files say. That's Infrastructure as Code (IaC), and Terraform is the most widely used tool for it. This article gets you from zero to understanding the whole core loop, and writing real Terraform you can run.

What Infrastructure as Code actually is

Infrastructure as Code means writing down what your infrastructure should look like in files you can version, review, and reuse, then having a tool make reality match the files.

The mental shift is from *doing* to *describing*. You don't perform the steps to create a server. You write down "I want one server, this size, in this network," and Terraform figures out the steps. If the server doesn't exist, it creates it. If it already matches, it does nothing. The analogy that makes it click:

Because the recipe is a text file, it goes in Git. Now your infrastructure has history, code review, and a single source of truth. "What changed?" becomes git log. "Make me another environment" becomes copying a folder.

Console clicks vs Terraform

The four words that are all of Terraform

Terraform looks big, but the day-to-day vocabulary is tiny. Learn these four and you can read almost any Terraform file.

1. 1

   Provider

   The plugin that knows how to talk to a specific cloud, aws, azurerm, google. You declare which provider(s) you're using and where.

2. 2

   Resource

   One thing you want to exist, a server, a network, a database. The bulk of your code is resource blocks.

3. 3

   Variable

   An input you can change without editing the logic, region, instance size, environment name. This is what makes one set of files reusable across environments.

4. 4

   Output

   A value Terraform prints after it builds, the server's IP, the database endpoint, so you (or other tooling) can use it.

Your first real Terraform

Let's write something that runs. Start by declaring the provider, which cloud, and which region. The region comes from a variable so the same files work anywhere.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region   # value comes from variables.tf
}

Now declare inputs as variables. Giving them defaults makes them optional; leaving a default off makes Terraform ask (or require) a value.

variable "region" {
  description = "AWS region to deploy into"
  type        = string
  default     = "eu-west-1"
}

variable "environment" {
  description = "Environment name, e.g. dev or prod"
  type        = string
  default     = "dev"
}

Then the actual resource. This is a real, free-tier-friendly S3 bucket, a good first resource because it's simple and hard to break. Notice how it reads the variable to tag itself.

resource "aws_s3_bucket" "app_data" {
  bucket = "thesimplifiedtech-${var.environment}-app-data"

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"   # so humans know not to click-edit it
  }
}

Finally, an output so Terraform tells you what it made instead of making you go look.

output "bucket_name" {
  description = "Name of the created bucket"
  value       = aws_s3_bucket.app_data.bucket
}

The plan / apply loop

Terraform has exactly one workflow you'll run thousands of times. init once to download the provider, then the loop: plan to preview, apply to make it real.

# Once per project: download providers, set up the working dir
terraform init

# The safety net: shows EXACTLY what will be created/changed/destroyed.
# Changes nothing. Read this every single time.
terraform plan

# Make reality match the files. Asks you to type 'yes' first.
terraform apply

# When you're done with everything: tear it all down cleanly
terraform destroy

terraform plan is the feature that makes Terraform safe to learn on. It's a dry run, it reads your files, checks what currently exists, and prints the diff: + for create, ~ for change, - for destroy. Nothing happens until you run apply and type yes.

State: how Terraform remembers

Here's the concept beginners trip over. How does Terraform know your bucket already exists so it doesn't make a second one? It keeps a state file, a record of every resource it created and its real-world ID. On the next plan, it compares three things: your files (desired), the state (last known), and the real cloud (actual).

This is also idempotency in action: run apply ten times with no file changes and Terraform does nothing nine of those times, because state already matches your files. "Make it so" is safe to repeat, that's the whole promise of IaC.

Common mistakes that cost hours

1. Running apply without reading the plan. The plan literally tells you what's about to be destroyed. Skipping it is how people accidentally delete production databases.
2. Editing resources in the console after Terraform made them. Now reality and state disagree. Next apply may revert your click, or get confused. If it's in Terraform, change it in Terraform.
3. Committing the state file or .tfvars secrets to Git. State can contain secrets; tfvars often hold passwords. .gitignore both before your first commit.
4. No remote state on a team. Two people apply at once with local state and corrupt it. Use a remote backend with locking the moment more than one person touches the code.
5. Hardcoding values that should be variables. Region, sizes, and names hardcoded means you can't reuse the files for a second environment. If it changes between environments, make it a variable.
6. Not pinning provider versions. Without a version constraint, a provider upgrade can change behaviour under you. Pin with ~> and upgrade deliberately.

Where to go next

Reading Terraform is easy; the fluency comes from running the loop yourself until plan and apply feel automatic. Go build something real:

• Run the full init/plan/apply loop in the browser: the Terraform Lab, then the broader Infrastructure as Code Lab.
• Go deeper with the interactive lesson: Infrastructure as Code.
• Apply Terraform to a real network, build a VPC from scratch in Cloud Networking Fundamentals: VPC.
• See where IaC fits the bigger picture: the Cloud Engineer path.

Create that S3 bucket with Terraform today, change the environment variable, and apply it again to make a second one. The moment you watch one variable spin up a whole new environment, you'll never want to click a console again.