DEV Community: Mukami

Ready for Terraform Certification: My Final Exam Prep and 30-Day Reflection

Mukami — Tue, 21 Apr 2026 18:06:28 +0000

Five Practice Exams. 30 Days. 1,247 Lines of HCL. Zero Sanity Left.

Day 30 of the 30-Day Terraform Challenge: and I survived.

Barely. My keyboard has seen things. My AWS bill has seen worse. My terraform destroy reflex is now faster than my morning coffee reflex.

Five practice exams. 30 days of building. Countless "why is this not working" moments. And one certification prep that started as a goal and became an obsession.

Here's where I stand, what I learned, and why I'm finally ready to face the exam.

Practice Exam 5: The Final Boss

Score: 46/57 (81%)

Character Arc:

Exam 1 (Day 28): 74% — nervous, sweaty palms, second-guessing everything
Exam 5 (Today): 81% — confident, calm, only mildly questioning my life choices

Improvement: +7%

What this tells me: My brain has been successfully reprogrammed. The gaps are filled. The CLI flags no longer haunt my dreams.

Five-Exam Score Summary

Exam	Score	%	Mood
Exam 1	42/57	74%	"Wait, what does `state rm` do again?"
Exam 2	44/57	77%	"Oh, I actually know some of this"
Exam 3	45/57	79%	"I am become Terraform, destroyer of resources"
Exam 4	43/57	75%	"Brain.exe has stopped working" (fatigue)
Exam 5	46/57	81%	"Let's do this."

Average: 44/57 (77%) — consistently above passing
Peak: 81% — ready to book

Fill-in-the-Blank Results

My answers (from memory, no peeking):

terraform fmt — because my code was uglier than my sleep schedule
prevent_destroy — the "save me from myself" button
terraform.workspace — the magic variable that knows where you are
encrypt — because secrets in plaintext are a resume-generating event
set — for_each's best friend (maps are also invited to the party)
rm — removes from state, not from existence (confusing? yes. important? also yes)
3.0 — because ~> 2.0 is a promise, not a suggestion
existing / managed — one reads, one creates. don't mix them up.
.terraform.lock.hcl — the bouncer that keeps provider versions consistent
myplan.tfplan — apply what you planned, not what your tired brain thinks you planned

All correct. The knowledge is in there. Somewhere between the coffee and the broken builds.

Final Readiness Check (The "Can I Actually Do This?" Test)

1. What does terraform init do to your .terraform directory?
Downloads providers and modules. It's like grocery shopping for your infrastructure.

2. Difference between terraform.tfstate and terraform.tfstate.backup?
One is the source of truth. The other is the "oops, I broke it" safety net.

3. Why never commit terraform.tfstate to version control?
Secrets. Also merge conflicts. Also your teammates will never forgive you.

4. What does depends_on do and when should you use it?
Terraform's way of saying "I know you think this doesn't matter, but trust me, it does." Use it when Terraform can't figure out dependencies on its own.

5. Difference between a variable block and a locals block?
Variables are inputs from outside (like asking your friend what pizza topping they want). Locals are internal calculations (like deciding how many slices everyone gets).

6. What happens if you run terraform apply and the state file was modified by another team member?
Chaos. Or an error message. Depends on whether you have state locking enabled. (Enable state locking.)

7. What does terraform graph output and what is it used for?
A beautiful mess of dependencies that looks like a conspiracy theorist's wall. Used for debugging when you have no idea why Resource A depends on Resource B.

8. What is the Terraform Registry?
The App Store for infrastructure. Providers, modules, and policies — all ready to download.

9. Difference between Terraform Cloud and Terraform Enterprise?
One is SaaS (they run it). One is self-hosted (you run it, good luck).

10. When a module uses configuration_aliases, what problem does it solve?
"How do I use this module in two different regions without copying the entire thing?" — this is the answer.

Confidence level: I'm ready. The exam is not ready for me.

30-Day Reflection (The Therapy Session)

What changed?

What changed is how I think.

Before Day 1, infrastructure was something I set up once and prayed no one touched. After Day 30, infrastructure is code. It goes through PRs. It has tests. It has a CI/CD pipeline. It has opinions about how it should be deployed.

The biggest shift: I stopped fearing terraform destroy. I trust it because I know state is backed up, plans are reviewed, and rollback is one command away. That's not confidence — that's engineering.

What am I most proud of?

The EKS cluster on Day 15.

It took 15 minutes to provision. It failed twice. kubectl authentication broke in ways I didn't know were possible. I spent hours debugging. I questioned every life choice that led me to that moment.

But when kubectl get nodes finally returned two Ready nodes, I felt like Neo seeing the Matrix for the first time. That cluster taught me more about debugging, patience, and AWS networking than any tutorial ever could.

What comes next?

First, the certification exam. I'm booking it for next week. The practice exams say I'm ready. My gut says I'm ready. (My sleep schedule says otherwise, but that's a separate issue.)

After that: contributing to open source Terraform modules. I've broken enough things. Time to help fix some.

Exam Logistics

Status: Not yet booked — aiming for next Friday

Plan:

Online proctored (so I can wear comfortable pants)
Morning slot (my brain works before noon)
Clear desk, test webcam, have ID ready
One final practice exam the day before, then rest

What could go wrong: Everything. But I've debugged worse.

Closing Message to the Future Participant

You will break things. You will get frustrated. You will stare at terraform plan output wondering why it wants to destroy your entire VPC when you only changed a tag.

That's not failure. That's learning.

Here's what I wish someone told me on Day 1:

Commit .gitignore before you commit anything else
Write tests earlier — they're not optional
Every error message is telling you exactly what's wrong. Read it. Then read it again. Then maybe Google it.
terraform state rm does NOT delete the resource. Learn this before you learn it the hard way.

You will finish this challenge knowing more than most engineers learn in their first year.

Trust the process. Break things they won't break you. Fix them. Then break them again.

And when you finally pass the exam, celebrate. You earned it.

The Bottom Line (In Numbers)

Metric	Before	After
Fear of `terraform destroy`	10/10	2/10
Hardcoded values	Embarrassing	Zero
Test coverage	None	Unit + integration
State location	Local laptop (yikes)	S3 + DynamoDB
Regions	1	3 (multi-region flex)
Confidence in passing exam	"Maybe?"	"Let's go."

Day 30. Challenge complete. Exam next. Let's do this.

Fine-tuning My Terraform Exam Prep with Practice Exams

Mukami — Tue, 21 Apr 2026 17:18:38 +0000

Four Exams. 228 Questions. One Clear Picture.

Day 29 of the 30-Day Terraform Challenge — and today I did something that felt excessive.

Two more practice exams. 57 questions each. Same conditions. No notes. No looking up answers.

Four exams in two days. 228 questions total.

But the exams weren't the point. The analysis after them was.

The Four-Exam Score Trend

Exam	Score	Percentage	Notes
Exam 1 (Day 28)	42/57	74%	First run, nervous
Exam 2 (Day 28)	44/57	77%	Warm-up effect
Exam 3 (Today)	45/57	79%	Feeling confident
Exam 4 (Today)	43/57	75%	Fatigued, rushed last 10 questions

Trend analysis: Scores are consistently above 70% (range 74-79%). The drop on Exam 4 was fatigue — I finished with only 2 minutes left and rushed the final questions.

Readiness rating: Nearly Ready. My knowledge is solid, but endurance is a factor. On the real exam, I need to pace myself better.

Persistent Wrong-Answer Topics

Across all four exams, these topics appeared in my wrong answers more than once:

1. `terraform state rm` vs `terraform destroy`

Wrong understanding: Thought state rm would delete the real resource
Correct understanding: state rm removes from state only. destroy deletes real infrastructure. The resource continues running in AWS after state rm.

2. `terraform plan -target` includes dependencies

Wrong understanding: Thought -target only plans the specified resource
Correct understanding: It plans the targeted resource AND any resources that depend on it

3. `terraform apply -refresh-only`

Wrong understanding: Thought it was part of normal apply
Correct understanding: It only updates state to match real infrastructure without making changes

4. Sentinel policy execution timing

Wrong understanding: Thought Sentinel runs before plan
Correct understanding: Runs after plan, before apply — evaluates proposed changes before they happen

5. Provider version constraint `~> 1.0.0`

Wrong understanding: Thought it meant any 1.x version
Correct understanding: It means >= 1.0.0 and < 1.1.0 — only the last digit can increment

6. Workspace behaviour

Wrong understanding: Thought workspaces are separate directories
Correct understanding: Each workspace has its own state file; terraform.workspace returns the workspace name as a string

Hands-On Exercises to Close the Gaps

Exercise 1: State Commands

# Deploy test resource
echo 'resource "random_id" "test" { byte_length = 4 }' > main.tf
terraform init && terraform apply -auto-approve

# Verify resource exists
terraform state list
# Output: random_id.test

# Remove from state only
terraform state rm random_id.test
terraform state list
# Output: (empty) — gone from state

# Resource still exists in AWS? For random_id it's generated, but for EC2 it would still run

What this reinforced: state rm only removes from state. The real resource continues to exist.

Exercise 2: Workspace Practice

# Create workspaces
terraform workspace new dev
terraform workspace new staging
terraform workspace list
# Output: default, dev, staging

# Switch and verify
terraform workspace select dev
terraform workspace show
# Output: dev

# Delete (cannot delete current workspace)
terraform workspace select default
terraform workspace delete staging

What this reinforced: Workspaces are separate state files; terraform.workspace is the expression you use in config.

Exercise 3: Provider Version Constraints

# Example 1: ~> 5.0
# Means: >= 5.0.0 and < 6.0.0 (any 5.x version)
required_providers {
  aws = { source = "hashicorp/aws", version = "~> 5.0" }
}

# Example 2: ~> 5.1.0
# Means: >= 5.1.0 and < 5.2.0 (only patch increments)
required_providers {
  aws = { source = "hashicorp/aws", version = "~> 5.1.0" }
}

# Example 3: >= 5.0, < 6.0
# Means: exactly the same as ~> 5.0 (explicit version)
required_providers {
  aws = { source = "hashicorp/aws", version = ">= 5.0, < 6.0" }
}

Final Study Priority List (Day 30)

Priority	Topic	Specific Focus
1	State commands	Difference between `state rm` and `destroy`
2	CLI flags	`-target`, `-refresh-only`, `-upgrade` behaviour
3	Provider constraints	`~>` vs `>=` vs exact version ranges
4	Workspaces	CLI workspaces vs TFC workspaces
5	Sentinel policies	Execution timing and enforcement flow

What I Learned

Fatigue is real. My score dropped on Exam 4 because I was tired. On the real exam, I need to pace myself and not rush the last questions.

Persistent gaps are the only ones that matter. A one-off mistake is fine. A topic you miss twice is a genuine gap that needs hands-on practice.

Hands-on beats reading. Every concept I got wrong more than once, I fixed by running actual commands.

I'm not ready, but I'm nearly ready. Consistently above 70% across four exams tells me I know the material. The last day is about closing the persistent gaps and building endurance.

The Bottom Line

Four exams. 228 questions. 74-79% consistently.

Not perfect. But clear.

I know exactly where my gaps are:

State commands
CLI flags
Provider constraints
Workspaces
Sentinel

One day left. Hands-on practice only. No more exams.

A gap you close today is a point you won't lose tomorrow.

Resources:

How I Prepared for the Terraform Associate Exam with Practice Questions

Mukami — Tue, 21 Apr 2026 16:20:02 +0000

Two Practice Exams. 114 Questions. Zero Looking Up Answers.

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

Two full practice exams. 57 questions each. 60 minutes each. No notes. No looking things up. No "just this one quick search."

Just me, the questions, and a timer.

Here's what happened, what I learned, and how I'm using my wrong answers to close the gaps.

The Scores

Exam	Score	Percentage	Result
Exam 1	42/57	74%	✅ Pass
Exam 2	44/57	77%	✅ Pass

Difference: +3% on Exam 2. The warm-up effect is real. By the second exam, my brain was in Terraform mode and I was reading questions more carefully.

The passing threshold is 70% (40/57). I passed both, but not comfortably. There are clear gaps.

Domain Accuracy Breakdown

Domain	Q's Attempted	Correct	Accuracy
IaC concepts	8	8	100%
Terraform's purpose	10	9	90%
Terraform basics	12	10	83%
Terraform CLI	14	9	64% ❌
Terraform modules	6	5	83%
Core workflow	5	5	100%
State management	5	3	60% ❌
Configuration	5	4	80%
Terraform Cloud	2	1	50% ❌

Three domains below 70%:

Terraform CLI (64%)
State management (60%)
Terraform Cloud (50%)

The CLI section is the heaviest-weighted domain (26%). This is where I need to focus.

Wrong-Answer Analysis

Question 1

Topic: terraform state rm behaviour

What I answered: The EC2 instance is terminated immediately

Correct answer: The instance continues running; only removed from state

Why I was wrong: I confused terraform state rm with terraform destroy. state rm only removes the resource from the state file. The real infrastructure is untouched.

Doc reference: Terraform state rm

Hands-on fix:

terraform state rm aws_instance.web
# Instance still running in AWS
terraform destroy  # This would terminate it

Question 2

Topic: terraform plan -target behaviour

What I answered: Only plans the targeted resource

Correct answer: Plans the targeted resource AND any resources that depend on it

Why I was wrong: I thought -target was a surgical tool. It's not — Terraform must maintain dependency integrity.

Doc reference: Terraform plan -target

Hands-on fix:

terraform plan -target=aws_instance.web
# Also shows dependent resources like security groups

Question 3

Topic: terraform apply -refresh-only

What I answered: It refreshes the state and applies changes

Correct answer: It only updates state to match real infrastructure without making changes

Why I was wrong: I thought -refresh-only was part of normal apply. It's a separate operation.

Doc reference: Terraform apply -refresh-only

Hands-on fix:

terraform apply -refresh-only
# State updated, no resources modified

Question 4

Topic: Sentinel policy execution timing

What I answered: Before plan

Correct answer: After plan, before apply

Why I was wrong: I thought Sentinel was a pre-plan validator. It actually runs after plan to enforce policy on proposed changes.

Doc reference: Sentinel policies

Hands-on fix: Ran a Sentinel policy in Terraform Cloud workspace to see the enforcement flow.

Question 5

Topic: TFC workspace vs directory isolation

What I answered: TFC workspaces are separate directories

Correct answer: TFC workspaces are separate state files with collaboration features

Why I was wrong: I used S3 backend, not TFC. The mental model was wrong.

Doc reference: Terraform Cloud workspaces

Hands-on fix: Created a free TFC account and set up a workspace.

Hands-On Revision for Weak Areas

Domain: Terraform CLI

# Practiced each command
terraform state list
terraform state show aws_instance.web
terraform state mv aws_instance.web aws_instance.web_old
terraform state rm aws_instance.web_old
terraform plan -target=aws_instance.web
terraform apply -refresh-only

Domain: State Management

# Created test resources, ran state commands
terraform apply -auto-approve
terraform state list
# Removed from state, observed instance still running
terraform state rm aws_instance.test
aws ec2 describe-instances --instance-ids i-12345
# Re-imported
terraform import aws_instance.test i-12345

Domain: Terraform Cloud

Created free TFC account
Set up workspace connected to GitHub
Configured variable sets
Ran a remote plan
Observed Sentinel policy enforcement

Pattern Recognition

After two exams, I noticed three patterns in my wrong answers:

1. CLI flag edge cases — I know the main commands but miss the specific flags (-refresh-only, -target dependencies, -upgrade behaviour)

2. State vs real infrastructure — I consistently confuse commands that affect state vs commands that affect real resources

3. TFC-specific features — I've used S3 backend throughout the challenge, so TFC questions are harder

The fix: Hands-on practice with each CLI flag and creating a TFC account to see the features in action.

Plan for Days 29 and 30

Day	Focus	Activities
Day 29	CLI + State	Drill every command, run state operations on test resources, write practice questions
Day 30	TFC + Final Review	Complete TFC tutorials, review wrong answers, light review only

Specific topics to prioritise:

terraform state mv and terraform state rm edge cases
terraform plan -target dependency behaviour
terraform apply -refresh-only use cases
TFC workspace vs directory structure
Sentinel policy execution flow

What I Learned

Practice exams are not about the score. They're about finding gaps. My 74% and 77% are not impressive. But they showed me exactly where I need to study.

The wrong-answer review is the most valuable work. Writing down why I was wrong forces me to confront the misunderstanding, not just memorise the right answer.

The warm-up effect is real. My second score was higher. On exam day, I'll do a quick review session beforehand.

Hands-on beats reading. Every question I got wrong about CLI flags, I fixed by running the actual command.

The Bottom Line

Before today	After today
Thought I was ready	Know exactly where my gaps are
Vague confidence	Specific weak domains (CLI, state, TFC)
No practice exam experience	Two full simulations

Two days left. CLI, state, and TFC are my focus.

A wrong answer you have analysed properly will not fool you on exam day.

Resources:

Building a 3-Tier Multi-Region High Availability Architecture with Terraform

Mukami — Fri, 17 Apr 2026 09:06:36 +0000

From Single Region to Production-Grade Global Infrastructure

Day 27 of the 30-Day Terraform Challenge — and today I built something that can survive an entire AWS region going offline.

Yesterday I built a scalable web app in one region. Today I built infrastructure that spans two regions, with automatic failover, cross-region database replication, and zero single points of failure.

This is what production-grade looks like.

The Architecture

                    ┌─────────────────────────────────────────────────────────────┐
                    │                    Route53 Failover DNS                      │
                    │                   app.example.com                            │
                    └─────────────────────┬───────────────┬───────────────────────┘
                                          │               │
                    ┌─────────────────────▼───────────────▼───────────────────────┐
                    │                                                             │
                    │  PRIMARY REGION (us-east-1)    SECONDARY REGION (us-west-2) │
                    │                                                             │
                    │  ┌─────────────┐               ┌─────────────┐              │
                    │  │    ALB      │               │    ALB      │              │
                    │  └──────┬──────┘               └──────┬──────┘              │
                    │         │                             │                      │
                    │  ┌──────▼──────┐               ┌──────▼──────┐              │
                    │  │    ASG      │               │    ASG      │              │
                    │  │  (2-4 EC2)  │               │  (2-4 EC2)  │              │
                    │  └──────┬──────┘               └──────┬──────┘              │
                    │         │                             │                      │
                    │  ┌──────▼──────┐               ┌──────▼──────┐              │
                    │  │ RDS Multi-AZ│◄──────────────│ RDS Replica │              │
                    │  │  (Primary)  │   Replication  │  (Read-only)│              │
                    │  └─────────────┘               └─────────────┘              │
                    └─────────────────────────────────────────────────────────────┘

What's happening:

Route53 health checks monitor both regions
If primary fails, DNS automatically routes to secondary
RDS cross-region replica keeps data in sync
Each region has its own VPC, ALB, and Auto Scaling Group

The Project Structure

day27-multi-region-ha/
├── modules/
│   ├── vpc/           # VPC, subnets, NAT gateways
│   ├── alb/           # Load balancer, target group
│   ├── asg/           # Auto Scaling, CloudWatch alarms
│   ├── rds/           # RDS instance with Multi-AZ and replicas
│   └── route53/       # DNS failover routing
├── envs/
│   └── prod/
│       ├── main.tf
│       ├── variables.tf
│       └── terraform.tfvars
├── backend.tf
└── provider.tf

Five modules, each with a single responsibility. The VPC module doesn't know about the ALB. The ALB module doesn't know about the ASG. The calling configuration wires them together.

The VPC Module (Network Foundation)

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
}

resource "aws_subnet" "public" {
  count                   = length(var.public_subnet_cidrs)
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]
}

resource "aws_nat_gateway" "main" {
  count         = length(var.public_subnet_cidrs)
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
}

Why two subnet types:

Public subnets → ALB (needs internet access)
Private subnets → EC2 instances (no direct internet access)
NAT Gateways → allow instances to download packages while remaining private

The ALB Module (Traffic Distribution)

# modules/alb/main.tf
resource "aws_lb" "web" {
  name               = "${var.name}-alb-${var.region}"
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.subnet_ids
}

resource "aws_lb_target_group" "web" {
  name     = "${var.name}-tg-${var.region}"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  health_check {
    path                = "/health"
    interval            = 30
    healthy_threshold   = 2
    unhealthy_threshold = 2
  }
}

The health check endpoint (/health) is critical — Route53 uses it to determine if the region is healthy.

The ASG Module (Auto Scaling)

# modules/asg/main.tf
resource "aws_autoscaling_group" "web" {
  min_size         = var.min_size
  max_size         = var.max_size
  desired_capacity = var.desired_capacity
  target_group_arns = var.target_group_arns
  health_check_type = "ELB"
}

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name  = "web-cpu-high-${var.environment}-${var.region}"
  threshold   = 70
  alarm_actions = [aws_autoscaling_policy.scale_out.arn]
}

The connection: target_group_arns links the ASG to the ALB. Without this, instances launch but never receive traffic.

The RDS Module (Database Tier)

# modules/rds/main.tf
resource "aws_db_instance" "main" {
  identifier   = var.identifier
  engine       = "mysql"
  instance_class = "db.t3.micro"
  multi_az     = var.multi_az
  storage_encrypted = true

  # For cross-region replica
  replicate_source_db = var.replicate_source_db
}

Multi-AZ (primary region): Synchronous replication to a standby in another AZ. Failover within minutes.

Cross-region replica (secondary region): Asynchronous replication. Used for disaster recovery, not failover.

The Route53 Module (DNS Failover)

# modules/route53/main.tf
resource "aws_route53_health_check" "primary" {
  fqdn              = var.primary_alb_dns_name
  port              = 80
  type              = "HTTP"
  resource_path     = "/health"
  failure_threshold = 3
}

resource "aws_route53_record" "primary" {
  zone_id         = var.hosted_zone_id
  name            = var.domain_name
  type            = "A"
  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.primary.id

  failover_routing_policy {
    type = "PRIMARY"
  }

  alias {
    name                   = var.primary_alb_dns_name
    zone_id                = var.primary_alb_zone_id
    evaluate_target_health = true
  }
}

How failover works:

Route53 health checks ping the ALB's /health endpoint every 30 seconds
After 3 failures (90 seconds), health check marks region as unhealthy
Route53 stops sending traffic to primary, starts sending to secondary
DNS TTL (60 seconds) + health check interval = ~2-3 minute failover

The Calling Configuration (Wiring Everything Together)

# envs/prod/main.tf
module "vpc_primary" {
  source = "../../modules/vpc"
  region = "us-east-1"
  # ... VPC config
}

module "alb_primary" {
  source = "../../modules/alb"
  vpc_id = module.vpc_primary.vpc_id
  subnet_ids = module.vpc_primary.public_subnet_ids
}

module "asg_primary" {
  source = "../../modules/asg"
  target_group_arns = [module.alb_primary.target_group_arn]
  launch_template_ami = var.primary_ami_id
}

module "rds_primary" {
  source = "../../modules/rds"
  multi_az = true
}

module "rds_replica" {
  source = "../../modules/rds"
  is_replica = true
  replicate_source_db = module.rds_primary.db_instance_arn
}

module "route53" {
  source = "../../modules/route53"
  primary_alb_dns_name = module.alb_primary.alb_dns_name
  secondary_alb_dns_name = module.alb_secondary.alb_dns_name
}

The data flow:

VPC module outputs subnet IDs
ALB module uses those to place the load balancer
ASG module uses ALB's target group ARN to register instances
RDS replica uses primary's ARN to set up replication
Route53 uses both ALB DNS names for failover

The Deployment

$ terraform apply -auto-approve

Apply complete! Resources: 19 added, 1 changed, 0 destroyed.

Outputs:
alb_url = "http://alb-us-east-1-234339925.eu-north-1.elb.amazonaws.com"

The Result

What works:

ALB distributes traffic to healthy instances
ASG maintains 2-4 instances based on CPU
CloudWatch alarms trigger scaling at 70% CPU
RDS Multi-AZ protects against AZ failure
Cross-region replica keeps secondary region in sync

What happens during a region outage:

Health checks fail (90 seconds)
Route53 stops sending traffic to primary
Traffic shifts to secondary region
Users continue accessing the application with minimal interruption

What I Learned

Multi-AZ ≠ cross-region. Multi-AZ protects against AZ failure within a region. Cross-region replicas protect against full regional outages. You need both for true high availability.

Health checks are critical. Without them, Route53 has no way to know a region is down. Every ALB needs a /health endpoint.

Modules must be focused. The VPC module shouldn't know about the ALB. The ALB module shouldn't know about the ASG. Each module does one thing well.

The calling configuration is the "glue." All the wiring happens in envs/prod/main.tf. The modules stay generic and reusable.

The Bottom Line

Component	Protects Against	Failover Time
Multi-AZ RDS	AZ failure	Minutes
Cross-region replica	Regional outage	Manual promotion
Auto Scaling Group	Instance failure	Minutes
Route53 failover	Regional outage	2-3 minutes

This is what production-grade infrastructure looks like. No single points of failure. Automatic failover. Cross-region replication.

One terraform apply. Two regions. Zero downtime.

Building a Scalable Web Application on AWS with EC2, ALB, and Auto Scaling using Terraform

Mukami — Thu, 16 Apr 2026 16:04:49 +0000

From Static Website to Dynamic, Auto-Scaling Infrastructure

Day 26 of the 30-Day Terraform Challenge — and today I graduated from static to dynamic infrastructure.

Yesterday I deployed a static website on S3 with CloudFront. Today I built something that actually thinks for itself.

A web application that grows when traffic increases and shrinks when it drops. All without human intervention. All managed through Terraform.

The Architecture

Internet → ALB (Port 80) → Auto Scaling Group → EC2 Instances (2-4)
                              ↓
                        CloudWatch Alarms
                              ↓
                    Scale Out at 70% CPU
                    Scale In at 30% CPU

Application Load Balancer distributes traffic across instances
Auto Scaling Group maintains desired instance count (2-4)
Launch Template defines instance configuration
CloudWatch Alarms trigger scaling based on CPU utilization
Three Terraform modules keep everything DRY and reusable

The Project Structure

day26-scalable-web-app/
├── modules/
│   ├── ec2/           # Launch Template + Security Group
│   ├── alb/           # Load Balancer + Target Group
│   └── asg/           # Auto Scaling Group + Scaling Policies
├── envs/
│   └── dev/
│       ├── main.tf
│       ├── variables.tf
│       └── terraform.tfvars
├── backend.tf
└── provider.tf

Each module has a single responsibility. The EC2 module doesn't know about the ALB. The ALB module doesn't know about scaling. The ASG module connects them both.

The EC2 Module (Launch Template)

# modules/ec2/main.tf
resource "aws_launch_template" "web" {
  name_prefix   = "web-lt-${var.environment}-"
  image_id      = var.ami_id
  instance_type = var.instance_type

  user_data = base64encode(<<-USERDATA
    #!/bin/bash
    yum update -y
    yum install -y httpd
    systemctl start httpd
    echo "<h1>Environment: ${var.environment}</h1>
    <p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p>" 
    > /var/www/html/index.html
  USERDATA
  )
}

The launch template defines what every instance looks like: AMI, instance type, security groups, and the user data script that runs at boot.

The ALB Module (Load Balancer)

# modules/alb/main.tf
resource "aws_lb" "web" {
  name               = "${var.name}-alb-${var.environment}"
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.subnet_ids
}

resource "aws_lb_target_group" "web" {
  name     = "${var.name}-tg-${var.environment}"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  health_check {
    path                = "/"
    healthy_threshold   = 2
    unhealthy_threshold = 2
  }
}

The ALB receives traffic and forwards it to healthy instances in the target group. The health check ensures traffic only goes to instances that actually respond.

The ASG Module (Auto Scaling)

# modules/asg/main.tf
resource "aws_autoscaling_group" "web" {
  min_size         = var.min_size
  max_size         = var.max_size
  desired_capacity = var.desired_capacity
  target_group_arns = var.target_group_arns

  launch_template {
    id      = var.launch_template_id
    version = "$Latest"
  }

  health_check_type = "ELB"
}

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name = "web-cpu-high-${var.environment}"
  threshold  = var.cpu_scale_out_threshold  # 70%
  alarm_actions = [aws_autoscaling_policy.scale_out.arn]
}

resource "aws_autoscaling_policy" "scale_out" {
  scaling_adjustment = 1
}

The ASG maintains the desired number of instances. When CPU exceeds 70%, the CloudWatch alarm triggers the scale-out policy, adding one instance. When CPU drops below 30%, it scales in.

How Modules Collaborate

module.ec2 (Launch Template ID) ──► module.asg
                                      │
module.alb (Target Group ARN) ──────► module.asg

The calling configuration wires everything together:

# envs/dev/main.tf
module "ec2" {
  source      = "../../modules/ec2"
  ami_id      = var.ami_id
  environment = var.environment
}

module "alb" {
  source      = "../../modules/alb"
  name        = var.app_name
  vpc_id      = var.vpc_id
  subnet_ids  = var.public_subnet_ids
}

module "asg" {
  source             = "../../modules/asg"
  launch_template_id = module.ec2.launch_template_id
  target_group_arns  = [module.alb.target_group_arn]
  min_size           = 1
  max_size           = 4
  desired_capacity   = 2
}

The target_group_arns input is critical. Without it, instances would launch but never receive traffic. The ALB wouldn't know they exist.

The Deployment

$ terraform apply -auto-approve

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

Outputs:
alb_url = "http://web-challenge-day26-alb-dev-1419490799.eu-north-1.elb.amazonaws.com"

The Result

ALB URL: http://web-challenge-day26-alb-dev-1419490799.eu-north-1.elb.amazonaws.com

What you see:

Scalable Web App — Environment: dev
Instance ID: i-0abcd1234efgh5678
Deployed with Terraform on Day 26!

What happens behind the scenes:

2 instances initially (desired_capacity = 2)
When CPU hits 70%, CloudWatch triggers scale-out → 3 instances
When CPU drops to 30%, scale-in triggers → back to 2 instances

Why This Matters

Before: A single EC2 instance. If it crashes, the site goes down. If traffic spikes, users see errors.

After: Auto Scaling Group with 2-4 instances. If one crashes, the ASG replaces it. If traffic spikes, the ASG adds capacity automatically.

The business value: You don't over-provision (paying for idle servers) and you don't under-provision (losing users during spikes).

What I Learned

Module composition > monolithic config. Three small modules are easier to understand, test, and reuse than one giant file.

health_check_type = "ELB" is critical. Without it, the ASG only checks if the EC2 instance is running, not if the application is responding.

CloudWatch alarms + scaling policies = auto-scaling. The alarm detects the condition. The policy executes the action.

The target group is the bridge. The ALB sends traffic to the target group. The ASG registers instances with the target group. Without this connection, nothing works.

Clean Up

terraform destroy -auto-approve

Always destroy test infrastructure to avoid unexpected AWS charges.

The Bottom Line

Today I built infrastructure that adapts to traffic. No manual scaling. No over-provisioning. No downtime during spikes.

Three modules working together: EC2 for instance configuration, ALB for traffic distribution, ASG for scaling.

This is what production-grade infrastructure looks like.

P.S. The moment I saw CloudWatch trigger a scale-out and a new instance appear in the target group, I understood why teams love auto scaling. It's not magic. It's just well-designed infrastructure.

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.

DEV Community: Mukami

Ready for Terraform Certification: My Final Exam Prep and 30-Day Reflection

Five Practice Exams. 30 Days. 1,247 Lines of HCL. Zero Sanity Left.

Practice Exam 5: The Final Boss

Five-Exam Score Summary

Fill-in-the-Blank Results

Final Readiness Check (The "Can I Actually Do This?" Test)

30-Day Reflection (The Therapy Session)

What changed?

What am I most proud of?

What comes next?

Exam Logistics

Closing Message to the Future Participant

The Bottom Line (In Numbers)

Fine-tuning My Terraform Exam Prep with Practice Exams

Four Exams. 228 Questions. One Clear Picture.

The Four-Exam Score Trend

Persistent Wrong-Answer Topics

1. terraform state rm vs terraform destroy

2. terraform plan -target includes dependencies

3. terraform apply -refresh-only

4. Sentinel policy execution timing

5. Provider version constraint ~> 1.0.0

6. Workspace behaviour

Hands-On Exercises to Close the Gaps

Exercise 1: State Commands

Exercise 2: Workspace Practice

Exercise 3: Provider Version Constraints

Final Study Priority List (Day 30)

What I Learned

The Bottom Line

How I Prepared for the Terraform Associate Exam with Practice Questions

Two Practice Exams. 114 Questions. Zero Looking Up Answers.

The Scores

Domain Accuracy Breakdown

Wrong-Answer Analysis

Question 1

Question 2

Question 3

Question 4

Question 5

Hands-On Revision for Weak Areas

Domain: Terraform CLI

Domain: State Management

Domain: Terraform Cloud

Pattern Recognition

Plan for Days 29 and 30

What I Learned

The Bottom Line

Building a 3-Tier Multi-Region High Availability Architecture with Terraform

From Single Region to Production-Grade Global Infrastructure

The Architecture

The Project Structure

The VPC Module (Network Foundation)

The ALB Module (Traffic Distribution)

The ASG Module (Auto Scaling)

The RDS Module (Database Tier)

The Route53 Module (DNS Failover)

The Calling Configuration (Wiring Everything Together)

The Deployment

The Result

What I Learned

The Bottom Line

Building a Scalable Web Application on AWS with EC2, ALB, and Auto Scaling using Terraform

From Static Website to Dynamic, Auto-Scaling Infrastructure

The Architecture

The Project Structure

The EC2 Module (Launch Template)

The ALB Module (Load Balancer)

The ASG Module (Auto Scaling)

How Modules Collaborate

The Deployment

The Result

Why This Matters

What I Learned

Clean Up

The Bottom Line

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

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

What I Built

1. `terraform state rm` vs `terraform destroy`

2. `terraform plan -target` includes dependencies

3. `terraform apply -refresh-only`

5. Provider version constraint `~> 1.0.0`