Infrastructure as code with Terraform

In this tutorial you will learn Terraform by doing. First you will create a file on your own laptop with Terraform (no cloud account, no cost) to learn the workflow. Then you will create a real S3 bucket on AWS for the Brew & Bean website, using variables and outputs, and finally destroy it.

Prerequisites: a terminal, Terraform installed (the official install page covers Windows, macOS and Linux; check with terraform version), and for the second half an AWS account with the AWS CLI configured for a non-root IAM user or SSO profile. See *AWS core services* for that set-up.

If you create servers and buckets by clicking in a console, nobody can answer: what exactly did we build, how do we build it again, and who changed it? Infrastructure as code (IaC) means you describe your infrastructure in text files, keep them in Git, review changes in pull requests and let a tool apply them.

Think of a recipe card versus a cook who "just knows" the dish. The card lets a second cook make the same dish in another kitchen.

Terraform is the most widely used IaC tool. It works across clouds (AWS, Azure, Google Cloud, Kubernetes, GitHub and many more) through plugins called providers. Its language is called HCL (HashiCorp Configuration Language). The licence of Terraform changed in 2023 and a community fork called OpenTofu exists with almost the same commands; everything here applies to both, just replace terraform with tofu.

Terraform is declarative: you write the end state you want ("one bucket with versioning on") and Terraform works out the steps. Run it twice and the second run does nothing, because reality already matches your files.

The workflow is always the same four commands: init (download providers), plan (preview), apply (do it) and destroy (remove it).

Create an empty folder tf-hello and a file main.tf. The local provider can create files on your own machine, which is a safe way to see the whole workflow.

terraform {
  required_version = ">= 1.5"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}

resource "local_file" "welcome" {
  filename = "${path.module}/welcome.txt"
  content  = "Welcome to Brew & Bean. Open 8 am to 10 pm.\n"
}

The terraform block pins the Terraform and provider versions. resource "local_file" "welcome" means: a resource of type local_file, which I will call welcome inside this configuration.

After apply, look in the folder: there is a terraform.tfstate file. This is Terraform's memory. It maps each resource in your code to the real object it created. Without it, Terraform would not know that the bucket already exists and would try to create it again.

Three rules about state:

1. Never edit it by hand and never delete it while real resources exist. 2. It can contain secrets (passwords, keys) in plain text. Never commit it to Git. Add .terraform/ and *.tfstate* to .gitignore. Commit .terraform.lock.hcl. 3. In a team, use remote state (for example an S3 bucket with locking, Terraform Cloud or another backend) so everyone shares one state and two people cannot apply at the same time.

Now a real resource. Create a folder tf-bucket with three files. Splitting a configuration into main.tf, variables.tf and outputs.tf is a convention, not a rule: Terraform reads every .tf file in the folder together.

variable "bucket_name" {
  type        = string
  description = "Globally unique S3 bucket name, lowercase letters, numbers and hyphens"
}

variable "region" {
  type    = string
  default = "ap-south-1"
}

A variable without a default has no value yet, so Terraform will ask for it (or you can pass -var). ap-south-1 is the Mumbai region.

terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = var.region
}

resource "aws_s3_bucket" "site" {
  bucket = var.bucket_name

  tags = {
    Project = "brew-and-bean"
    Managed = "terraform"
  }
}

resource "aws_s3_bucket_versioning" "site" {
  bucket = aws_s3_bucket.site.id

  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_public_access_block" "site" {
  bucket                  = aws_s3_bucket.site.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

aws_s3_bucket.site.id is a reference to another resource. Terraform sees it and creates the bucket first, then the versioning and access-block settings. You never write the order yourself. If terraform init rejects ~> 6.0, check the provider's page on the Terraform Registry for the current major version.

output "bucket_name" {
  value = aws_s3_bucket.site.id
}

output "bucket_arn" {
  value = aws_s3_bucket.site.arn
}

Outputs are printed after apply and can be read later with terraform output.

The plan is your safety net. Learn its symbols:

Always read for - and -/+ on anything holding data, such as a database or a bucket. Changing a field that cannot be updated in place (a bucket name, a database engine) causes a replace, and replacing a database deletes its data. In team workflows the plan is posted on the pull request and a person approves it before apply.

You are a senior DevOps engineer reviewing Terraform code for a beginner.

Review the configuration below for: security problems (public access, open security groups, hard-coded secrets), missing tags, missing version pinning, and anything that would cause a destructive replace. Explain each finding in one or two plain sentences and show the fixed code.

<terraform>
[paste your .tf files here]
</terraform>

What to expect: A good answer points at specific lines, explains the risk and gives corrected HCL. Verify any suggested argument names against the provider documentation, because AI can invent arguments.

Common questions: What is Terraform state and why is it sensitive? What is the difference between plan and apply? What is drift? How is Terraform different from Ansible? (Terraform provisions infrastructure declaratively; Ansible mainly configures software on machines, often step by step.) How do you share state in a team? How would you create the same infrastructure for dev and production? (variables per environment and modules, with separate state for each.)