Terraform, Explained the Way Engineers Actually Use It in Production

A practical breakdown of how Terraform works, with real commands, real structure, and no theory fluff.

Cloud infrastructure drifts. Someone clicks a button. Someone hotfixes at 2 a.m. A “temporary” rule becomes permanent. Three months later, nobody knows why a security group exists, but everyone is afraid to delete it.

This is how systems become fragile. Terraform exists to stop that.

What Terraform Actually Does

Terraform lets you define infrastructure as code, then ensures reality matches that definition.

It’s declarative. You don’t tell Terraform how to build infrastructure. You tell it what the final state should be. Terraform then:

• Reads your configuration
• Compares it with real infrastructure
• Builds a plan (a diff)
• Applies only what’s necessary

Think of Git— but for infrastructure.

What You Need to Get Started

Before you write a single line of Terraform, you need three things:

1. A Cloud Account: AWS, Azure, or GCP
2. Credentials

For AWS:

aws configure

Or via SSO (common in enterprise setups).

For Azure :

az login

Terraform uses these credentials via providers.

3. Terraform Installed

provider "aws" {
  region = "eu-west-1"
}

resource "aws_s3_bucket" "data" {
  bucket = "my-secure-data-bucket"
}

That’s it. Readable. Version-controlled. Reproducible.

Understanding State (This Is Where It Gets Real)

Terraform keeps a state file, a mapping between your code and real infrastructure. Without state, Terraform is blind. Best practice is to store it remotely:

terraform {
  backend "s3" {
    bucket = "terraform-state"
    key    = "prod/infra.tfstate"
    region = "eu-west-1"
  }
}

No shared state → no safety → eventual chaos.

Commands You’ll Use Daily

terraform init     # Initialise project
terraform plan     # Preview changes
terraform apply    # Apply changes

And the ones engineers actually rely on:

terraform fmt      # Clean formatting
terraform validate # Syntax + structure checks

Run fmt and validate before every commit. It saves you from embarrassing pipeline failures (writing from experience, obviously)

Why terraform plan Matters

plan shows:

• What will be created
• What will change
• What will be destroyed

If you don’t read your Terraform plan, you’re not doing Infrastructure as Code; you're gambling.

Variables (Stop Hardcoding)

variable "env" {
  default = "dev"
}

Use it:

bucket = "app-${var.env}"

Same code. Different environments. No duplication. Remember to create your .env file (project root directory – or whichever directory you choose; project root directory my favourite place)

Outputs (Expose What Matters)

output "bucket_name" {
  value = aws_s3_bucket.data.bucket
}

Outputs make your infrastructure composable and usable in pipelines.

Drift Detection

Someone changes infrastructure manually in the console. Terraform notices.

terraform plan

You’ll see the difference immediately. Not friction. Just accountability.

Terraform looks simple until reality shows up.

Your organisation blocks resources with SCPs Terraform fails, but the console “magically works” State gets out of sync after manual fixes You inherit infrastructure you didn’t build

This is where Terraform stops being a tool and becomes discipline.

Sometimes you:

• import existing resources
• debug permissions, not code
• fix drift before you can even deploy

Terraform doesn’t remove complexity. It forces you to face it early.

What Terraform Is Not

• A deployment tool
• A configuration management tool
• A secret manager

Use it to provision infrastructure, not to manage applications.

Final Thoughts

Terraform doesn’t make infrastructure simple. It makes it visible.

Every resource is declared. Every change is reviewable. Every shortcut shows up.

And in production systems, clarity beats cleverness every time.