Terraform Basics

Overview

Terraform lets you describe infrastructure, servers, networks, DNS records, databases, as declarative configuration files instead of manual console clicks or imperative scripts. You write what you want to exist; Terraform figures out what needs to be created, changed, or destroyed to get there, by comparing your configuration against a state file that records what it created last time. Because that configuration is just text, it gets the same benefits as application code: version control, code review, and repeatable, auditable changes. The trade-off is a genuinely new failure mode application developers don't usually deal with, state drift, where the real infrastructure and Terraform's record of it disagree.

Quick Reference

The commands below are grouped by workflow stage, not an exhaustive reference (see the official Terraform CLI docs for every flag), but the set that covers nearly all day-to-day Terraform work.

Syntax

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket = "my-tfstate"
    key    = "prod/network.tfstate"
    region = "us-east-1"
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

Examples

# Standard workflow - review before anything changes
terraform init      # downloads providers, configures the backend
terraform plan       # shows the diff; nothing is changed yet
terraform apply

# Variables make configuration reusable across environments
variable "instance_type" {
  type    = string
  default = "t3.micro"
}

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = var.instance_type
}

Visual Diagram

Common Mistakes

• Committing terraform.tfstate to Git; it often contains plaintext secrets and immediately causes merge conflicts between teammates.
• Running terraform apply directly without reviewing terraform plan's output first, especially in CI where a bad diff can destroy production resources unattended.
• Manually editing or deleting a cloud resource that Terraform manages, then being surprised when the next plan shows it wants to "recreate" something that already exists, Terraform only knows what's in its state.
• Hardcoding values (regions, AMI ids, account numbers) instead of using variables, making the same configuration impossible to reuse across environments.

Performance

• terraform plan and apply runtime scales with the number of resources and how many depend on each other, Terraform parallelizes independent resources automatically, but long dependency chains serialize.
• Remote state with locking adds a small network round-trip per operation but is non-negotiable for team safety; the alternative (local state) doesn't scale past one person.
• Large monolithic configurations (hundreds of resources in one state file) make every plan slower and every apply riskier, splitting state by environment or service (state isolation) keeps blast radius and plan time down.

Best Practices

• Always use a remote backend with state locking (S3+DynamoDB, Terraform Cloud, etc.) the moment more than one person touches the infrastructure.
• Require a reviewed terraform plan output (e.g., posted as a CI comment) before any apply runs, especially against production.
• Split state per environment (dev/staging/prod) so a mistake in one can't touch another.
• Use variables and modules instead of duplicating near-identical resource blocks across environments.