Forem: Mukami

Deploying a Static Website on AWS S3 with Terraform: A Beginner's Guide

Mukami — Thu, 16 Apr 2026 07:57:46 +0000

From Zero to a Live, Globally Distributed Website in One Day

Day 25 of the 30-Day Terraform Challenge — and today I built something I can actually show people.

Not just infrastructure. Not just a cluster that responds to curl. An actual website. With a URL. That works in a browser.

Using nothing but Terraform code.

What I Built

A fully serverless static website hosted on AWS S3, served globally through CloudFront, with HTTPS, custom error pages, and environment isolation.

All deployed with one command: terraform apply

The Architecture

User → CloudFront (HTTPS) → S3 Bucket (Static Files)
                              ├── index.html
                              └── error.html

S3 bucket stores the HTML files
Bucket policy makes the files publicly readable
CloudFront distributes content globally and adds HTTPS
Terraform manages everything as code

The Project Structure

day25-static-website/
├── modules/
│   └── s3-static-website/
│       ├── main.tf          # S3 bucket + CloudFront
│       ├── variables.tf     # Configurable inputs
│       └── outputs.tf       # CloudFront URL
├── envs/
│   └── dev/
│       ├── main.tf          # Module call
│       ├── variables.tf
│       └── terraform.tfvars # Environment config
├── backend.tf               # Remote state
└── provider.tf

This structure enforces DRY — the module is reusable, and the environment configuration is minimal.

The Module (Reusable)

The module encapsulates everything needed for a static website:

# modules/s3-static-website/main.tf

resource "aws_s3_bucket" "website" {
  bucket = var.bucket_name
  force_destroy = var.environment != "production"
}

resource "aws_s3_bucket_website_configuration" "website" {
  bucket = aws_s3_bucket.website.id
  index_document { suffix = var.index_document }
  error_document { key = var.error_document }
}

resource "aws_cloudfront_distribution" "website" {
  enabled = true
  origin {
    domain_name = aws_s3_bucket_website_configuration.website.website_endpoint
    origin_id   = "s3-website"
  }
  default_cache_behavior {
    viewer_protocol_policy = "redirect-to-https"
  }
}

Key design decisions:

force_destroy = var.environment != "production" — dev buckets can be destroyed easily, production buckets are protected
CloudFront adds HTTPS automatically — no certificate needed for the default domain
Module outputs the CloudFront URL so callers can access it

The Environment Configuration (Clean)

Because the module does all the heavy lifting, the dev environment config is tiny:

# envs/dev/main.tf
module "static_website" {
  source = "../../modules/s3-static-website"

  bucket_name    = var.bucket_name
  environment    = var.environment
  index_document = "index.html"
  error_document = "error.html"
}

output "cloudfront_url" {
  value = "https://${module.static_website.cloudfront_domain_name}"
}

# envs/dev/terraform.tfvars
bucket_name = "my-terraform-website-day25-20260416"
environment = "dev"

That's it. All the complexity lives in the module.

The Deployment

cd envs/dev
terraform init
terraform plan
terraform apply -auto-approve

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

Outputs:
cloudfront_url = "https://d123.cloudfront.net"

The Result

After waiting 10 minutes for CloudFront to propagate:

curl https://d123.cloudfront.net

<!DOCTYPE html>
<html>
<head><title>Terraform Static Website</title></head>
<body>
  <h1>🚀 Day 25: Deployed with Terraform!</h1>
  <p>Environment: dev</p>
  <p>This website was deployed using Terraform on Day 25!</p>
</body>
</html>

A live, globally distributed website. Deployed entirely through code.

Why This Project Matters

It's real. Not a demo. Not a "hello world" that only works on localhost. A real website with a real URL.

It's complete. S3 + CloudFront + HTTPS + error handling + environment isolation.

It's reusable. The module can deploy dev, staging, and production with different variables.

It demonstrates everything from Days 1-24:

Modules (Day 8-9)
Remote state (Day 6)
DRY principle (Day 4)
Environment isolation (Day 7)
Tags and best practices (Day 16)

What I Learned

S3 static websites are simple but have limits. No HTTPS on the S3 endpoint — that's why you need CloudFront.

CloudFront takes time. 5-15 minutes to propagate globally. Be patient.

The module pattern is powerful. I can now deploy a static website in any environment with 5 lines of code.

Remote state protects your work. The state file is encrypted in S3, not on my laptop.

The DRY Principle in Practice

Without a module, I would have written 100+ lines of S3 + CloudFront configuration for every environment. With a module, each environment needs only 5 lines.

That's the difference between a one-off script and production-grade infrastructure.

My Final Preparation for the Terraform Associate Exam

Mukami — Mon, 13 Apr 2026 15:15:27 +0000

60 Minutes. 57 Questions. No Looking Back.

Day 24 of the 30-Day Terraform Challenge — and today I did something I've been dreading for weeks.

I simulated the real exam.

No notes. No pauses. No second chances to look something up.

Just me, 57 questions, and a 60-minute timer.

Here's what happened, what I learned, and my plan for exam day.

The Simulation Results

Score: 43/57 (75%) — just above the 70% passing threshold

Time remaining: 4 minutes

Questions flagged for review: 12

Domains I struggled with:

Terraform CLI (26% weight) — missed 5 questions
State management (8% weight) — missed 3 questions
Terraform Cloud (4% weight) — missed 2 questions

The CLI section is what almost got me. The questions about -target, -refresh-only, and terraform state mv were harder than I expected.

What I Learned From My Mistakes

The CLI traps:

terraform plan -target doesn't just plan the targeted resource — it also plans any resources that depend on it
terraform state mv requires the full resource address, not just the name
terraform apply -refresh-only updates state to match real infrastructure without changing anything

The state traps:

A stale state file can cause terraform plan to show no changes even when infrastructure has drifted
terraform refresh is deprecated — use terraform apply -refresh-only instead

The Terraform Cloud traps:

Sentinel policies run after plan, before apply
Workspaces in TFC are separate state files, not separate directories

Flash Card Answers (Without Looking)

1. What file does terraform init create to record provider versions?
.terraform.lock.hcl

2. Difference between terraform.workspace and a Terraform Cloud workspace?
terraform.workspace is an expression used in config to get current workspace name. TFC workspace is a separate state file with collaboration features.

3. If you run terraform state rm aws_instance.web, what happens to the EC2 instance?
Nothing — it continues running. Only removed from state.

4. What does depends_on do and when should you use it?
Creates explicit dependency when Terraform can't infer it. Use when a resource needs to wait for another that isn't referenced in its arguments.

5. Purpose of .terraform.lock.hcl?
Locks provider versions so every team member uses the same version.

6. How does for_each differ from count when items are removed from middle?
count reindexes and recreates subsequent resources. for_each keys by value, so only removed item is affected.

7. What does terraform apply -refresh-only do?
Updates state file to match real infrastructure without modifying resources.

8. Maximum items in a single terraform import command?
One — you can only import one resource at a time.

9. What happens when you run terraform plan against a workspace that has never been applied?
It shows all resources as "to be created" since state is empty.

10. What does prevent_destroy do and what does it NOT prevent?
Blocks terraform destroy from deleting the resource. Does NOT prevent manual deletion in AWS Console.

High-Weight Domain Drill

Terraform basics (24%):

templatefile() reads a template file and renders it with variables — useful for user_data scripts
merge() combines multiple maps; later keys overwrite earlier ones
tomap() converts a list of objects to a map, but fails if keys aren't unique

Terraform CLI (26%):

terraform init -upgrade forces provider version upgrades even when lock file pins them
terraform apply -auto-approve skips interactive approval — never use in production
terraform plan -out=file.tfplan saves plan to apply exactly later

IaC concepts (16%):

Declarative = describe desired state, system figures out how to achieve it
Idempotency = applying same config multiple times produces same result
Drift = difference between declared state and actual state

State management (8%):

State is the source of truth — Terraform compares config to state, not directly to AWS
State locking prevents concurrent writes using DynamoDB
State versioning in S3 allows recovery from corruption

Common Exam Traps (I Added 3 More)

1. "Terraform plan shows no changes" doesn't mean infrastructure is correct — stale state can mask drift

2. terraform destroy vs terraform state rm — destroy deletes real resources, state rm only removes from state

3. Module source ?ref=main vs ?ref=v1.0.0 — branch is mutable, tag is immutable. Always pin to tags.

4. sensitive = true does NOT prevent secrets from being stored in state — only masks terminal output

5. Multi-select questions — if it says "select TWO," exactly two. One or three = wrong regardless of which you picked

6. terraform plan -target includes dependencies — not just the targeted resource

Exam-Day Strategy

Read the question twice before looking at answers
Spend max 90 seconds per question — flag and move on if stuck
Eliminate clearly wrong answers first — often gets you from 4 to 2 options
Flag any question you're unsure about — don't waste time overthinking
Answer all flagged questions in remaining time — even guessing beats leaving blank
Watch for "select TWO" instructions — don't over-select or under-select
Trust your gut on first pass — your first instinct is usually right

Remaining Red Topics

Terraform Cloud features — still red. I've used S3 backend, not TFC.

How I'll address this:

Complete TFC "Get Started" tutorials (1 hour)
Create a free TFC account and run a remote plan
Write 10 practice questions about TFC features

The Bottom Line

75% on my first simulation. Not great. Not failing.

The CLI section is my biggest risk. The questions about specific flags and edge cases are harder than I expected.

But I know exactly where my gaps are now. And I have six days to close them.

Whatever the score is on exam day, I know this material better than I did 24 days ago.

Let's go.

Resources:

Preparing for the Terraform Associate Exam — Key Resources and Tips

Mukami — Mon, 13 Apr 2026 06:47:25 +0000

How I Audited My Gaps and Built a Study Plan

Day 23 of the 30-Day Terraform Challenge — and today I shifted from building infrastructure to preparing for the certification.

After 22 days of hands-on work, I thought I was ready. Then I looked at the official exam objectives.

I wasn't as ready as I thought.

The Domain Audit

The exam covers 9 domains with different weights. Here's my honest self-assessment:

Domain	Weight	My Rating
IaC concepts	16%	🟢 Green
Terraform's purpose	20%	🟢 Green
Terraform basics	24%	🟢 Green
Terraform CLI	26%	🟡 Yellow
Modules	12%	🟢 Green
Core workflow	8%	🟢 Green
State management	8%	🟡 Yellow
Configuration	8%	🟢 Green
Terraform Cloud	4%	🔴 Red

Green = I can explain and have done it hands-on.
Yellow = I understand conceptually but need practice.
Red = I need to learn this.

The CLI and state sections are more detailed than I expected. Terraform Cloud is almost entirely new to me.

CLI Commands — Know Them Cold

The exam tests specific command flags. You need to know what each command does and when to use it.

Command	What it does
`terraform init`	Downloads providers, initializes backend
`terraform validate`	Checks syntax and consistency
`terraform fmt`	Formats code to canonical style
`terraform plan`	Shows proposed changes
`terraform apply`	Creates or updates infrastructure
`terraform destroy`	Removes all resources
`terraform output`	Reads outputs from state
`terraform state list`	Lists resources in state
`terraform state show`	Shows resource attributes
`terraform state mv`	Moves resource between states
`terraform state rm`	Removes from state (no destroy)
`terraform import`	Imports existing resources
`terraform workspace`	Manages multiple state files
`terraform providers`	Shows provider versions
`terraform graph`	Outputs dependency graph

The trickiest is understanding what terraform state rm does to real infrastructure — nothing. It only removes from state.

Non-Cloud Providers

Terraform isn't just for AWS. The random and local providers appear frequently on the exam:

resource "random_id" "suffix" {
  byte_length = 4
}

resource "random_password" "db_pass" {
  length  = 16
  special = true
}

resource "local_file" "config" {
  content  = "Password: ${random_password.db_pass.result}"
  filename = "${path.module}/config.txt"
}

Why this matters: The exam expects you to know Terraform works with DNS, TLS, random values, and local files — not just cloud providers.

Terraform Cloud — My Biggest Gap

I used S3 + DynamoDB for remote state. Terraform Cloud has features I haven't touched:

Remote runs (vs local runs)
Sentinel policies (run after plan, before apply)
Private module registry
Workspace-specific variables
Cost estimation

This is only 4% of the exam, but it's 100% new to me.

My Study Plan (Days 24-30)

Topic	Study Method	Time
terraform state commands	Run each command on test resources	45 min
Sentinel policies	Read docs + write 2 policies	60 min
Terraform Cloud	Complete TFC lab exercises	90 min
CLI flags (-out, -target)	Practice each flag	45 min
Random/local providers	Build example configs	30 min
Official sample questions	Complete all	60 min

Practice Questions — Write Your Own

Writing questions forces you to understand the material deeply. Here's one I wrote:

Q: You run terraform state rm aws_instance.web. What happens to the actual EC2 instance?

A) Terminated immediately
B) Removed from state only (continues running) ✅
C) Stopped
D) Removed from state and terminated

Why the wrong answers are wrong:

A, C, D describe actions that affect real infrastructure
Only B correctly states that state rm affects only the state file

Official Sample Questions

I scored 8/10 on my first attempt. The two I missed were about:

Sentinel policy execution timing (runs after plan, before apply)
Terraform Cloud workspace vs directory structure

These went straight into my study plan.

What I Learned

The CLI section is more detailed than most people expect. You need to know specific flags, not just commands.

Non-cloud providers are tested. Don't skip the random and local providers.

Terraform Cloud is different from open source. If you only used S3 backend, you need to study TFC separately.

Writing practice questions is the best study technique. It forces you to think like the exam writer.

The Bottom Line

The exam tests specific knowledge, not just experience. You can build infrastructure for weeks and still miss questions about terraform state mv or Sentinel policy syntax.

My advice:

Print the official study guide
Audit yourself honestly against every objective
Build a concrete study plan for your gaps
Write your own practice questions
Don't underestimate the CLI section

Resources:

Putting It All Together: My 22-Day Terraform Journey

Mukami — Mon, 13 Apr 2026 06:26:35 +0000

From "What's a provider?" to a Complete CI/CD Pipeline

Day 22 of the 30-Day Terraform Challenge — and I can't believe how far I've come.

Twenty-two days ago, I didn't know what a provider alias was. I hardcoded instance types. I thought terraform destroy was the scariest command in the world.

Today, I have a complete integrated pipeline. And I'm about to finish the book.

Here's what I built. What I learned. And what surprised me most.

The Journey in 22 Days

Days	What I Built
1	Introduction to the challenge
2	Setting up AWS CLI, credentials, Terraform
3	First EC2 instance with user data script
4	Configurable web server with variables
5-6	Auto Scaling Group + Application Load Balancer
7	Remote state with S3 + DynamoDB locking
8-9	Reusable modules (webserver cluster)
10	Loops (`count`, `for_each`) and conditionals
11	Environment-aware module (dev vs prod)
12	Zero-downtime deployments
13	Secrets management with AWS Secrets Manager
14-15	Multiple providers (multi-region, EKS, Docker)
16	Production-grade refactor (tags, alarms, validation)
17	Manual testing
18	Automated testing (terraform test + Terratest)
19	IaC adoption strategy for teams
20-21	Application + infrastructure deployment workflows
22	Integrated CI/CD pipeline + Sentinel policies

That's a complete infrastructure platform. Most engineers don't build this much in their first year.

What I Built (The Highlights)

Week 1 (Days 1-7): I went from a single hardcoded EC2 instance to a configurable, load-balanced, auto-scaling cluster with remote state. The jump from Day 3 to Day 5 was the biggest learning curve — understanding ASGs and ALBs took hours.

Week 2 (Days 8-14): I built reusable modules, added conditionals for multi-environment deployments, learned zero-downtime with create_before_destroy, and deployed an EKS cluster with Kubernetes. The EKS section was the most complex — 68 resources, 15 minutes of waiting, and a lot of coffee.

Week 3 (Days 15-22): I refactored everything to production-grade standards (tags, alarms, validation), wrote manual and automated tests, designed an adoption strategy for teams, and finally built an integrated CI/CD pipeline with Sentinel policies.

The Integrated Pipeline

My final workflow combines everything:

name: Infrastructure CI

on:
  pull_request:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform fmt -check -recursive
      - run: terraform init -backend=false
      - run: terraform validate
      - run: terraform test

  plan:
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - run: terraform plan -out=ci.tfplan
      - uses: actions/upload-artifact@v4
        with:
          name: terraform-plan
          path: ci.tfplan

What this does:

Format check on every PR
Validation and unit tests
Plan generation saved as immutable artifact

The same plan can be promoted from dev to prod — no regeneration, no drift.

Sentinel Policies

I wrote two policies to enforce standards:

Policy 1: Require ManagedBy tag

main = rule {
  all tfplan.resource_changes as _, rc {
    rc.change.after.tags["ManagedBy"] is "terraform"
  }
}

Policy 2: Allow only approved instance types

allowed_types = ["t3.micro", "t3.small", "t3.medium"]

These caught several violations in my early code — security groups without tags, t2.micro instances — and forced me to fix them.

The Side-by-Side Comparison

Component	Application Code	Infrastructure Code
Source of truth	Git repository	Git repository
Local run	`npm start`	`terraform plan`
Artifact	Docker image	Saved `.tfplan` file
Versioning	Semantic tag	Semantic tag
Automated tests	Unit + integration	`terraform test` + Terratest
Policy enforcement	Linting	Sentinel policies
Deployment	CI/CD pipeline	`terraform apply <plan>`
Rollback	Redeploy previous image	`terraform apply <previous plan>`

The parallel is striking. Infrastructure code follows the same discipline as application code.

What Changed in How I Think

The single biggest mental shift: Infrastructure is not a one-time setup. It's a software product.

Before: "I'll set up the servers once and never touch them again."

After: "Every infrastructure change goes through version control, review, testing, and CI/CD — just like application code."

Infrastructure isn't a project. It's a product that needs continuous improvement.

What Was Harder Than Expected

State management. Not the technical part — the understanding that state is the source of truth. A corrupted state file is worse than corrupted code.

Testing. Unit tests were easy. Integration tests (Terratest) were hard — writing Go code, handling timeouts, waiting for ALBs to provision.

Multi-region deployments. I thought adding a second region would be trivial. Provider aliases, module design, remote state — everything got more complicated.

EKS. The cluster took 15 minutes to provision, and kubectl authentication was a nightmare. But it worked.

What I Would Do Differently

Week 1: Create a .gitignore before writing any code. I committed state files and provider binaries. Embarrassing.

Week 2: Write unit tests earlier. I waited until Day 18. Testing from Day 1 would have caught bugs earlier.

Week 3: Separate state buckets by environment earlier. One bucket for everything was fine for learning but dangerous for production.

Overall: Read the book before starting the challenge, not during. But that's cheating.

What Comes Next

Terraform Associate Certification. I've been studying the exam objectives. My weak areas are Terraform Cloud features (I used S3 backend) and Sentinel policies.

First real project: Refactor my team's development environment. Five developers, each with a manually configured AWS sandbox. I'll write a module that provisions identical sandboxes for everyone.

Longer term: Contribute to open source Terraform modules. I've learned enough to help others.

Chapter 10's Most Important Insight

Immutable versioned artifacts.

The same Docker image that passes tests in CI gets promoted to staging, then production. No rebuilding. No "but it worked in dev."

For infrastructure, the saved .tfplan file is that immutable artifact. The plan reviewed in the PR is the exact plan applied in production. No drift. No surprises.

This insight changes everything. Infrastructure deployment becomes predictable.

The Bottom Line

Twenty-two days ago, I was afraid of terraform destroy.

Today, I trust it because I know:

State is backed up in versioned S3
Plans are reviewed before apply
Tests run automatically
Sentinel enforces rules
Rollback is one command away

Infrastructure as Code isn't just a tool. It's a discipline.

And it's one I'll carry into every project from now on.

A Workflow for Deploying Infrastructure Code with Terraform

Mukami — Sun, 12 Apr 2026 15:08:49 +0000

Seven Steps. One Plan File. Zero Surprises.

Day 21 of the 30-Day Terraform Challenge — and today I learned that deploying infrastructure code safely requires discipline that application deployments don't need.

Yesterday I mapped the seven-step application workflow. Today I applied it to infrastructure — and discovered where the two workflows diverge and why those differences matter.

The Seven-Step Infrastructure Workflow

Step	Action
1	Version control (Git)
2	Run locally (`terraform plan -out`)
3	Make code changes (feature branch)
4	Submit for review (PR with plan output)
5	Run automated tests (CI)
6	Merge and release (tag)
7	Deploy (apply saved plan file)

Step 1: Version Control

Every infrastructure change starts in Git. Not in the AWS Console.

git init
git add .
git commit -m "Day 21: Initial web server"
git push origin main

Why this matters: Every change has an author, a timestamp, and a reason. No more mystery infrastructure.

Step 2: Run Locally — The Infrastructure Difference

For application code, running locally means executing the binary. For infrastructure, it means running terraform plan.

terraform plan -out=day21.tfplan

The critical difference: You're not running the code. You're generating a diff against your state file. The plan shows exactly what will change in production.

Step 3: Make Code Changes

Create a feature branch and make your change. I added a CloudWatch alarm:

git checkout -b add-cloudwatch-alarm
# Edit main.tf to add the alarm resource
git add main.tf
git commit -m "Add CloudWatch CPU alarm"
git push origin add-cloudwatch-alarm

Step 4: Submit for Review — The Infrastructure Difference

For application code, you review the code diff. For infrastructure, you review the plan output.

My PR description:

## What this changes
Adds a CloudWatch metric alarm for CPU utilization

## Terraform plan output
Plan: 1 to add, 0 to change, 0 to destroy.

## Resources affected
- Created: 1 (CloudWatch alarm)

## Blast radius
Low. Only adds monitoring. No impact on existing resources.

## Rollback plan
Remove the alarm resource and re-apply.

Why this matters: The reviewer sees exactly what will change in production without running Terraform themselves.

Step 5: Run Automated Tests

GitHub Actions runs terraform validate, terraform fmt --check, and unit tests automatically on every PR.

Why this matters: Catch syntax and formatting errors before a human ever reviews the code.

Step 6: Merge and Release

After approval, merge and tag:

git checkout main
git pull origin main
git tag -a "v1.1.0" -m "Add CloudWatch CPU alarm"
git push origin v1.1.0

Why this matters: Tags create rollback points. Every release is versioned.

Step 7: Deploy — The Infrastructure Difference

For application code, you deploy from CI. For infrastructure, you apply the saved plan file.

terraform apply day21.tfplan

The critical difference: Using the saved plan guarantees that exactly what was reviewed is what gets applied. No surprises. No drift between plan and apply.

What I Deployed

A web server with a CloudWatch alarm:

Component	Status
EC2 instance	Running, serving HTTP
Security group	Allow port 80
CloudWatch alarm	Monitoring CPU > 80%

Verification:

$ curl -s http://56.228.18.125
<h1>Day 21: Infrastructure Deployment Workflow</h1>

$ aws cloudwatch describe-alarms --alarm-names day21-high-cpu
{
    "AlarmName": "day21-high-cpu",
    "StateValue": "OK",
    "Threshold": 80.0
}

Infrastructure-Specific Safeguards

These have no equivalent in application code deployment:

1. Plan File Pinning

Always apply from a saved plan, never from a fresh plan.

# Correct — apply exactly what was reviewed
terraform plan -out=reviewed.tfplan
terraform apply reviewed.tfplan

# Risky — the plan may differ
terraform apply

2. Blast Radius Documentation

Every PR must document what breaks if the apply fails.

3. State Backup

S3 bucket versioning must be enabled. Know how to restore a previous state.

4. Approval Gates for Destructive Changes

Any plan showing resource destruction requires explicit approval beyond PR review.

Infrastructure vs Application: Key Differences

Difference	Why It Exists
Plan files, not binaries	Infrastructure changes affect real resources; plan must be reviewed before apply
Blast radius	A bad infrastructure deploy can destroy production data
State management	Terraform tracks real resources; state corruption breaks everything

The Most Dangerous Step

The gap between terraform plan and terraform apply is where things go wrong. If infrastructure changes between plan and apply, the plan becomes invalid.

The safeguard: Save the plan file and apply it directly. Never run terraform apply without a plan file.

# Safe
terraform plan -out=day21.tfplan
terraform apply day21.tfplan

# Risky
terraform apply

What I Learned

Plan output is the most important review artifact. Include it in every PR.

Blast radius matters. A bad infrastructure deploy can break more than a bad code deploy.

Plan file pinning is non-negotiable. Without it, you're applying something that might not match what was reviewed.

State is the source of truth. Protect it with versioning and backups.

The Bottom Line

Deploying infrastructure code requires the same seven steps as application code — plus infrastructure-specific safeguards.

Before	After
Console clicks	Pull requests with plan output
"Who changed this?"	Git blame
Hope it works	Plan file proves it
Can't roll back	Tags and state versioning

Seven steps. Plan files. Blast radius documentation. State backups.

Infrastructure deployment shouldn't be risky. It should be reviewed, tested, and applied exactly as planned.

P.S. The moment I applied a saved plan file and saw exactly what was reviewed happen in production, I understood why teams adopt this workflow. It's not slower. It's safer. 🔧

A Workflow for Deploying Application Code with Terraform

Mukami — Sun, 12 Apr 2026 14:12:01 +0000

Seven Steps from Local Change to Production

Day 20 of the 30-Day Terraform Challenge — and today I learned that infrastructure deployment should look exactly like application deployment.

The same seven steps developers trust to ship code safely can be used to ship infrastructure. No more "clicking around in the console." No more "who changed that security group?" No more "it works on my machine."

Here's how it works.

The Seven-Step Workflow

Step	Action
1	Use version control
2	Run the code locally
3	Make code changes
4	Submit changes for review
5	Run automated tests
6	Merge and release
7	Deploy

Step 1: Version Control

Every infrastructure change starts in Git. Not in the AWS Console. Not in a script. Not in a Slack message.

git init
git add .
git commit -m "Initial web server - Version 1"
git push origin main

Why this matters: Every change has an author, a timestamp, and a reason. No more mystery changes.

Step 2: Run Locally

Before proposing changes, run them locally to see what will happen.

terraform plan -out=day20.tfplan

The output shows exactly what will change:

Which resources will be created
Which will be modified
Which will be destroyed

Why this matters: You catch mistakes before they reach production. Not after.

Step 3: Make Code Changes

Create a feature branch and make your change:

git checkout -b update-to-v3
# Edit main.tf
git add .
git commit -m "Update web server to Version 3"
git push origin update-to-v3

Why this matters: Changes are isolated. Main branch stays deployable. Multiple engineers can work simultaneously.

Step 4: Submit for Review

Open a pull request on GitHub. Include the terraform plan output in the description.

Why this matters: Code review catches mistakes. The plan output shows the reviewer exactly what will happen in production — without them running Terraform themselves.

Step 5: Run Automated Tests

Your CI pipeline runs terraform validate, terraform fmt, and terraform test automatically on every PR.

Why this matters: Catch syntax errors, formatting issues, and logic mistakes before a human ever looks at them.

Step 6: Merge and Release

After approval, merge the PR and tag the release:

git checkout main
git pull origin main
git tag -a "v3.0.0" -m "Version 3 release"
git push origin v3.0.0

Why this matters: Tags give you a history of what changed when. Rollback is as simple as checking out an old tag.

Step 7: Deploy

Apply the saved plan:

terraform apply day20.tfplan

Then verify:

$ curl http://my-server.com
<h1>Version 3: Day 20 workflow complete!</h1>

Why this matters: The plan was reviewed, tested, and approved before apply. No surprises.

What I Actually Deployed

A simple web server that shows its version:

Version	Command	Result
v1	`terraform apply`	"Version 1: Hello from Day 20!"
v2	`terraform plan && apply`	Tag changed, but user_data didn't run
v3	Added `user_data_replace_on_change = true`	"Version 3: Day 20 workflow complete!"

The third attempt worked because I learned that EC2 instances don't re-run user_data unless you force replacement.

Workflow Comparison

Step	Application Code	Infrastructure Code	Key Difference
Version control	Git for source code	Git for .tf files	State file is NOT in Git
Run locally	`npm start` / `python app.py`	`terraform plan`	Plan shows what will change, not a running app
Make changes	Edit source files	Edit .tf files	Changes affect real cloud resources
Review	Code diff in PR	Plan output in PR	Reviewer must understand cloud implications
Automated tests	Unit tests, linting	`terraform test`	Infra tests deploy real resources → cost
Merge and release	Merge + tag	Merge + tag	Module consumers must pin versions
Deploy	CI/CD pipeline	`terraform apply`	Apply must be run from trusted, locked environment

The Biggest Difference

Application code: You run it and see if it works.

Infrastructure code: You run plan and predict what will happen. Then you trust the prediction.

That trust comes from:

Code review
Automated tests
A history of successful deploys
The ability to roll back

What I Learned

Plan output is the most powerful review tool. Include it in every PR. It shows exactly what will change.

User_data doesn't re-run on existing instances. You need user_data_replace_on_change = true or a launch template with create_before_destroy.

Git workflow works for infrastructure. The same seven steps developers trust can be used to deploy infrastructure safely.

Tags matter. Every release gets a tag. Every tag is a rollback point.

The Bottom Line

Infrastructure deployment doesn't need to be risky or mysterious.

The same seven-step workflow that engineers trust to ship application code works perfectly for Terraform.

Before	After
Console clicks	Pull requests
"Who changed this?"	Git blame
Manual testing	Automated tests
Hope it works	Plan output proves it
Can't roll back	Tags = rollback points

Version control. Plan. Review. Test. Merge. Tag. Deploy.

Seven steps. Every time. No exceptions.

P.S. The moment I saw terraform plan show exactly what would change, and then curl confirm it worked, I finally understood why teams adopt this workflow. It's not slower. It's safer.

How to Convince Your Team to Adopt Infrastructure as Code

Mukami — Sun, 12 Apr 2026 13:28:56 +0000

The Technical Part Is Easy. The People Part Is Hard.

Day 19 of the 30-Day Terraform Challenge — and today I learned something uncomfortable.

The technical part of Terraform is the easy part. Writing configurations, managing state, setting up modules — that's straightforward compared to what's actually hard:

Getting a team to change how they work.

The Problem: Engineers Don't Resist Technology

Engineers don't resist technology. They resist:

Changing habits they've had for years
Learning new tools when the old ones "work"
Slowing down to do things the "right" way
Trusting automation over their own judgment

If you're trying to introduce IaC to a team, you're not solving a technical problem. You're solving a people problem.

The Business Case (What Leadership Cares About)

Leadership doesn't care about "better infrastructure." They care about outcomes.

Business Problem	IaC Solution	Measurable Outcome
Infrastructure incidents from manual errors	Code review catches mistakes before apply	Fewer production outages
Hours spent on repetitive environment setup	Reusable modules provision in minutes	Engineering time freed for product work
No audit trail for compliance	Every change is a git commit with author and timestamp	Full audit trail for auditors
Dev environments differ from production	Same config for all environments	Fewer "works on my machine" incidents
Slow onboarding for new engineers	Documented, version-controlled configs	Faster onboarding time

Frame the conversation around outcomes they already care about.

Why Most IaC Adoptions Fail

According to the author, the most common reason IaC adoption fails is:

Trying to do too much at once.

Teams attempt to migrate all their existing infrastructure to Terraform in one big project. It takes months. People get frustrated. Things break. Management loses confidence. The project dies.

The fix: Start small. Win early. Build momentum.

The Incremental Adoption Strategy

Phase 1: Start with Something New (2-4 weeks)

Do not migrate existing infrastructure first. Pick one new piece of infrastructure — a new S3 bucket, a new IAM role, a monitoring dashboard — and provision it entirely with Terraform.

Why this works:

Zero migration risk (it's new, not replacing anything)
Quick win (days, not months)
Team learns without pressure
Creates a success story

Success criteria:

Configuration is code-reviewed and merged
Remote state is configured in S3
Team members can run terraform plan and understand the output

Phase 2: Import Existing Infrastructure (4-6 weeks)

Once the team is comfortable with the workflow, begin importing critical existing resources.

# Example: import an existing S3 bucket
terraform import aws_s3_bucket.existing_logs my-existing-logs-bucket

# Example: import an existing security group
terraform import aws_security_group.existing sg-0abc123def456789

Prioritise resources that:

Change frequently
Have caused incidents
Are well-understood

Do not try to import everything at once.

Phase 3: Establish Team Practices (Ongoing)

Once multiple engineers are writing Terraform, establish the practices that prevent chaos:

Module versioning
Code review requirements for all infrastructure changes
terraform plan output as a required part of every PR
Automated terraform validate and terraform fmt in CI
State locking enforced via DynamoDB
No manual console changes to Terraform-managed resources — ever

Phase 4: Automate Deployments (6-8 weeks)

Connect Terraform to your CI/CD pipeline so that merges to main trigger terraform apply automatically.

At this stage, infrastructure changes go through the same review and deployment process as application code.

The Cultural Shift

Technical changes require cultural changes. Here's what needs to shift:

From	To
"It works on my machine"	"It works in the code"
Manual console changes	Pull requests for everything
Blaming the tool	Blaming the process
Heroic fixes	Reliable rollbacks
"I know what changed"	"The git log knows"

Building Trust in Automation

Teams don't trust automation because they've been burned before. Build trust through:

1. Visibility
terraform plan output is the most transparent change preview possible. Use it in every PR.

2. Safety
Start with read-only changes. Let the team run terraform plan for weeks before anyone runs apply.

3. Rollback capability
Show the team how to revert a change in minutes. Trust comes from knowing you can recover.

4. Gradual rollout
Start with low-risk resources. Work up to critical infrastructure.

What I've Observed

In my experience, the hardest part of IaC adoption isn't technical. It's getting experienced engineers to trust code over console.

Engineers who have been burned by bad automation resist. Engineers who have fixed things manually for years don't see the problem.

The solution isn't better tooling. It's small wins that build confidence over time.

The Bottom Line

The technical part of Terraform is straightforward. The real challenge is:

Convincing leadership to invest in IaC
Getting engineers to change their workflow
Building trust in automation
Moving incrementally when everyone wants to move fast

Start small. Win early. Build momentum. The rest follows.

P.S. The next time someone says "we should just do it manually this once," you'll know that's how drift starts. One manual change becomes ten. Ten becomes a hundred. The only way to win is to never start.

Automating Terraform Testing: From Unit Tests to End-to-End Validation

Mukami — Fri, 10 Apr 2026 06:53:52 +0000

How to Stop Wondering If Your Infrastructure Works and Start Knowing It Does

Day 18 of the 30-Day Terraform Challenge — and today I finally solved the problem that's been bothering me since Day 1.

How do you know your infrastructure actually works?

Manual testing gave me confidence, but it didn't scale. Every change meant re-running the same checks. Every environment meant more time. Every team member meant more coordination.

Today I automated everything.

The Three Layers of Testing

Test Type	Tool	Deploys Real Infra	Time	Cost
Unit	`terraform test`	No	Seconds	Free
Integration	Terratest	Yes	Minutes	Low
End-to-End	Terratest	Yes	15-30 min	Medium

Each layer catches different failures. Together, they create confidence.

Layer 1: Unit Tests (Fast, Free, No AWS)

Terraform 1.6+ includes a native testing framework. No external dependencies. No real infrastructure deployed. Just plan-time assertions.

# webserver_cluster_test.tftest.hcl

variables {
  cluster_name  = "test-cluster"
  instance_type = "t3.micro"
  environment   = "dev"
}

run "validate_asg_name" {
  command = plan

  assert {
    condition     = can(regex("^test-cluster-asg-", aws_autoscaling_group.web.name_prefix))
    error_message = "ASG name prefix must start with cluster_name"
  }
}

run "validate_instance_type" {
  command = plan

  assert {
    condition     = aws_launch_template.web.instance_type == "t3.micro"
    error_message = "Instance type must match variable"
  }
}

run "validate_tags" {
  command = plan

  assert {
    condition     = aws_lb.web.tags["Environment"] == "dev"
    error_message = "ALB must have Environment tag = dev"
  }
}

Run with: terraform test

What it catches: Syntax errors, naming conventions, tag consistency, logic mistakes.

What it doesn't catch: DNS propagation, health check failures, actual HTTP responses.

Layer 2: Integration Tests (Real Infra, Real Assertions)

Integration tests deploy real infrastructure, run assertions against it, then destroy it.

// test/webserver_cluster_test.go
func TestWebserverClusterIntegration(t *testing.T) {
  t.Parallel()

  uniqueID := random.UniqueId()
  clusterName := fmt.Sprintf("test-cluster-%s", uniqueID)

  terraformOptions := &terraform.Options{
    TerraformDir: "../manual-test",
    Vars: map[string]interface{}{
      "cluster_name":  clusterName,
      "instance_type": "t3.micro",
      "min_size":      1,
      "max_size":      2,
      "environment":   "dev",
    },
  }

  // CRITICAL: Always destroy, even if test fails
  defer terraform.Destroy(t, terraformOptions)

  terraform.InitAndApply(t, terraformOptions)

  albDnsName := terraform.Output(t, terraformOptions, "alb_dns_name")
  url := fmt.Sprintf("http://%s", albDnsName)

  // Retry for 5 minutes (ALB takes time)
  http_helper.HttpGetWithRetryWithCustomValidation(
    t, url, nil, 30, 10*time.Second,
    func(status int, body string) bool {
      return status == 200
    },
  )
}

Run with: go test -v -timeout 30m ./...

What it catches: ALB DNS resolution, health check passing, actual HTTP responses, deployment ordering.

The critical piece: defer terraform.Destroy ensures cleanup even if tests fail. No orphaned resources. No surprise AWS bills.

Layer 3: End-to-End Tests (Full Stack)

E2E tests deploy everything — VPC, database, application — and verify the whole system works.

func TestFullStackEndToEnd(t *testing.T) {
  t.Parallel()
  uniqueID := random.UniqueId()

  // Deploy VPC
  vpcOptions := &terraform.Options{
    TerraformDir: "../modules/networking/vpc",
    Vars: map[string]interface{}{
      "vpc_name": fmt.Sprintf("test-vpc-%s", uniqueID),
    },
  }
  defer terraform.Destroy(t, vpcOptions)
  terraform.InitAndApply(t, vpcOptions)

  vpcID := terraform.Output(t, vpcOptions, "vpc_id")
  subnetIDs := terraform.OutputList(t, vpcOptions, "private_subnet_ids")

  // Deploy app using VPC outputs
  appOptions := &terraform.Options{
    TerraformDir: "../modules/services/webserver-cluster",
    Vars: map[string]interface{}{
      "cluster_name": fmt.Sprintf("test-app-%s", uniqueID),
      "vpc_id":       vpcID,
      "subnet_ids":   subnetIDs,
    },
  }
  defer terraform.Destroy(t, appOptions)
  terraform.InitAndApply(t, appOptions)

  albDnsName := terraform.Output(t, appOptions, "alb_dns_name")
  http_helper.HttpGetWithRetry(t, fmt.Sprintf("http://%s", albDnsName), nil, 200, "Hello", 30, 10*time.Second)
}

What it catches: Cross-module integration issues, networking problems, full stack failures that unit and integration tests miss.

The CI/CD Pipeline

Run everything automatically on every commit:

name: Terraform Tests

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  unit-tests:
    name: Unit Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init && terraform test
        working-directory: manual-test

  integration-tests:
    name: Integration Tests
    runs-on: ubuntu-latest
    if: github.event_name == 'push'  # Only on merge to main
    needs: unit-tests
    env:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v4
        with: { go-version: "1.21" }
      - run: go test -v -timeout 30m ./...
        working-directory: test

Job dependencies:

Unit tests run on every PR (fast, cheap)
Integration tests only run on merge to main (slower, costs money)
E2E tests run on schedule (once a day)

Why This Matters

Before automation, every change meant:

Run terraform apply manually
Wait 5 minutes
Test with curl
Remember to destroy
Repeat for every environment

Now, every commit triggers:

Unit tests (10 seconds)
Integration tests (5 minutes)
Confidence that it works

Infrastructure that is tested automatically is infrastructure you can trust.

The Results

Test Type	What It Found	Time	Result
Unit	Missing tags, wrong naming	10s	✅ Caught before PR
Integration	Health check failures, 502 errors	5min	✅ Caught before merge
E2E	Cross-module networking	15min	✅ Caught before release

What I Learned

Unit tests are your safety net. Run them on every commit. They cost nothing and catch everything.

Integration tests are your confidence builder. Run them before merging. They cost a little but find real issues.

E2E tests are your release gate. Run them less frequently. They cost more but verify everything works together.

defer terraform.Destroy is critical. Without it, failed tests leave resources running. With it, cleanup is guaranteed.

Secrets never go in code. Use GitHub Secrets for AWS credentials.

The Bottom Line

Manual testing gave me confidence for one deployment. Automated testing gives me confidence for every deployment.

Before	After
Test once a day	Test every commit
Manual curl checks	Automated HTTP assertions
Hope cleanup works	`defer` guarantees cleanup
30 minutes of manual work	5 minutes of automated trust

If you're not testing your infrastructure automatically, you're deploying with blind faith.

The Importance of Manual Testing in Terraform

Mukami — Mon, 30 Mar 2026 14:06:49 +0000

Why "It Works" Isn't Enough Until You Prove It

Day 17 of the 30-Day Terraform Challenge — and today I learned that my infrastructure "worked" until I actually tested it.

I had a webserver cluster. Terraform applied without errors. Everything looked perfect in the AWS Console. I was confident.

Then I ran a structured manual test. The results were humbling.

The Problem: Code Success ≠ Functional Success

Terraform told me:

✅ 11 resources created
✅ No errors
✅ State matches configuration

But when I actually tried to use my infrastructure:

$ curl http://my-alb-dns
502 Bad Gateway

The code worked. The infrastructure didn't.

This is why manual testing matters.

My Test Checklist

I built a structured test plan covering five categories:

1. Provisioning Verification

terraform init completes without errors
terraform validate passes cleanly
terraform plan shows expected resources
terraform apply completes successfully

2. Resource Correctness

Resources visible in AWS Console
Names match variables
Tags match expected values
Security group rules exactly as defined

3. Functional Verification

ALB DNS resolves
curl returns expected response
ASG instances pass health checks
Instance termination triggers replacement

4. State Consistency

terraform plan returns "No changes"
State file matches AWS resources

5. Cleanup

terraform destroy completes
AWS Console verification shows no resources

What I Found

Passed: 12 tests ✅

Provisioning worked perfectly
All resources created with correct tags
State consistency was perfect
Destroy cleaned up properly

Failed: 2 tests ❌

ALB DNS resolution (timeout)
ALB returned 502 Bad Gateway

The Root Cause

The infrastructure was created, but the application wasn't working. Why?

ALB DNS takes time to propagate — I tested too early
Health checks were failing — Instances weren't responding to HTTP
User-data script may have failed — Apache probably wasn't running

The code was correct. The application was not.

What Manual Testing Taught Me

Terraform applies successfully ≠ infrastructure works

Terraform only checks that resources are created. It doesn't verify that your application is actually running.

DNS propagation is real — Just because the ALB exists doesn't mean it's reachable immediately.

Health checks are the real indicator — A running instance isn't enough. It needs to respond correctly.

Cleanup is harder than it looks — After terraform destroy, I found leftover instances. Manual verification is essential.

The Value of a Test Checklist

Before today, I'd run terraform apply and call it done.

Now I have a checklist that catches:

DNS propagation issues
Application startup failures
Health check problems
Cleanup gaps

Each failed test is a gap I can fix and later automate.

What I Learned About Cleanup

After terraform destroy, I verified with:

aws ec2 describe-instances --filters "Name=tag:Name,Values=*test-webserver*"

I found five instances still running. Terraform destroyed the ASG but instances were still terminating. Manual verification caught what automation missed.

Lesson: Always verify cleanup. Don't trust destroy alone.

The Manual Test Results

Test	Result
terraform init	✅ PASS
terraform validate	✅ PASS
terraform plan	✅ PASS
terraform apply	✅ PASS
Resources in AWS	✅ PASS
Tags correct	✅ PASS
Security group rules	✅ PASS
ALB DNS resolution	❌ FAIL
ALB returns webpage	❌ FAIL
ASG instances running	✅ PASS
State consistency	✅ PASS
terraform destroy	✅ PASS
Cleanup verification	✅ PASS

12 passed, 2 failed.

Why This Matters

Manual testing isn't about checking boxes. It's about finding gaps before they become outages.

If I had deployed this infrastructure without testing:

Users would see 502 errors
I'd be debugging under pressure
The problem would take longer to find

Instead, I found the failure in a controlled environment. I can now fix it and write automated tests to prevent it from happening again.

The Big Lesson

Terraform applies successfully ≠ Infrastructure works

The gap between "code success" and "functional success" is where outages happen. Manual testing closes that gap.

Next Steps

Fix the user-data script to ensure Apache starts reliably
Add wait_for_capacity_timeout to ASG
Wait 2-3 minutes after apply before testing
Write automated tests to catch these issues in CI

P.S. The 502 Bad Gateway was humbling. But finding it manually before deployment was a win. Test early, test often, test manually before you automate. 🚀

Creating Production-Grade Infrastructure with Terraform

Mukami — Mon, 30 Mar 2026 07:21:58 +0000

The Gap Between "It Works" and "It's Production-Ready"

Day 16 of the 30-Day Terraform Challenge — and today I learned that my "working" infrastructure was nowhere near production-ready.

I had a webserver cluster. It deployed. It served traffic. I was proud of it.

Then I ran it against a production-grade checklist. The result was humbling.

The Production-Grade Checklist

I audited my infrastructure against 5 categories:

Category	Score	What I Was Missing
Structure	80%	Some hardcoded values
Reliability	60%	No `prevent_destroy`, no wait timeouts
Security	70%	SSH open to world, no validation
Observability	30%	No consistent tags, no alarms
Maintainability	90%	Missing input validation

The gap was significant. Here's how I closed it.

Refactor 1: Consistent Tagging

Before: Tags scattered across resources, inconsistent.

tags = {
  Name        = "${var.cluster_name}-instance"
  Environment = var.environment
}

After: Centralized tags with locals and merge().

locals {
  common_tags = {
    Environment = var.environment
    ManagedBy   = "Terraform"
    Project     = var.project_name
    Team        = var.team_name
    Day         = "16"
  }
}

tags = merge(local.common_tags, {
  Name = "${var.cluster_name}-alb"
})

Now every resource has the same base tags. Cost allocation, ownership tracking, and operations all benefit.

Refactor 2: Lifecycle Protection

Before: No protection against accidental deletion.

After: Added prevent_destroy to critical resources.

resource "aws_lb" "web" {
  # ... config ...

  lifecycle {
    prevent_destroy = true  # Can't accidentally delete ALB
  }
}

Without this, one wrong terraform destroy wipes production. With it, Terraform errors before doing damage.

Refactor 3: CloudWatch Alarms

Before: No monitoring. If CPU spiked, I wouldn't know.

After: Alarms that notify via SNS.

resource "aws_sns_topic" "alerts" {
  name = "${var.cluster_name}-alerts"
}

resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  alarm_name          = "${var.cluster_name}-high-cpu"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 120
  threshold           = 80
  alarm_description   = "CPU exceeds 80% for 4 minutes"

  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.web.name
  }

  alarm_actions = [aws_sns_topic.alerts.arn]
}

Now when CPU hits 80% for 4 minutes, I get an alert. I can scale before users notice.

Refactor 4: Input Validation

Before: Any value was accepted. environment = "prod" would work.

After: Validation blocks catch mistakes early.

variable "environment" {
  validation {
    condition     = contains(["dev", "staging", "production"], var.environment)
    error_message = "Environment must be dev, staging, or production."
  }
}

variable "instance_type" {
  validation {
    condition     = can(regex("^t[23]\\.", var.instance_type))
    error_message = "Instance type must be a t2 or t3 family type."
  }
}

Try terraform plan -var="environment=prod" (missing "uction"):

Error: Invalid value for variable
Environment must be dev, staging, or production.

Caught at plan time, not after deployment.

Refactor 5: ASG Wait Timeout

Before: No wait_for_capacity_timeout — Terraform would move on before instances were healthy.

After: Added patience.

resource "aws_autoscaling_group" "web" {
  health_check_grace_period = 300
  wait_for_capacity_timeout = "10m"
}

Now Terraform waits up to 10 minutes for instances to pass health checks before destroying old ones. Critical for zero-downtime.

The Before and After

Aspect	Before	After
Tags	Inconsistent	Centralized, all resources tagged
Deletion Protection	None	`prevent_destroy` on ALB
Monitoring	None	CloudWatch alarms + SNS
Validation	None	All variables validated
ASG Wait	None	10-minute timeout
SSH Access	0.0.0.0/0	Restricted (configurable)

What I Learned

Production-grade isn't about features. It's about resilience.

My code "worked." But it wouldn't survive:

A bad terraform destroy command
A CPU spike at 3 AM
A teammate typing "prod" instead of "production"
An instance taking 2 minutes to boot

Each refactor addresses a failure mode I hadn't considered.

The Checklist Matters

The production-grade checklist isn't just a list. It's a map of failure modes.

Tagging → Who owns this? Who pays for it?
prevent_destroy → What happens if I fat-finger this?
Alarms → How will I know something is wrong?
Validation → What if someone passes wrong values?
Timeouts → What if things take longer than expected?

Every checkbox answers a "what if" question.

The Bottom Line

Today I transformed "working" infrastructure into "production-ready" infrastructure.

The difference isn't features. It's resilience, observability, and safety.

If you're deploying code that matters, run it through a production checklist.

P.S. The moment I added prevent_destroy to my ALB, I felt safer. The moment I added validation, I felt smarter. The moment I added alarms, I felt like a real engineer. Small changes, big impact.

Deploying Multi-Cloud Infrastructure with Terraform Modules

Mukami — Sun, 29 Mar 2026 09:21:41 +0000

From S3 Buckets to EKS Clusters — All in One Configuration

Day 15 of the 30-Day Terraform Challenge — and today I learned that Terraform isn't just for AWS. It's for everything.

One configuration. Multiple providers. S3 buckets across regions. Docker containers locally. A full Kubernetes cluster on EKS. All from the same tool.

Here's how it all came together.

Part 1: Multi-Provider Modules

The first challenge: creating a module that works across multiple AWS regions.

Modules can't hardcode providers. That would break reusability. Instead, they must accept provider configurations from the caller.

The module (no provider block inside):

terraform {
  required_providers {
    aws = {
      source                = "hashicorp/aws"
      version               = "~> 5.0"
      configuration_aliases = [aws.primary, aws.replica]
    }
  }
}

resource "aws_s3_bucket" "primary" {
  provider = aws.primary
  bucket   = "${var.app_name}-primary"
}

resource "aws_s3_bucket" "replica" {
  provider = aws.replica
  bucket   = "${var.app_name}-replica"
}

The caller (provides the providers):

provider "aws" {
  alias  = "primary"
  region = "eu-north-1"
}

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

module "multi_region_app" {
  source = "../modules/multi-region-app"

  providers = {
    aws.primary = aws.primary
    aws.replica = aws.replica
  }
}

This pattern is how Terraform scales to global infrastructure.

Part 2: Docker Provider — Local Testing

Before deploying to Kubernetes, I tested locally with Docker:

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.0"
    }
  }
}

resource "docker_image" "nginx" {
  name = "nginx:latest"
}

resource "docker_container" "nginx" {
  image = docker_image.nginx.image_id
  name  = "terraform-nginx"

  ports {
    internal = 80
    external = 8080
  }
}

One terraform apply later:

$ docker ps
CONTAINER ID   IMAGE          COMMAND                  PORTS                  NAMES
2ea179f7333b   nginx:latest   "/docker-entrypoint.…"   0.0.0.0:8080->80/tcp   terraform-nginx

$ curl http://localhost:8080
<!DOCTYPE html>
<html>
<head><title>Welcome to nginx!</title>...

A container running on my machine, provisioned entirely by Terraform. No Docker commands. No manual setup.

Part 3: EKS Cluster — The Big One

This was the most complex deployment yet. An entire Kubernetes cluster on AWS EKS.

VPC first (using community module):

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "eks-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-north-1a", "eu-north-1b", "eu-north-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
}

Then the EKS cluster:

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "terraform-challenge-cluster"
  cluster_version = "1.29"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    default = {
      min_size       = 1
      max_size       = 3
      desired_size   = 2
      instance_types = ["t3.small"]
    }
  }
}

The Kubernetes provider (authenticates using AWS token):

provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)

  exec {
    api_version = "client.authentication.k8s.io/v1beta1"
    command     = "aws"
    args        = ["eks", "get-token", "--cluster-name", module.eks.cluster_name]
  }
}

This exec block runs aws eks get-token to generate a temporary authentication token. No hardcoded credentials.

Part 4: Deploying to Kubernetes

With the cluster running, I deployed nginx:

resource "kubernetes_deployment" "nginx" {
  metadata {
    name = "nginx-deployment"
    labels = { app = "nginx" }
  }

  spec {
    replicas = 2

    selector {
      match_labels = { app = "nginx" }
    }

    template {
      metadata {
        labels = { app = "nginx" }
      }

      spec {
        container {
          image = "nginx:latest"
          name  = "nginx"
          port  { container_port = 80 }
        }
      }
    }
  }
}

resource "kubernetes_service" "nginx" {
  metadata {
    name = "nginx-service"
  }

  spec {
    selector = { app = "nginx" }
    port { port = 80; target_port = 80 }
    type = "LoadBalancer"
  }
}

Part 5: The Moment It Worked

After 8 minutes of cluster provisioning (felt like an eternity), the nodes appeared:

$ kubectl get nodes
NAME                                          STATUS   ROLES    AGE   VERSION
ip-10-0-1-219.eu-north-1.compute.internal     Ready    <none>   21m   v1.29
ip-10-0-2-67.eu-north-1.compute.internal      Ready    <none>   21m   v1.29

Then the nginx pods:

$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-xxxxxxxxxx-xxxxx   1/1     Running   0          30s
nginx-xxxxxxxxxx-yyyyy   1/1     Running   0          30s

And finally, the LoadBalancer:

$ kubectl get service nginx
NAME    TYPE           EXTERNAL-IP
nginx   LoadBalancer   a4410db0bc9904a48978a65e7108ee18-2037003514.eu-north-1.elb.amazonaws.com

A publicly accessible nginx server, running on Kubernetes, provisioned entirely by Terraform.

What I Learned

Modules must accept providers. You can't hardcode regions inside a reusable module. Use configuration_aliases and pass providers from the root.

The Docker provider is great for local testing. Before deploying to EKS, I tested the same container image locally. Saved time and money.

EKS takes time. 8-10 minutes for the control plane. Another 2-3 minutes for nodes. Patience is required.

RBAC is the final hurdle. Even with the cluster running, your IAM user needs explicit permissions via Access Entry and policy association.

One tool, many providers. AWS, Docker, Kubernetes — all from the same Terraform configuration.

The Cost Warning

EKS isn't free. A cluster costs ~$0.10/hour plus EC2 nodes (~$0.04/hour each). My 2-hour test cost about $0.50. Always destroy when done.

terraform destroy -auto-approve

The Bottom Line

Today I deployed:

S3 buckets in two AWS regions (using provider aliases)
A Docker container locally (using Docker provider)
A full EKS cluster with 2 nodes (using AWS EKS module)
Nginx pods on Kubernetes (using Kubernetes provider)

All from one Terraform configuration.

This is why I love Terraform. One language. One workflow. Every cloud.

Getting Started with Multiple Providers in Terraform

Mukami — Sun, 29 Mar 2026 08:07:33 +0000

How to Deploy Across Multiple AWS Regions Without Losing Your Mind

Day 14 of the 30-Day Terraform Challenge — and today I learned that Terraform isn't limited to one region or one account.

One provider config. Multiple regions. Multiple accounts. Same codebase.

Here's how it works.

What Is a Provider?

A provider is a plugin that translates Terraform code into API calls. The AWS provider knows how to create S3 buckets. The Kubernetes provider knows how to create pods. The random provider generates... random stuff.

When you run terraform init, Terraform downloads these plugins from the Terraform Registry. No manual installation. No hunting for binaries.

Pinning Provider Versions

Never leave your provider version blank. That's how things break unexpectedly.

terraform {
  required_version = ">= 1.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"  # Any 5.x, but not 6.0
    }
  }
}

The ~> 5.0 constraint means: use version 5.0 or higher, but less than 6.0. You get bug fixes and security patches, but no breaking changes.

After terraform init, check .terraform.lock.hcl. It records the exact version downloaded. Commit this file to Git. It ensures your whole team uses the same provider version.

The Default Provider

A basic provider config applies to every resource in your configuration:

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

resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"  # Deploys in eu-north-1
}

Terraform uses this default provider for every resource that doesn't specify otherwise.

Multiple Regions: Provider Aliases

Want resources in two regions? Define an alias:

# Default provider — primary region
provider "aws" {
  region = "eu-north-1"
}

# Aliased provider — secondary region
provider "aws" {
  alias  = "ireland"
  region = "eu-west-1"
}

# Aliased provider — tertiary region
provider "aws" {
  alias  = "frankfurt"
  region = "eu-central-1"
}

Now you can deploy resources anywhere:

# Uses default provider (eu-north-1)
resource "aws_s3_bucket" "primary" {
  bucket = "primary-bucket"
}

# Uses ireland alias
resource "aws_s3_bucket" "replica" {
  provider = aws.ireland
  bucket   = "replica-bucket"
}

# Uses frankfurt alias
resource "aws_s3_bucket" "backup" {
  provider = aws.frankfurt
  bucket   = "backup-bucket"
}

Terraform knows exactly which API endpoint to call for each resource.

S3 Cross-Region Replication Example

Here's a practical use case: replicate data across regions for disaster recovery.

# Primary bucket in eu-north-1
resource "aws_s3_bucket" "primary" {
  bucket = "app-primary-data"
}

# Replica bucket in eu-west-1
resource "aws_s3_bucket" "replica" {
  provider = aws.ireland
  bucket   = "app-replica-data"
}

# Replication configuration
resource "aws_s3_bucket_replication_configuration" "replication" {
  role   = aws_iam_role.replication.arn
  bucket = aws_s3_bucket.primary.id

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.replica.arn
      storage_class = "STANDARD"
    }
  }
}

Now every file uploaded to the primary bucket is automatically replicated to Ireland. If eu-north-1 goes down, your data is safe.

Multiple AWS Accounts

For multi-account setups, use assume_role:

provider "aws" {
  alias  = "prod"
  region = "eu-north-1"

  assume_role {
    role_arn = "arn:aws:iam::111111111111:role/TerraformDeployRole"
  }
}

provider "aws" {
  alias  = "staging"
  region = "eu-north-1"

  assume_role {
    role_arn = "arn:aws:iam::222222222222:role/TerraformDeployRole"
  }
}

The IAM role in each account needs permissions to create the resources you're managing. Terraform assumes the role, performs the operations, then drops the credentials.

The Lock File Explained

After terraform init, you get .terraform.lock.hcl:

provider "registry.terraform.io/hashicorp/aws" {
  version     = "5.100.0"      # Exact version installed
  constraints = "~> 5.0"       # Your version constraint
  hashes = [
    "h1:abc123def456...",      # Checksum for verification
  ]
}

Why commit this file?

Everyone uses the same provider version
No "works on my machine" problems
Hashes verify downloads haven't been tampered with

Chapter 7 Learnings

What happens during terraform init?

Reads your required_providers block
Downloads provider binaries from the Terraform Registry
Records exact versions in .terraform.lock.hcl

version vs ~> version:

version = "5.0" — exact version only
~> 5.0 — any 5.x version, but not 6.0 (allows patches)

How Terraform chooses a provider: Uses the default provider unless you specify provider = alias in the resource.

What I Learned

Provider aliases unlock multi-region infrastructure. One configuration can now deploy globally.

The lock file is your friend. Commit it. It prevents version drift across your team.

Multi-account deployments are just aliases with assume_role. Same pattern, different accounts.

The Bottom Line

Terraform isn't limited to one region or one account. With provider aliases, you can deploy anywhere.

Need	Solution
Multiple regions	Provider aliases
Multiple accounts	`assume_role` + aliases
Version consistency	Pin versions + commit lock file

One configuration. Global infrastructure.

P.S. The lock file seems like a small detail, but it's saved me from "but it worked on my laptop" conversations more times than I can count. Commit it. 🔒