Why Infrastructure as Code Matters

Knowing what Terraform is and knowing why it exists are two different things. This lesson is about the second one — and it changes how you think about infrastructure permanently.

Before IaC Existed

Picture a mid-sized engineering team in 2012. They have a production environment on AWS. One senior engineer — call him Marcus — built it. He knows every setting, every security group rule, every subnet configuration. That knowledge lives entirely in his head.

Marcus goes on holiday for two weeks. A server fails. Nobody else on the team knows how to recreate it correctly. They spend three days guessing their way through the AWS console, getting things mostly right, missing a few settings they cannot see because they were never written down.

Marcus returns and finds a production environment that looks right on the surface but behaves slightly differently from what he built. Nobody knows exactly what changed. The team has what engineers call a snowflake server — a piece of infrastructure so unique and hand-crafted that nobody fully understands it and nobody dares touch it.

The Six Problems IaC Solves

Infrastructure as Code was not invented to be elegant. It was invented because teams kept hitting the same painful problems over and over. Here are the six that matter most:

Infrastructure in Git — Why It Changes Everything

The moment your infrastructure lives in .tf files stored in a Git repository, it inherits everything that makes application code manageable at scale.

Mutable vs Immutable Infrastructure

This is one of the most important mindset shifts IaC introduces. Understanding it now will save you from a category of infrastructure problems that trips up most teams at least once.

Mutable infrastructure means you take an existing server and modify it in place — SSH in, install a package, change a config file, restart a service. The server's history accumulates. Nobody knows exactly what state it is in after months of patches and changes. This is the snowflake problem again.

Immutable infrastructure means you never modify a running server. When something needs to change, you build a new server from updated configuration and replace the old one. The new server's state is completely known — it was built from code, from scratch, with no accumulated history.

Terraform encourages immutable thinking. When you update a resource in your configuration and apply, Terraform often destroys the old resource and creates a new one rather than patching what is already there. This feels uncomfortable at first. Over time you realise it is the only approach that keeps infrastructure predictable at scale.

What This Looks Like in Practice

Here is the same infrastructure task done two ways — the old manual way versus the IaC way. The task: create an S3 bucket in AWS for storing application logs.

New terms:

• aws_s3_bucket — the Terraform resource type for an Amazon S3 storage bucket.
• aws_s3_bucket_versioning — a separate resource that enables versioning on an S3 bucket. In AWS, bucket settings like versioning, encryption, and access control are managed as separate API resources — and Terraform mirrors this exactly.
• bucket argument — the globally unique name for the S3 bucket. No two S3 buckets in the world can share a name.
• versioning_configuration status — either "Enabled" or "Suspended". When enabled, S3 keeps every version of every object — useful for audit trails and accidental deletion recovery.

# main.tf — Create an S3 bucket for application logs

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

resource "aws_s3_bucket" "app_logs" {
  bucket = "acme-app-logs-prod"

  tags = {
    Name        = "Application Logs"
    Environment = "prod"
    ManagedBy   = "Terraform"
  }
}

# Enable versioning so deleted logs can be recovered
resource "aws_s3_bucket_versioning" "app_logs_versioning" {
  bucket = aws_s3_bucket.app_logs.id

  versioning_configuration {
    status = "Enabled"
  }
}

$ terraform apply

Terraform will perform the following actions:

  # aws_s3_bucket.app_logs will be created
  + resource "aws_s3_bucket" "app_logs" {
      + bucket = "acme-app-logs-prod"
      + tags   = {
          + "Environment" = "prod"
          + "ManagedBy"   = "Terraform"
          + "Name"        = "Application Logs"
        }
    }

  # aws_s3_bucket_versioning.app_logs_versioning will be created
  + resource "aws_s3_bucket_versioning" "app_logs_versioning" {
      + bucket = "acme-app-logs-prod"
      + versioning_configuration {
          + status = "Enabled"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

  Enter a value: yes

aws_s3_bucket.app_logs: Creating...
aws_s3_bucket.app_logs: Creation complete after 3s [id=acme-app-logs-prod]
aws_s3_bucket_versioning.app_logs_versioning: Creating...
aws_s3_bucket_versioning.app_logs_versioning: Creation complete after 1s

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Common Mistakes

Practice Questions

Quiz