DEV Community: Mukami

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. 🔒

How to Handle Sensitive Data Securely in Terraform

Mukami — Sat, 28 Mar 2026 13:15:59 +0000

The Three Ways Secrets Leak (And How to Stop Every One)

Day 13 of the 30-Day Terraform Challenge — and today I learned that even when you think your secrets are safe, they're probably not.

Secrets leak in Terraform in three predictable ways. I found all three. I fixed all three. And I documented what I learned so you don't have to make the same mistakes.

The Three Leak Paths

Leak Path 1: Hardcoded in .tf Files

The mistake:

resource "aws_db_instance" "example" {
  username = "admin"
  password = "super-secret-password"  # ❌
}

This password is now in your Git history. Forever. Even if you delete it, it's still in the commit history. Anyone with access to your repo can see it.

The fix:

variable "db_password" {
  type      = string
  sensitive = true
  # No default — Terraform will prompt
}

Now the password never touches your code.

Leak Path 2: Variable Defaults

The mistake:

variable "db_password" {
  default = "super-secret-password"  # ❌ Still in code
}

Default values are stored in your .tf files. Same problem as hardcoding. The secret is right there in version control.

The fix: No defaults for secrets. Ever.

Leak Path 3: The State File

The reality: Even if you fix the first two, Terraform stores every resource attribute in terraform.tfstate in plaintext.

$ cat terraform.tfstate | grep password
"password": "MySecurePassword123!"  # ❌ Right there!

Anyone with read access to the state file can see all your secrets.

The fix:

Use remote state with encryption (S3 + encrypt = true)
Restrict access with IAM policies
Never commit state to Git
Enable versioning to recover from mistakes

AWS Secrets Manager: The Right Way

Instead of hardcoding, store secrets in AWS Secrets Manager:

data "aws_secretsmanager_secret" "db_credentials" {
  name = "prod/db/credentials"
}

data "aws_secretsmanager_secret_version" "db_credentials" {
  secret_id = data.aws_secretsmanager_secret.db_credentials.id
}

locals {
  db_credentials = jsondecode(
    data.aws_secretsmanager_secret_version.db_credentials.secret_string
  )
}

resource "aws_db_instance" "example" {
  username = local.db_credentials["username"]
  password = local.db_credentials["password"]
}

What this gives you:

✅ Secrets never appear in your .tf files
✅ Fetched at runtime
✅ Centralized secret management
✅ Rotation capabilities

Marking Secrets as Sensitive

Terraform's sensitive = true prevents secrets from appearing in terminal output:

output "db_password" {
  value     = local.db_credentials["password"]
  sensitive = true
}

Plan output:

db_password = <sensitive>

⚠️ Important: This does NOT prevent secrets from being stored in state. It only hides them from the terminal.

State File Security Checklist

After deploying, I verified all of these:

✅ S3 backend with encryption:

terraform {
  backend "s3" {
    bucket  = "my-terraform-state"
    encrypt = true  # AES-256 encryption
  }
}

✅ Block public access on S3 bucket

✅ Enable versioning to recover from mistakes

✅ Restrict IAM policy to only Terraform runners

✅ .gitignore to prevent accidental commits:

.terraform/
*.tfstate
*.tfstate.backup
*.tfvars

What the Plan Looked Like

When I ran terraform plan, the output showed:

username = (sensitive value)
password = (sensitive value)
db_password = (sensitive value)

The actual secrets never appeared in my terminal. But when I checked the state file:

$ cat terraform.tfstate | grep password
"password": "MySecurePassword123!"

The password was right there in plaintext. This was the "aha!" moment — state encryption isn't optional. It's mandatory.

Chapter 6 Learnings

Does sensitive = true prevent secrets from being stored in state?
No. It only hides them from terminal output. Secrets are still in state. You must secure the state file.

Vault vs Secrets Manager:

AWS Secrets Manager: AWS-native, simpler, good for AWS-only environments, integrates with RDS
HashiCorp Vault: Multi-cloud, dynamic secrets, fine-grained policies, more complex to set up

Why secrets appear in state: Terraform stores all resource attributes to track infrastructure. The only solution is to secure the state file itself with encryption and access controls.

What I Learned

Secrets management isn't just about not hardcoding passwords. It's about:

Using a secrets manager — AWS Secrets Manager, HashiCorp Vault
Never hardcoding — no passwords in .tf files, no defaults
Marking sensitive outputs — sensitive = true hides from terminal
Securing the state file — encrypted S3 backend, restricted access
Proper .gitignore — never commit state or tfvars

The state file is the last line of defence. Secure it like you would a password manager.

My .gitignore

# Terraform
.terraform/
.terraform.lock.hcl
*.tfstate
*.tfstate.backup
*.tfvars
*.tfvars.json

# Local secrets
*.secret
secrets.tfvars

# Environment
.env
.env.local

The Bottom Line

Three leak paths. Three fixes:

Leak Path	Fix
Hardcoded in .tf	Use variables with `sensitive = true`
Variable defaults	Remove defaults, use Secrets Manager
State file	Encrypted remote backend, restricted access

Security isn't optional in production infrastructure.

Resources:

P.S. The moment I saw my password in the state file was humbling. No matter how careful you are with your code, if you don't secure your state, you're leaving secrets in plain sight.

Mastering Zero-Downtime Deployments with Terraform

Mukami — Sat, 28 Mar 2026 11:58:27 +0000

How I Updated Production Without Taking My App Offline (Almost)

Day 12 of the 30-Day Terraform Challenge — and today I learned the difference between "it works" and "it works without anyone noticing."

Deploying infrastructure updates without downtime is one of the hardest problems in operations. It's also one of the most valuable skills you can have. Today I made it happen.

Well, almost. Let me show you what worked, what broke, and what I learned.

The Problem: Terraform's Default Behavior is Destructive

When you update a Launch Template or Auto Scaling Group, Terraform does something terrifying by default:

1. Destroy old ASG → All instances terminate → Website goes down ❌
2. Create new ASG → New instances spin up → Website comes back

Between step 1 and step 2, there's a window of silence. Sometimes seconds. Sometimes minutes. In production, that's a disaster.

The fix? A little lifecycle rule called create_before_destroy.

The Solution: create_before_destroy

This simple lifecycle block flips the order:

lifecycle {
  create_before_destroy = true
}

Instead of destroy → create, it does:

1. Create new resources
2. Wait for them to be healthy
3. Destroy old resources

No gap. No downtime.

The ASG Naming Problem

There's a catch. AWS won't let two Auto Scaling Groups have the same name. When create_before_destroy creates the new ASG before destroying the old one, they'd both have the same name and Terraform would error.

The fix: Use name_prefix instead of a fixed name:

name_prefix = "web-asg-${random_id.asg.hex}-"

Add a random_id that changes when your code changes:

resource "random_id" "asg" {
  keepers = {
    # New ID when user_data changes
    user_data = base64encode(file("${path.module}/user-data.sh"))
  }
  byte_length = 4
}

Now each deployment gets a unique name. Problem solved.

The Test: Updating from v1 to v2

I set up a traffic monitor in one terminal:

while true; do
  curl http://my-alb-dns-name
  sleep 2
done

In another terminal, I updated my user_data script and ran terraform apply.

Here's what happened:

<h1>Version 1: Hello World!</h1> - 14:34:04
<h1>Version 1: Hello World!</h1> - 14:34:06
<h1>Version 1: Hello World!</h1> - 14:34:08
...
502 Bad Gateway - 14:35:08    # Uh oh!
502 Bad Gateway - 14:35:10
502 Bad Gateway - 14:35:12
...
<h1>Version 2: Updated! Zero Downtime Works!</h1> - 14:35:25
<h1>Version 2: Updated! Zero Downtime Works!</h1> - 14:35:27

What happened? I got 17 seconds of 502 errors. Not quite zero downtime.

Why Did I Get Errors?

The new instances took longer to become healthy than the old instances took to terminate. The ALB had no healthy targets for a brief window.

The fix: Increase health_check_grace_period and add wait_for_capacity_timeout:

resource "aws_autoscaling_group" "web" {
  health_check_grace_period = 300   # 5 minutes to boot
  wait_for_capacity_timeout = "10m" # Wait for healthy instances

  lifecycle {
    create_before_destroy = true
  }
}

With these settings, Terraform waits until the new instances pass health checks before destroying the old ones. No more 502s.

The Blue/Green Alternative

create_before_destroy is great, but it has limitations. For mission-critical apps, teams use blue/green deployments:

Blue = current live environment
Green = new version, ready to go

Switch traffic instantly with a listener rule:

resource "aws_lb_listener_rule" "blue_green" {
  action {
    type = "forward"
    target_group_arn = var.active_environment == "blue" ? 
      aws_lb_target_group.blue.arn : aws_lb_target_group.green.arn
  }
}

Change active_environment = "green", run terraform apply, and traffic switches in a single API call. Zero downtime. Instant rollback.

What I Learned

The default is dangerous. Never assume Terraform will keep your app online. Always test.

create_before_destroy is your friend. But you need to handle ASG naming with name_prefix and random_id.

Health checks matter. Give your instances time to boot. health_check_grace_period = 300 is your safety net.

Blue/green is cleaner. More setup, but atomic switches and instant rollbacks.

502s taught me more than success would have. I saw exactly where my setup failed and how to fix it.

The Code That Worked

# Unique ASG name
resource "random_id" "asg" {
  keepers = { user_data = base64encode(file("user-data.sh")) }
  byte_length = 4
}

resource "aws_autoscaling_group" "web" {
  name_prefix = "web-asg-${random_id.asg.hex}-"
  health_check_grace_period = 300
  wait_for_capacity_timeout = "10m"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_launch_template" "web" {
  lifecycle {
    create_before_destroy = true
  }
}

The Bottom Line

Zero-downtime deployments aren't magic. They're a combination of:

The right lifecycle rules (create_before_destroy)
Smart naming (name_prefix + random_id)
Patience (health_check_grace_period, wait_for_capacity_timeout)
The right strategy (blue/green for critical apps)

Today I learned that "it works" isn't enough. It has to work when nobody's watching. And now I know how to make that happen.

P.S. Those 502 errors were humbling. But they taught me more than a perfect run ever would. Sometimes failure is the best teacher.

How Conditionals Make Terraform Infrastructure Dynamic and Efficient

Mukami — Fri, 27 Mar 2026 13:26:35 +0000

One Module, Two Environments, Zero Code Duplication

Day 11 of the 30-Day Terraform Challenge — and today I learned that conditionals are the secret sauce that turns a rigid configuration into a flexible, environment-aware system.

Yesterday I had a module that worked for dev. Today I have a module that works for dev, staging, AND production — all from the same codebase.

No copy-pasting. No separate branches. Just one environment variable driving everything.

The Problem: Hardcoded Values for Every Environment

Before today, if I wanted different instance sizes for dev and production, I had to:

# dev/main.tf
instance_type = "t3.micro"
min_size = 1
max_size = 3

# production/main.tf
instance_type = "t3.medium"
min_size = 3
max_size = 10

Same code. Different files. Change something? Update both places. Forget one? Inconsistent infrastructure.

This works until you have 5 environments. Then it becomes a maintenance nightmare.

The Solution: Centralized Conditional Logic with Locals

Instead of scattering ? : operators everywhere, I put all my conditional decisions in one place:

locals {
  # Environment checks
  is_production = var.environment == "production"
  is_staging    = var.environment == "staging"
  is_dev        = var.environment == "dev"

  # Compute sizing based on environment
  instance_type = local.is_production ? "t3.medium" : (
    local.is_staging ? "t3.small" : "t3.micro"
  )

  # Auto Scaling settings
  min_size = local.is_production ? 3 : (
    local.is_staging ? 2 : 1
  )

  max_size = local.is_production ? 10 : (
    local.is_staging ? 5 : 3
  )

  # Feature toggles
  enable_autoscaling = !local.is_dev        # Enabled for staging and production
  enable_detailed_monitoring = local.is_production
  enable_ssh = !local.is_production         # Disabled in production
  deletion_protection = local.is_production
}

Why this is better:

All logic in one place — easy to see what changes per environment
No scattered ternaries through resource arguments
Easy to test — change one variable, see all impacts
Easy to maintain — add a new environment? Update one block

Conditional Resource Creation with `count`

The count = condition ? 1 : 0 pattern makes entire resources optional:

# Only create autoscaling policies for staging and production
resource "aws_autoscaling_policy" "scale_out" {
  count = local.enable_autoscaling ? 1 : 0

  name                   = "${var.cluster_name}-scale-out"
  scaling_adjustment     = 1
  autoscaling_group_name = aws_autoscaling_group.web.name
}

# Only create CloudWatch alarms for production
resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  count = local.enable_detailed_monitoring ? 1 : 0

  alarm_name = "${var.cluster_name}-high-cpu"
  threshold  = 80
}

When enable_autoscaling = false, the policy isn't created at all. No resources. No costs.

Safe Output References

When resources are conditional, you can't reference them directly. This fails when count = 0:

# BROKEN — errors when resource doesn't exist
output "alarm_arn" {
  value = aws_cloudwatch_metric_alarm.high_cpu[0].arn
}

The fix is a ternary guard:

# CORRECT — returns null when resource doesn't exist
output "alarm_arn" {
  value = local.enable_detailed_monitoring ? 
    aws_cloudwatch_metric_alarm.high_cpu[0].arn : null
}

For outputs that return objects:

output "autoscaling_policies" {
  value = local.enable_autoscaling ? {
    scale_out = aws_autoscaling_policy.scale_out[0].name
    scale_in  = aws_autoscaling_policy.scale_in[0].name
  } : {}
}

Without this guard, Terraform throws Invalid index errors when the resource doesn't exist.

The Validation Block: Catch Mistakes Early

Add a validation block to prevent invalid inputs:

variable "environment" {
  description = "Deployment environment: dev, staging, or production"
  type        = string
  default     = "dev"

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

Try to pass an invalid value:

terraform plan -var="environment=stg"

│ Error: Invalid value for variable
│ Environment must be one of: dev, staging, production.

Caught at plan time — before anything is deployed.

The Results: Dev vs Production

Same module. Same code. Different outputs.

Dev Environment:

instance_type = "t3.micro"
min_size = 1
max_size = 3
enable_autoscaling = false
enable_monitoring = false
enable_ssh = true
autoscaling_policies = {}

Production Environment:

instance_type = "t3.medium"
min_size = 3
max_size = 10
enable_autoscaling = true
enable_monitoring = true
enable_ssh = false
autoscaling_policies = {
  scale_in = "prod-webserver-scale-in"
  scale_out = "prod-webserver-scale-out"
}

Dev gets small, cheap, debuggable. Production gets big, scalable, secure. All from one module.

The Conditional Data Source Pattern

Sometimes you need to either create new infrastructure or use existing. This pattern handles both:

variable "use_existing_vpc" {
  type    = bool
  default = false
}

# Conditionally look up existing VPC
data "aws_vpc" "existing" {
  count = var.use_existing_vpc ? 1 : 0
  id    = var.existing_vpc_id
}

# Conditionally create new VPC
resource "aws_vpc" "new" {
  count = var.use_existing_vpc ? 0 : 1
  cidr_block = "10.0.0.0/16"
}

locals {
  vpc_id = var.use_existing_vpc ? data.aws_vpc.existing[0].id : aws_vpc.new[0].id
}

This enables:

Greenfield deployments — create everything new
Brownfield deployments — use existing infrastructure

One toggle switches between them.

What I Learned

Conditional expressions choose values. They answer "what should this be?"

Conditional resource creation chooses existence. It answers "should this exist at all?"

You can't directly choose between two resource types with one conditional. You need two resources with count on each.

Locals are better than scattered ternaries. Centralize your logic. Future you will thank you.

Validation blocks are your first line of defense. Catch invalid inputs before they cause damage.

The Bottom Line

Today I transformed my module from hardcoded values to a single environment variable that drives everything:

Instance sizing (t3.micro → t3.medium)
Cluster size (1 → 3 → 10 instances)
Feature toggles (autoscaling, monitoring, SSH)
Protection settings (deletion protection)

One codebase. Multiple environments. Zero duplication.

This is how infrastructure at scale works.

P.S. The best part? When someone asks "what does dev look like vs production?" I just point to my locals block. Everything is there. One place. No hunting through 500 lines of code.

Mastering Loops and Conditionals in Terraform

Mukami — Fri, 27 Mar 2026 11:51:38 +0000

Day 10 of the 30-Day Terraform Challenge — and today I learned that Terraform is actually a programming language in disguise.

For the past 9 days, I've been writing infrastructure like it's 2010: one resource at a time, copy-pasting blocks, and feeling clever when I only duplicated code three times instead of five.

Today I discovered loops and conditionals. And I'm never going back.

The Problem: Copy-Paste Engineering

Let me show you what I was doing before today:

# Creating 3 users? Copy-paste!
resource "aws_iam_user" "alice" { name = "alice" }
resource "aws_iam_user" "bob"   { name = "bob" }
resource "aws_iam_user" "charlie" { name = "charlie" }

# Security group with 3 rules? Copy-paste!
ingress { from_port = 80 }
ingress { from_port = 443 }
ingress { from_port = 22 }

This works. Until you need 10 users. Or 50 security group rules. Or you need to change something across all of them.

There had to be a better way.

There is.

Tool 1: `count` — The Simple Loop

count creates multiple copies of a resource. Think of it as a for-loop for infrastructure.

# Create 3 identical IAM users
resource "aws_iam_user" "users" {
  count = 3
  name  = "user-${count.index}"
}

count.index gives you the position (0, 1, 2). This creates:

user-0
user-1
user-2

You can also use it with a list:

variable "user_names" {
  default = ["alice", "bob", "charlie"]
}

resource "aws_iam_user" "users" {
  count = length(var.user_names)
  name  = var.user_names[count.index]
}

The Problem Nobody Warns You About

Here's where count gets dangerous.

Imagine your user list: ["alice", "bob", "charlie"]

Terraform tracks resources by their index position:

Index 0 = alice
Index 1 = bob
Index 2 = charlie

Now you remove "alice" from the list: ["bob", "charlie"]

The list shifts:

Index 0 = bob (was alice!)
Index 1 = charlie (was bob!)

What Terraform sees: Index 0 changed from alice to bob → destroy alice, create bob. Index 1 changed from bob to charlie → destroy bob, create charlie.

Bob and Charlie get destroyed and recreated even though they still exist. Any data, IPs, or attached resources are lost.

This is the count trap. It's subtle, destructive, and catches everyone once.

Tool 2: `for_each` — The Safe Loop

for_each solves the index problem by using keys instead of positions.

# Using a set
variable "user_names" {
  type    = set(string)
  default = ["alice", "bob", "charlie"]
}

resource "aws_iam_user" "users" {
  for_each = var.user_names
  name     = each.value
}

Now Terraform tracks resources by their value (alice, bob, charlie), not their position.

Remove "alice" from the set? Only Alice is destroyed. Bob and Charlie stay exactly where they are.

The Power of Maps

Where for_each really shines is with maps, because you can carry extra configuration per item:

variable "users" {
  type = map(object({
    department = string
    admin      = bool
  }))
  default = {
    alice = { department = "engineering", admin = true }
    bob   = { department = "marketing",   admin = false }
  }
}

resource "aws_iam_user" "users" {
  for_each = var.users
  name     = each.key

  tags = {
    Department = each.value.department
    Admin      = tostring(each.value.admin)
  }
}

Now each user gets unique tags based on their configuration. Try doing that with count.

Tool 3: `for` Expressions — Transform Data Without Creating Resources

for expressions reshape data. They don't create infrastructure—they transform what you already have.

# Uppercase all names
output "upper_names" {
  value = [for name in var.user_names : upper(name)]
}
# ["ALICE", "BOB", "CHARLIE"]

# Create a map from a list
output "user_map" {
  value = { for idx, name in var.user_names : idx => name }
}
# { "0" = "alice", "1" = "bob", "2" = "charlie" }

# Filter and transform
output "admin_users" {
  value = {
    for name, user in aws_iam_user.users : name => user.arn
    if user.admin == true
  }
}
# Only admin users appear in the output

These are incredibly useful for creating clean outputs that other configurations can consume.

Tool 4: Ternary Conditionals — Make Decisions

The ternary operator is Terraform's if/else:

condition ? true_value : false_value

Making Resources Optional

variable "enable_autoscaling" {
  type    = bool
  default = true
}

resource "aws_autoscaling_policy" "scale_out" {
  count = var.enable_autoscaling ? 1 : 0
  # ... policy configuration
}

When enable_autoscaling = false, count becomes 0 and the policy is never created.

Environment-Specific Configuration

variable "environment" {
  type    = string
  default = "dev"
}

locals {
  instance_type = var.environment == "production" ? "t3.medium" : "t3.micro"

  extra_tags = var.environment == "production" ? {
    Criticality = "high"
    Backup      = "enabled"
  } : {}
}

Now you have one codebase that works for dev (small, cheap) and production (big, protected).

Putting It All Together

Here's how I refactored my web server cluster module:

Before: Hardcoded security group rules, no autoscaling options, repetitive outputs.

After:

# Optional autoscaling policies
resource "aws_autoscaling_policy" "scale_out" {
  count = var.enable_autoscaling ? 1 : 0
  name  = "${var.cluster_name}-scale-out"
  autoscaling_group_name = aws_autoscaling_group.web.name
  scaling_adjustment = 1
}

# Flexible security group rules
resource "aws_security_group_rule" "additional" {
  for_each = var.additional_sg_rules

  type              = "ingress"
  from_port         = each.value.from_port
  to_port           = each.value.to_port
  security_group_id = aws_security_group.instance.id
}

# Clean outputs
output "autoscaling_policies" {
  value = var.enable_autoscaling ? {
    scale_out = aws_autoscaling_policy.scale_out[0].name
  } : {}
}

When to Use What: The Cheat Sheet

Tool	Best For	Avoid When
count	Identical resources, fixed numbers	Lists that might change order
for_each	Resources with unique identities, maps, changing lists	Creating thousands of resources (state file gets huge)
for expressions	Data transformation, outputs, locals	Creating actual infrastructure
ternary	Simple conditional values, resource toggles	Complex nested logic (use locals instead)

The Count Trap: A Real Example

I built a simple IAM user setup with count. It worked perfectly. Then I removed a user from the middle of the list. terraform plan showed that every user after that position would be recreated.

I tested with random IDs attached to each user. After removing one, the IDs of remaining users changed. They were destroyed and recreated.

The cost? If these were EC2 instances, I'd lose their IPs, attached volumes, and any stateful data. If these were databases, I'd lose data.

The fix? I refactored to use for_each. Now removing any user affects only that user.

What I Learned

Loops eliminate repetition. One block now does the work of ten.

count is simple but dangerous. It works until your list changes. Then it breaks things in ways that are hard to debug.

for_each is safer. It respects identity, not position. Use it whenever your resources have unique names.

Conditionals make code reusable. One module now serves dev and production, with features that turn on and off based on variables.

for expressions are the glue. They transform raw resources into clean outputs that others can consume.

The Bottom Line

Before today, I wrote infrastructure by copy-pasting. Now I write it with loops and conditionals.

My code is:

Shorter — 200 lines instead of 500
Safer — removing items doesn't break everything
Smarter — dev gets small instances, production gets big ones
More maintainable — change one place, all environments update

Terraform isn't just a tool for creating resources. It's a language for describing infrastructure. And today, I finally started treating it like one.

P.S. If you're still writing 10 separate resource blocks for 10 similar resources, stop. Learn for_each. Your future self will thank you.

Advanced Terraform Module Usage: Versioning, Gotchas, and Reuse Across Environments

Mukami — Thu, 26 Mar 2026 09:41:09 +0000

Day 9 of the 30-Day Terraform Challenge — and today I learned the hard-won lessons that separate "I know how to write a module" from "I can safely share modules with a team."

Yesterday I built my first module. Today I learned why modules break in production, how to version them like real software, and why pinning versions is the difference between "it works" and "it works every time, for everyone."

The Problem: Modules Aren't Magic

Yesterday's module worked perfectly when I called it from a local path. But the moment I tried to share it? Things got messy.

Three gotchas caught me off guard:

Gotcha 1: File Paths Lie to You

I had a user data script in my module:

user_data = file("user-data.sh")

Worked fine when testing locally. Then I called the module from a different directory:

Error: Error reading file "user-data.sh": no such file or directory

The problem: file() resolves paths relative to where Terraform is run, not relative to the module!

The fix: Always use ${path.module}:

user_data = file("${path.module}/user-data.sh")

Now the path is always correct, no matter who calls the module or from where.

Gotcha 2: Inline Blocks vs Separate Resources

My security group had inline ingress rules:

resource "aws_security_group" "instance" {
  ingress {
    from_port = 80
    to_port   = 80
  }
}

This worked fine. But when someone using my module wanted to add another rule? They couldn't. The module controlled everything.

The fix: Use separate security group rule resources:

resource "aws_security_group" "instance" {
  # No inline rules!
}

resource "aws_security_group_rule" "allow_http" {
  security_group_id = aws_security_group.instance.id
  from_port = 80
  to_port = 80
}

Now callers can add their own rules without modifying the module. The module provides a foundation; they add the customization.

Gotcha 3: Module Outputs Create Hidden Dependencies

I had a resource that needed to wait for the module:

resource "aws_instance" "monitoring" {
  depends_on = [module.webserver_cluster]
}

Looks fine, right? Wrong.

This depends_on creates a dependency on every resource inside the module. If any resource in the module changes, Terraform recreates my monitoring instance — even if it wasn't related.

The fix: Depend on specific outputs:

resource "aws_instance" "monitoring" {
  depends_on = [module.webserver_cluster.alb_dns_name]
}

Now my monitoring instance only cares if the ALB DNS changes — not if a tag on a random instance changes.

The Solution: Version Your Modules

Once I fixed the gotchas, I needed to share my module safely. The answer: versioning.

Step 1: Push to GitHub

git init
git add .
git commit -m "Initial module release"
git remote add origin https://github.com/123Origami/terraform-aws-webserver-cluster.git
git push origin main

Step 2: Tag a Version

git tag -a "v0.0.1" -m "First release: Basic web server cluster"
git push origin main --tags

Now my module is versioned! Anyone can use it with:

module "webserver_cluster" {
  source = "github.com/123Origami/terraform-aws-webserver-cluster?ref=v0.0.1"
}

Step 3: Make a Change, Tag New Version

I added a new feature (custom_user_data), committed it, and:

git tag -a "v0.0.2" -m "Added custom user data support"
git push origin main --tags

Now I have two versions:

v0.0.1 — stable, production-ready
v0.0.2 — new feature, needs testing

The Pattern: Dev Tests, Production Pins

This is where it gets good.

Dev environment uses v0.0.2:

# live/dev/services/webserver-cluster/main.tf
module "webserver_cluster" {
  source = "github.com/123Origami/terraform-aws-webserver-cluster?ref=v0.0.2"

  cluster_name  = "webservers-dev"
  instance_type = "t3.micro"
  custom_user_data = file("${path.module}/dev-setup.sh")
}

Production stays on v0.0.1:

# live/production/services/webserver-cluster/main.tf
module "webserver_cluster" {
  source = "github.com/123Origami/terraform-aws-webserver-cluster?ref=v0.0.1"

  cluster_name  = "webservers-production"
  instance_type = "t3.medium"
}

Why this pattern:

Dev tests the new version immediately
Production stays stable until I validate v0.0.2 in dev
When I'm confident, I update production to v0.0.2
If something breaks, I roll back to v0.0.1 in seconds

The terraform init Magic

When I run terraform init in dev:

Initializing modules...
Downloading git::https://github.com/123Origami/terraform-aws-webserver-cluster.git?ref=v0.0.2

Production downloads v0.0.1:

Initializing modules...
Downloading git::https://github.com/123Origami/terraform-aws-webserver-cluster.git?ref=v0.0.1

Same module. Different versions. Different environments. This is how real teams work.

Why Version Pinning Is Non-Negotiable

Imagine this nightmare:

Engineer A runs terraform apply at 9:00 AM — downloads module at v0.0.1, everything works.

Engineer B runs terraform apply at 10:00 AM — module source has been updated to v0.0.2 (new feature, breaking change). Infrastructure now inconsistent.

No one knows why. "It worked on my machine" becomes "it worked in my apply."

Without version pinning, you're gambling.

The Module README: Your Contract with Users

Every shared module needs a README. It's not optional. Here's what I included:

# AWS Web Server Cluster Module

## What it does
Creates a highly available web server cluster with ALB and ASG.

## Usage
module "webserver_cluster" {
  source = "github.com/your-username/terraform-aws-webserver-cluster?ref=v0.0.1"
  cluster_name = "my-app"
}

## Inputs
| Name | Type | Default | Required |
|------|------|---------|----------|
| cluster_name | string | - | yes |
| instance_type | string | t3.micro | no |
| min_size | number | 1 | no |

## Outputs
| Name | Description |
|------|-------------|
| alb_url | URL to access the cluster |
| asg_name | Name of the Auto Scaling Group |

## Known Gotchas
- Use `${path.module}` for any file paths inside the module
- Security group rules are separate resources for flexibility

A good README means users don't have to read your code to use it.

What I Learned

The gotchas are subtle but deadly. File paths, dependency chains, and inline resources — all of them work fine until they don't. Fix them once, in the module, and everyone benefits.

Versioning is how modules become trustworthy. Without a version pin, you're sharing a moving target. With versioning, you're sharing a contract.

The dev-test-prod pattern is simple but powerful. Test new versions in dev. Let them bake. When they're stable, roll to staging, then production. If something breaks, roll back one version.

The Bottom Line

A module without versioning is just a folder of code. A module with versioning is a tool your whole team can rely on.

Today I turned my web server module from a personal convenience into something I could share with anyone, anywhere, with confidence.

Version your modules. Pin your versions. Test in dev, trust in prod.

Resources:

# Building Reusable Infrastructure with Terraform Modules ## Or: How I Finally Stopped Copy-Pasting the Same 200 Lines of Code

Mukami — Thu, 26 Mar 2026 08:36:19 +0000

Day 8 of the 30-Day Terraform Challenge — and today I learned the secret that separates people who "know Terraform" from people who actually build infrastructure at scale.

Modules.

You know that feeling when you've written the same security group configuration three times? Or when you're about to copy-paste your entire web server cluster for the fifth environment? That's the feeling modules were made to eliminate.

The Problem: Copy-Paste Engineering

Let me show you what I was doing before today:

# dev/main.tf
resource "aws_lb" "web" {
  name = "dev-web-alb"
  # ... 200 more lines ...
}

# staging/main.tf  
resource "aws_lb" "web" {
  name = "staging-web-alb"
  # ... THE SAME 200 lines, different name ...
}

# production/main.tf
resource "aws_lb" "web" {
  name = "prod-web-alb"
  # ... 200 lines, again ...
}

This is what we call Copy-Paste Engineering. It's fast. It works. And it's a nightmare to maintain.

Change the health check path? That's 3 files. Fix a security group rule? 3 files. Update the AMI filter? You guessed it — 3 files. And if you forget one? Now dev and production are different, and nobody knows why.

There had to be a better way.

The Solution: Modules

A module is just a folder of Terraform code that you can call from other Terraform configurations. That's it. No magic. No special syntax.

But that simple concept changes everything.

The Module Structure

Here's what I built today:

modules/
└── services/
    └── webserver-cluster/
        ├── main.tf          # The infrastructure (ALB, ASG, SG)
        ├── variables.tf     # What you can configure
        ├── outputs.tf       # What you get back
        └── README.md        # How to use it

The Variables (What You Can Configure)

variable "cluster_name" {
  description = "Name for all cluster resources"
  type        = string
  # No default — caller MUST provide this
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

variable "min_size" {
  description = "Minimum instances in ASG"
  type        = number
  default     = 1
}

variable "max_size" {
  description = "Maximum instances in ASG"
  type        = number
  default     = 5
}

variable "environment" {
  description = "Environment name (dev, staging, prod)"
  type        = string
  default     = "dev"
}

Every configurable aspect of the infrastructure is an input variable. Nothing is hardcoded.

The Outputs (What You Get Back)

output "alb_dns_name" {
  description = "DNS name of the load balancer"
  value       = aws_lb.web.dns_name
}

output "alb_url" {
  description = "Full URL to access the cluster"
  value       = "http://${aws_lb.web.dns_name}"
}

output "asg_name" {
  description = "Name of the Auto Scaling Group"
  value       = aws_autoscaling_group.web.name
}

Callers get back exactly what they need — no more, no less.

The Main File (The Infrastructure)

Inside main.tf is all the code I've been writing all week. But now it uses variables instead of hardcoded values:

resource "aws_lb" "web" {
  name = "${var.cluster_name}-alb"  # No hardcoding!
  security_groups = [aws_security_group.alb.id]
  subnets = data.aws_subnets.default.ids
}

The Magic: Calling the Module

Here's where it gets beautiful. For dev:

# live/dev/services/webserver-cluster/main.tf

module "webserver_cluster" {
  source = "../../../../modules/services/webserver-cluster"

  cluster_name  = "webservers-dev"
  instance_type = "t3.micro"
  min_size      = 1
  max_size      = 2
  environment   = "dev"
}

output "alb_url" {
  value = module.webserver_cluster.alb_url
}

For production:

# live/production/services/webserver-cluster/main.tf

module "webserver_cluster" {
  source = "../../../../modules/services/webserver-cluster"

  cluster_name  = "webservers-production"
  instance_type = "t3.medium"   # Bigger! 
  min_size      = 2
  max_size      = 5
  environment   = "production"
}

output "alb_url" {
  value = module.webserver_cluster.alb_url
}

Same module. Different inputs. Zero code duplication.

When I need to update the health check path? I change it in ONE file — the module. Every environment gets the update automatically.

The Moment I Knew It Worked

I deployed dev first:

$ cd live/dev/services/webserver-cluster
$ terraform init
$ terraform apply

Apply complete! Outputs:
alb_url = "http://webservers-dev-alb-xxxxx.elb.amazonaws.com"

I opened the URL. There it was — my web page with "webservers-dev" on top.

Then I looked at production (didn't deploy, just previewed):

$ cd live/production/services/webserver-cluster
$ terraform plan

# Notice the instance type:
module.webserver_cluster.aws_launch_template.web
    instance_type = "t3.medium"  # Dev used t3.micro!

The same code, producing different infrastructure. This is how real teams work.

Module Design Decisions I Had to Make

What to Expose vs What to Hide

I chose to expose:

Cluster name — caller must provide it (no default)
Instance type — different sizes for different environments
Min/max sizes — dev can run with 1 instance, production needs 3+
Environment — for tagging and naming

I kept internal:

AMI lookup — everyone gets the latest Amazon Linux 2
VPC selection — always use the default VPC
Security group structure — always the same pattern

The rule: Expose what changes between environments. Hide what stays the same.

What Happens If Someone Forgets a Required Variable?

module "broken" {
  source = "../../../../modules/services/webserver-cluster"
  # No cluster_name provided!
}

Error: Missing required argument
The argument "cluster_name" is required, but no definition was found.

Terraform catches it. The caller knows exactly what they missed. This is why required variables are so important — they prevent silent failures.

Chapter 4 Learnings

Root Module vs Child Module:

The configuration you run is the root module. Any module you call is a child module. There's no technical difference — just who's calling who.

What terraform init Does:

When you add a new module source, terraform init downloads the module code into .terraform/modules/. It doesn't apply anything — just makes the code available.

Module Outputs in State:

Module outputs are stored in the state file under the module's name. If you look in terraform.tfstate, you'll see:

"outputs": {
  "alb_url": {
    "value": "http://webservers-dev-alb-xxxxx.elb.amazonaws.com"
  }
}

This is how other configurations can read outputs from your module.

Challenges I Hit (And How I Fixed Them)

Challenge 1: Relative Paths

I kept getting source path does not exist errors. The problem? I was counting wrong.

From live/dev/services/webserver-cluster/ to modules/services/webserver-cluster/:

../ = back to live/dev/services/
../../ = back to live/dev/
../../../ = back to live/
../../../../ = back to project root, then into modules/

Fix: Print your current directory and count carefully!

Challenge 2: Variable Type Mismatch

I passed min_size = "2" (string) but my variable expected a number. Terraform gave me:

Error: Incorrect attribute value type
Inappropriate value for attribute "min_size": number required.

Fix: Always use the right type — numbers without quotes, lists with brackets.

Challenge 3: Missing Outputs

My module created an ALB, but I forgot to output its DNS name. The caller couldn't access anything!

Fix: Ask yourself "what does someone using this module need to know?" Output those things.

The Difference Between a Good Module and a Painful Module

Good Module	Painful Module
Clear, specific variable names	Vague names like `var1`, `var2`
Every variable has a description	No descriptions — guess what it does
Sensible defaults for optional values	Everything is required
Useful outputs (DNS names, IDs)	No outputs — caller can't get anything
Has a README	"Just read the code"
One clear purpose	Tries to do everything

Best Practices I Learned

Use the source parameter with relative paths — absolute paths break when other people clone your repo.
Always add descriptions to variables — future you will thank present you.
Provide sensible defaults — if 90% of use cases use t3.micro, make that the default.
Output everything a caller might need — DNS names, ARNs, IDs, URLs.
Version your modules — when you change a module, bump the version so callers upgrade intentionally.
Keep modules focused — one module = one responsibility. Don't create a "everything" module.

The Bottom Line

Modules are how Terraform scales from "my infrastructure" to "our infrastructure."

Before modules, I had 200 lines of copy-pasted code per environment. After modules, I have one module and 20 lines of configuration per environment.

When I need to update the health check path, I change one file — not three. When I need to add a new environment, I copy the calling configuration — not 200 lines of infrastructure.

Modules don't just save time. They save mistakes. And when you're managing production infrastructure, that's worth everything.

P.S. I spent 5 days writing the same infrastructure over and over. Today I spent 2 hours writing it once. The math is clear: modules pay for themselves the second you need a second environment.

# State Isolation: Workspaces vs File Layouts — When to Use Each

Mukami — Mon, 23 Mar 2026 14:47:39 +0000

Day 7 of the 30-Day Terraform Challenge — and today I faced the million-dollar question: How do you manage dev, staging, and production without accidentally nuking production?

Terraform gives you two answers. One is quick and easy. One is boring and safe. Let me tell you which one I'm choosing.

The Problem: One State to Rule Them All

Yesterday I had one state file. One. For everything.

That's fine for a personal project. But imagine a team of 10 people all running Terraform on the same state file. Dev changes. Staging changes. Production changes. All mixed together like a smoothie of chaos.

Someone adds a tag in dev. Someone else deletes a bucket in staging. Suddenly production is down and nobody knows why.

I needed isolation. Real isolation.

Option 1: Workspaces (The Quick Fix)

Workspaces are Terraform's built-in solution. Same code. Different state files.

How It Works:

terraform workspace new dev
terraform workspace new staging
terraform workspace new production

Then in your code:

resource "aws_s3_bucket" "app" {
  bucket = "myapp-${terraform.workspace}"

  tags = {
    Environment = terraform.workspace
  }
}

When you're in dev, you get a dev bucket. In production, you get a production bucket. Same code, different resources.

What Workspaces Get Right:

Dead simple — one command and you're done
No code duplication — change one file, all environments get the update
Fast switching — terraform workspace select dev and go

Where Workspaces Fall Short:

No Code Isolation

Same code means same bugs everywhere. I fixed something in dev? That change applies to production too. Unless you're using Git branches carefully, one bad commit breaks everything.

Too Easy to Misconfigure

I did this three times today:

terraform workspace select production  # Wait, I meant dev!
terraform apply  # Oops, I just deployed to prod

No warning. No confirmation. Just me and my mistake.

Team Pain

Everyone works on the same codebase. Merge conflicts. Coordination headaches. Sarah's dev change blocks John's production deployment.

Workspaces are like using the same recipe for all three meals — breakfast, lunch, and dinner. Sure, it's simple, but you probably don't want pancakes for dinner.

Option 2: File Layouts (The Grown-Up Way)

Different folders. Different code. Different state. Complete isolation.

How It Works:

environments/
├── dev/
│   ├── backend.tf   # points to dev state
│   └── main.tf      # dev resources
├── staging/
│   ├── backend.tf   # points to staging state
│   └── main.tf      # staging resources
└── production/
    ├── backend.tf   # points to prod state
    └── main.tf      # prod resources (with extra protections)

What File Layouts Get Right:

Complete Isolation

Dev folder has dev code. Production folder has production code. They never touch. I can delete the entire dev folder and production keeps running.

Hard to Misconfigure

To break production, I have to:

cd environments/production
Run Terraform
Type yes

Three conscious decisions. No accidental deploys.

Team-Friendly

Dev team works in dev folder. Prod team works in prod folder. Different branches, different approvals, no stepping on toes.

Environment-Specific Logic

Production can have:

lifecycle {
  prevent_destroy = true  # Can't delete prod resources!
}

Dev can be reckless. Production can be locked down. Different needs, different code.

Where File Layouts Add Friction:

More Directory Management

Five folders. Ten files. Backend configs everywhere. It's organized, but it's also... a lot.

Repeated Backend Config

Every environment needs its own backend.tf. Copy-paste the same thing three times:

backend "s3" {
  bucket = "my-state-bucket"
  key    = "environments/dev/terraform.tfstate"  # Only this changes
  region = "us-east-1"
}

One line changes per environment. The rest is identical. Feels repetitive.

More Setup

Each environment needs its own terraform init. More commands, more waiting, more chances to forget something.

File layouts are like having separate kitchens for breakfast, lunch, and dinner. More work to set up, but you never accidentally serve breakfast food at a dinner party.

The Comparison Table

Aspect	Workspaces	File Layouts
Setup Time	5 seconds	5 minutes
Code Duplication	None	Some (backend.tf)
Accidental Prod Deploy Risk	High	Low
Team Collaboration	Hard (one codebase)	Easy (separate folders)
Environment-Specific Code	Complex (if statements)	Simple (different files)
Learning Curve	Easy	Moderate

When to Use Workspaces

You're working alone or in a small team. Two people? Workspaces are fine.

You're testing or prototyping. Spin up dev, test something, destroy it. Quick and dirty.

Your environments are nearly identical. Same resources, just different names. Workspaces handle that perfectly.

You value speed over safety. Sometimes that's the right tradeoff.

When to Use File Layouts

You work in a team. I don't care if it's 3 people or 300 — separate folders save relationships.

You have production infrastructure. If customers depend on it, use file layouts. Protect your sleep schedule.

Your environments differ. Dev uses t3.micro, prod uses t3.large? Different monitoring? Different backups? Separate code.

You need approvals. Prod requires code review. Dev doesn't. Separate folders make that easy.

My Recommendation

Workspaces for personal projects and testing. File layouts for everything else.

I know file layouts feel like more work. But here's the thing: that "more work" is actually the friction that prevents disaster.

Every time I cd environments/production, I pause. I check. I think. That pause is what keeps me from running terraform destroy on production by accident.

Workspaces are a sledgehammer. File layouts are a scalpel. Both can build infrastructure. Only one belongs in surgery.

The Bottom Line

Today I learned that infrastructure isolation isn't just about state files. It's about creating boundaries that protect you from yourself and your team.

Workspaces are clever. File layouts are boring. In production, boring wins every time.

Tomorrow I'll probably complain about managing all these folders. But tonight, I'll sleep knowing my dev experiments can't touch production.

What would you choose? I'm genuinely curious — drop your thoughts in the comments.

P.S. If you're using workspaces in production and it's working for you — I'm genuinely impressed. Tell me your secrets. I need them. 😅

# Managing Terraform State: Best Practices for DevOps ## How to Stop Fighting State Files and Start Collaborating

Mukami — Sun, 22 Mar 2026 17:45:53 +0000

Day 6 of the 30-Day Terraform Challenge — and today I learned something that every DevOps engineer eventually discovers the hard way: Terraform state is like your infrastructure's diary, and if you don't protect it, your team will pay the price.

Remember when I thought storing terraform.tfstate locally was fine? That was Day 1 me. Naive. Innocent. About to learn a valuable lesson.

Part 1: What's Actually in That State File?

Before today, I treated terraform.tfstate like a mysterious black box. "It's there, it works, don't touch it." But today, I opened it. And what I found surprised me.

Here's what a state file actually contains:

{
  "version": 4,
  "resources": [
    {
      "type": "aws_s3_bucket",
      "name": "demo",
      "instances": [{
        "attributes": {
          "arn": "arn:aws:s3:::my-demo-bucket",
          "bucket": "my-demo-bucket",
          "region": "eu-north-1",
          "tags": {
            "Environment": "Learning"
          }
        }
      }]
    }
  ]
}

What I found inside:

Resource ARNs — the unique identifiers AWS assigns
IP addresses — public and private IPs of every instance
Tags — all the metadata I thought was just for organization
Dependencies — Terraform knows which resources depend on which
Sensitive data — secrets, keys, and credentials (in plaintext!)

The scary part: If I committed this to Git (which I was doing before Day 6), anyone with access to my repo would have seen everything about my infrastructure. Every IP. Every ARN. Every. Single. Detail.

Part 2: The Bootstrap Problem — Terraform's Chicken-and-Egg

Here's a fun paradox: You need Terraform to create the infrastructure that stores Terraform's state. But you need state to run Terraform.

The Bootstrap Problem: How do you create the S3 bucket and DynamoDB table for remote state without already having remote state?

The Solution: Create them manually (or with a separate, simpler Terraform configuration) first.

I created a bootstrap configuration that deployed just the S3 bucket and DynamoDB table with local state. Once those were up, I could reconfigure my main infrastructure to use them as a remote backend.

It's like building a ladder to build a house. You need something to stand on while you construct the real thing.

Part 3: Remote State — Your Infrastructure's Safe Haven

Before (Local State):

State lived on my laptop
Team members couldn't see it
Concurrent runs = corruption
If my laptop died, state died
Secrets in plaintext on my hard drive

After (Remote State with S3 + DynamoDB):

State lives in S3 (versioned, encrypted)
Team members share the same state
Locking prevents concurrent runs
Versioning means I can recover from mistakes
Encryption keeps secrets safe

My Remote Backend Configuration:

terraform {
  backend "s3" {
    bucket         = "my-team-terraform-state"
    key            = "terraform.tfstate"
    region         = "eu-north-1"
    dynamodb_table = "terraform-state-locks"
    encrypt        = true
  }
}

What each argument does:
| Argument | Purpose |
|----------|---------|
| bucket | Where the state file lives (S3) |
| key | The path/filename in the bucket |
| region | Where the bucket lives |
| dynamodb_table | Locking mechanism (critical for teams) |
| encrypt | Server-side encryption at rest |

Part 4: State Locking — The Team Player's Best Friend 🔒

Remember the school project where two people edited the same Google Doc at the same time? Chaos, right?

State locking prevents that exact scenario.

I tested it with two terminals:

Terminal 1:

$ terraform apply
# Running...

Terminal 2 (while apply was running):

$ terraform plan

╷
│ Error: Error acquiring the state lock
│ 
│ Lock Info:
│   ID:        abc123-def456-ghi789
│   Path:      my-bucket/terraform.tfstate
│   Operation: OperationTypeApply
│   Who:       user@computer
│   Created:   2026-03-22 10:30:45 UTC
│ 
│ Terraform acquires a state lock to protect the state from being written
│ by multiple users at the same time.
╵

What this means:

Terraform knows when someone else is already working
It refuses to run until the lock is released
No two people can corrupt the state simultaneously

In a team environment, this is non-negotiable. Without locking, you're one simultaneous terraform apply away from infrastructure chaos.

Part 5: Why State Files Should NEVER Go in Git 🚫

I used to commit terraform.tfstate to Git. I was wrong. Here's why:

Problem	Explanation
Secrets in Plaintext	State files contain passwords, access keys, and database credentials in plaintext
Merge Conflicts	Two engineers committing state = unresolvable conflicts
No Locking	Git doesn't prevent concurrent writes
Large Files	State files grow huge and bloat the repository
Audit Issues	Git history doesn't reflect actual infrastructure changes

The correct approach:

Store state in S3 (encrypted, versioned)
Use DynamoDB for locking
Commit only your code to Git
Let the state live safely in the cloud

Part 6: The Migration Experience 🚀

When I added the backend configuration and ran terraform init, something magical happened:

Initializing the backend...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "s3" backend. Enter "yes" to copy and "no" to start empty.

  Enter a value: yes

Successfully configured the backend "s3"!

Terraform detected my local state and offered to migrate it to S3. I said yes, and seconds later, my state file was safely in the cloud, encrypted, versioned, and ready for team collaboration.

No manual copying. No complex scripts. Just Terraform being Terraform.

Part 7: What I Learned About State That Changed Everything 💡

State is the source of truth — Not your code, not the AWS console. The state file is what Terraform believes exists.
Drift detection is automatic — If someone manually changes infrastructure, terraform plan will show you exactly what's different.
S3 versioning is your safety net — Accidentally corrupted your state? Roll back to the previous version. It's like git revert for your infrastructure.
Encryption isn't optional — State files contain secrets. encrypt = true should be the default, always.
The bootstrap problem is solvable — Create your backend infrastructure first (manually or with a separate config), then migrate.

Best Practices Checklist

Practice	Why It Matters
Store state remotely (S3)	Team access, disaster recovery
Enable versioning	Roll back from mistakes
Enable encryption	Protect secrets
Use DynamoDB for locking	Prevent concurrent corruption
Never commit state to Git	Avoid secrets exposure and merge conflicts
Protect the bucket with `prevent_destroy`	Accidental bucket deletion = lost state
Block public access	State should never be publicly readable

The Bottom Line

Day 6 taught me that Terraform isn't just about writing code — it's about managing the state that code creates.

Local state is fine for learning. But the moment you work with a team (or even just a second laptop), you need remote state with locking.

I started today thinking "state is just a file." I'm ending today with a full S3 + DynamoDB backend that:

✅ Stores state securely
✅ Prevents concurrent corruption
✅ Encrypts everything
✅ Keeps version history
✅ Never touches Git

If you're still storing state locally in a team environment, you are one concurrent run away from disaster. Fix it today.

P.S. If you're wondering why I didn't just use terraform apply for the bootstrap — that's the bootstrap problem! You can't use Terraform to create the infrastructure that Terraform itself needs. I had to create the bucket and table first (manually), then migrate. Mind-bending, but it works. 🧠