DEV Community: Mary Mutua

How to Convince Your Team to Adopt Infrastructure as Code

Mary Mutua — Sat, 11 Apr 2026 21:28:34 +0000

Convincing a team to adopt Infrastructure as Code is not a technical challenge - it is a people and process challenge.

Day 19 of my Terraform journey focused on this exact question:

How do you actually convince a team (and leadership) to adopt IaC?

Here is what worked for me and what I’ve seen in real team workflows, grounded in Chapter 10 of Terraform: Up & Running by Yevgeniy Brikman.

1. Start With the Business Case, Not the Tool

The biggest mistake is leading with Terraform features.

What leadership really cares about:

fewer incidents
less downtime
predictable releases
auditability

In the teams I’ve worked with, the real pain points are:

manual changes after PR merges
environment updates applied directly on servers
outages caused by exhausted workers
secrets stored on servers and readable by anyone with access

So the argument is not “Terraform is cool.”

The argument is:

“We can reduce production incidents caused by manual drift.”
“We can standardize autoscaling and reduce downtime.”
“We can build a full audit trail for infra changes.”

This aligns with Brikman’s key point: lead with the problem you are solving, not the tooling.

2. Adopt Incrementally, Not All at Once

Big‑bang migrations almost always fail.

The safer strategy is incremental:

pick one small, real problem
solve it with IaC
show results quickly
build trust and momentum

A simple first win would be:

a new S3 bucket managed entirely in Terraform
remote state stored in S3
PR workflow for infra changes

This reflects Brikman’s lesson: incremental wins build momentum and reduce risk.

3. Give the Team Time and Safety to Learn

IaC fails when only one person knows how it works.

In a real incident, people will choose the fastest fix.

If Terraform feels slow or unfamiliar, they will go manual - and drift begins.

To avoid that:

training time must be deliberate
workflows must be documented
the “right way” must be the easiest way
PR reviews and terraform plan should be standard
no manual console changes for Terraform‑managed resources

This is the cultural shift Brikman emphasizes: code‑first operations must be taught and supported, not assumed.

4. Common Failure Modes to Avoid

These are the patterns that keep showing up:

Trying to migrate everything at once
Starting without leadership buy‑in
Underestimating the learning curve
One person owns all IaC knowledge
Outage happens and the team goes manual
Drift accumulates until Terraform is abandoned

The fix is always the same:

smaller steps
clearer training
consistent team practices

A 4‑Phase Adoption Plan That Works

Phase 1 - Start with something new (2–4 weeks)

Create a new S3 bucket (logs/backups) in Terraform.

Low risk, clear win.

Phase 2 - Import existing infrastructure

Use terraform import for one high‑change resource (e.g., security group).

Phase 3 - Establish team practices

Module versioning, PR reviews, terraform plan in PRs, CI checks.

Phase 4 - Automate deployments

CI/CD runs terraform apply on merge to main with approval gates.

Each phase delivers value even if the next phase takes longer.

Final Thought

If you want your team to adopt IaC, don’t start with the tool.

Start with the biggest pain the team is already feeling.

Solve that one problem with IaC.

Then repeat.

That is how real adoption starts.

GitHub (Day 19):

👉 Github Link

Follow My Journey

This is Day 19 of my 30‑Day Terraform Challenge.

See you on Day 20.

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

Mary Mutua — Thu, 09 Apr 2026 19:17:16 +0000

Day 18 of my Terraform journey was one of the most exciting so far because it brought everything together: local testing, real AWS validation, and a CI/CD pipeline that runs automatically in GitHub Actions.

In Chapter 9 of Terraform: Up & Running, Yevgeniy Brikman explains that manual testing is necessary, but it does not scale. Once infrastructure grows beyond what one person can test by hand every time, you need automation that catches regressions early and gives the whole team confidence to move faster.

That was the focus of today.

I implemented all three layers of Terraform testing:

unit tests with terraform test
integration tests with Terratest
end-to-end tests with Terratest
a GitHub Actions workflow to run them automatically

GitHub reference:

👉 GitHub Day 18 Link

Why One Test Type Is Not Enough

One of the clearest lessons from today is that no single test layer is enough on its own.

If you only use unit tests:

they are fast and cheap
but they do not prove real AWS behavior

If you only use integration tests:

they prove module composition
but they still do not test the full stack from the outside

If you only use end-to-end tests:

they give the strongest confidence
but they are slower, more expensive, and harder to debug

The right strategy is to use all three.

Layer 1: Unit Tests with `terraform test`

Terraform 1.6+ includes native testing through .tftest.hcl files, which makes lightweight unit-style testing much easier.

For Day 18, I used terraform test to validate module behavior without creating any real infrastructure.

These tests checked things like:

ASG naming logic
instance type propagation
security group port configuration
variable validation for invalid environments

Example command:

terraform -chdir=day_18/modules/services/webserver-cluster test

What I liked about this layer:

very fast
no AWS cost
no external dependencies
great for checking Terraform logic early

Tradeoff:

it does not prove that AWS will accept and run the infrastructure correctly

So unit tests are excellent for fast feedback, but they only cover part of the story.

Layer 2: Integration Tests with Terratest

The next layer was Terratest integration testing.

Here, the goal was to deploy real infrastructure and verify that the reusable modules worked correctly together in AWS.

For my integration test, I used:

the Day 18 webserver cluster module
a lightweight example root module
the default VPC as the test harness

The test:

applied the infrastructure
read outputs like alb_dns_name
sent HTTP requests to the deployed ALB
verified the expected response
destroyed the resources afterward

This gave me confidence that:

Terraform could really apply the stack
the ALB, ASG, target group, and alarms worked together
the app was actually reachable

Tradeoff:

slower than unit tests
creates real AWS resources
costs money
needs cleanup discipline

Still, this is the layer where Terraform starts moving from “logic looks right” to “real infrastructure works.”

Layer 3: End-to-End Tests with Terratest

The most complete layer was the end-to-end test.

Instead of using existing networking, this test deployed:

a fresh VPC
subnets
the webserver stack on top of that VPC
the full public application path

Then it verified that the final app response was correct from the outside.

This was the strongest test because it checked the complete system, not just a subset of it.

It also exposed a real issue:
my first end-to-end run failed because the subnet CIDRs did not fit inside the VPC CIDR range. AWS rejected them with an InvalidSubnet.Range error.

That was a very useful reminder that end-to-end tests often catch the kinds of real cloud issues that smaller tests miss.

After fixing the VPC CIDR input, the end-to-end test passed and cleaned up correctly.

Tradeoff:

slowest test layer
most expensive
most realistic
best confidence

This is why end-to-end tests are powerful, but you do not want to rely on them alone for every kind of feedback.

The CI/CD Pipeline That Ties It Together

After getting the local tests working, I built a GitHub Actions workflow to automate the testing pipeline.

The workflow runs:

unit tests on pull requests
unit, integration, and end-to-end tests on pushes to main
manual workflow runs when needed

That setup gave me a nice balance:

PRs stay faster and cheaper
merges to main get full confidence checks

One of the best parts of today was seeing the pipeline work the way it should:

local tests passed
the first GitHub Actions run failed
I fixed the workflow
opened a pull request from a feature branch
PR checks ran
merged into main
GitHub Actions ran all three layers successfully

That was a great end-to-end learning moment for both Terraform testing and CI/CD.

What Each Layer Contributed

Here is how I now think about the testing stack.

Unit tests

Tool:

terraform test

Best for:

validation logic
naming
output expectations
fast feedback

Integration tests

Tool:

Terratest

Best for:

real AWS deployment checks
reusable module composition
output and connectivity verification

End-to-end tests

Tool:

Terratest

Best for:

full-stack confidence
fresh environment testing
user-visible behavior
catching real infrastructure wiring problems

That layered approach is what makes the whole system strong.

My Main Takeaway

The biggest lesson from Day 18 was this:

good Terraform testing is not about choosing one “best” test type.

It is about using the right mix of test layers for the right level of confidence.

unit tests are fast and free, but test less
integration tests are more realistic, but slower and costlier
end-to-end tests are the most thorough, but also the heaviest

The right strategy uses all three.

And once those tests are connected to CI/CD, infrastructure changes stop being something you only hope will work and start becoming something your pipeline can prove.

Full Code

GitHub reference:

👉 GitHub Day 18 Link

Follow My Journey

This is Day 18 of my 30-Day Terraform Challenge.

See you on Day 19.

The Importance of Manual Testing in Terraform

Mary Mutua — Thu, 09 Apr 2026 12:50:50 +0000

Day 17 of my Terraform journey focused on something that sounds simple, but is actually a big part of real infrastructure work: manual testing.

In Chapter 9 of Terraform: Up & Running, Yevgeniy Brikman makes a strong case that manual testing is not something you outgrow once automated testing enters the picture. Instead, it is often the step that teaches you what should be automated, what success really looks like, and what can go wrong in the real world.

The biggest lesson from today was this:

manual testing is not the opposite of automated testing.

It is often the step that makes good automated testing possible.

Before you can automate a test well, you need to know:

what you are testing
what success looks like
what failure looks like
how the infrastructure behaves in real life
how to clean it up safely afterward

For Day 17, I built a structured manual testing process for my Terraform webserver cluster, ran it against both dev and production environments, documented the results, and treated cleanup as part of the test itself.

GitHub reference:
👉 Github Link

Why Manual Testing Still Matters

As Yevgeniy Brikman explains in Chapter 9, automated tests are powerful, but they do not replace the need to first understand the behavior of your infrastructure. Manual testing helps you build that understanding.

Automated tests are excellent for:

repeatability
regression detection
CI/CD confidence
faster feedback on future changes

But manual testing is still valuable because it helps you discover things automated tests do not always reveal immediately, such as:

confusing outputs
weak defaults
cloud-provider quirks
slow readiness times
cleanup surprises
differences between environments
gaps in documentation

Manual testing teaches you what actually matters to verify.

That is why I now see it as the foundation for better automation, not as something temporary or optional.

What a Structured Manual Test Should Cover

A manual test should be more than just “run terraform apply and click around.”

For Day 17, I organized my checklist into these categories.

1. Provisioning Verification

This is the Terraform layer.

Questions:

Did terraform init complete without errors?
Did terraform validate pass cleanly?
Did terraform plan show the expected resources?
Did terraform apply complete successfully?

This confirms that the configuration is valid and deployable.

2. Resource Correctness

This is the “did Terraform create what I expected?” layer.

Questions:

Are the expected AWS resources present?
Do names, tags, and regions match the variables?
Are security group rules exactly what I intended?

This is important because infrastructure can be “working” while still being incorrectly shaped.

3. Functional Verification

This is the behavior layer.

Questions:

Does the ALB DNS name resolve?
Does curl return the expected response?
Are instances healthy behind the load balancer?
Does the environment behave as the service is supposed to?

This is the part that tells you whether the deployed system is actually usable.

4. State Consistency

This checks whether Terraform and reality still match.

Questions:

Does terraform plan return “No changes” after apply?
Does the state reflect what exists in AWS?

This is important because drift or hidden mismatches are easy to miss otherwise.

5. Regression Check

This tests whether a small change behaves predictably.

Questions:

If I change one small thing, does Terraform show only that change?
After applying it, does terraform plan return clean again?

This helps prove the configuration is stable and understandable.

6. Cleanup

This is the most overlooked part of manual testing.

Questions:

Did terraform plan -destroy look correct?
Did terraform destroy succeed?
Were any active resources left behind afterward?

Cleanup is not just cost control.

It is part of whether the test process itself is trustworthy.

Provisioning Verification vs Functional Verification

This difference became much clearer to me today.

Provisioning verification asks:

“Did Terraform successfully create the infrastructure?”

Examples:

terraform init
terraform validate
terraform plan
terraform apply

Functional verification asks:

“Does the infrastructure actually do what it is supposed to do?”

Examples:

opening the ALB URL
running curl
checking the expected app response
checking whether health checks pass

You need both.

A Terraform apply can succeed while the application is still broken.

And an app can look reachable while the Terraform state or resource shape is still wrong.

That is why a complete manual test must cover both layers.

The Day 17 Test Environments

To make the tests more realistic, I ran the manual test process against two environments:

day_17/environments/dev
day_17/environments/production

Both used the Day 17 reusable modules, but with different environment settings.

That was useful because it let me compare whether behavior changed between:

dev
production

That kind of comparison matters, because many real issues only show up when environments differ in:

instance count
naming
defaults
scaling assumptions

My Actual Day 17 Results

Here is what I found.

Dev environment

Passes:

terraform init
terraform validate
terraform plan
terraform apply
terraform output
browser check showed Hello from Day 17 Dev
terraform plan returned clean after apply
terraform plan -destroy showed the expected destroy plan
terraform destroy completed successfully

One useful cleanup nuance:
after destroy, a broad EC2 query still showed an instance ID briefly. At first glance, that looked like a failed cleanup.

But the real issue was the query, not Terraform.

A better command filtered to active instance states only:

aws ec2 describe-instances \
  --filters "Name=tag:ManagedBy,Values=terraform" \
            "Name=instance-state-name,Values=pending,running,stopping,stopped" \
  --query "Reservations[*].Instances[*].InstanceId"

That returned:

[]

So destroy had actually worked.

That was a great reminder that verifying cleanup also needs the right query logic.

Production environment

Passes:

terraform init
terraform validate
terraform plan
terraform apply
terraform output
browser and curl checks returned Hello from Day 17 Production
terraform plan returned clean after apply
terraform plan -destroy looked correct
terraform destroy completed successfully
post-destroy verification returned clean results for active resources

That told me the same module structure behaved correctly in both environments.

Why Cleanup Discipline Matters So Much

This was one of the biggest takeaways of the day.

As Brikman emphasizes in this chapter, a test is not really complete if you do not know how to tear the infrastructure down and verify that cleanup worked.

If you test infrastructure in AWS without strong cleanup habits, you can end up with:

running EC2 instances
load balancers
security groups
alarms
orphaned resources
unexpected costs

So a manual test is not complete when the app loads once in the browser.

A manual test is complete when:

the infrastructure worked
the results were recorded
the cleanup was run
the cleanup was verified

That is the standard I want to keep carrying forward.

What Manual Testing Gives You That Automation Alone Cannot

Day 17 helped me see that manual testing gives a different kind of value than automation.

Manual testing gives you:

context
observation
understanding
discovery

Automation gives you:

repetition
speed
consistency
regression protection

That means manual testing helps answer:

what should I automate next?
what actually matters to check?
what can go wrong in the real cloud environment?

That is why manual testing is still important, even when Terratest and other automation exist.

My Main Takeaway

The biggest lesson from Day 17 was this:

good infrastructure testing is not just about proving that Terraform runs.

It is about proving that the system behaves correctly, stays consistent, and can be cleaned up safely.

Manual testing helped me define that process clearly.

And once that process is clear, automated testing becomes much more meaningful.

Full Code

GitHub reference:
👉 Github Link

Follow My Journey

This is Day 17 of my 30-Day Terraform Challenge.

See you on Day 18 🚀

Creating Production-Grade Infrastructure with Terraform

Mary Mutua — Tue, 07 Apr 2026 18:59:33 +0000

Day 16 of my Terraform journey was less about creating new resources and more about improving how infrastructure is designed.

The big lesson was this:

Terraform code that works is not automatically production-grade.

Production-grade infrastructure should be:

modular
reliable
secure
observable
maintainable
testable

For Day 16, I audited my earlier infrastructure against that checklist, refactored it into smaller modules, added better validation and observability, and tested it both manually and with Terratest.

GitHub reference:
👉 Github Link

The Production-Grade Checklist

Here is the practical version of what I used.

1. Structure

In practice, this means:

no giant main.tf doing everything
small modules with one responsibility
clear variables and outputs
repeated logic centralized with locals

2. Reliability

In practice, this means:

safer replacements with create_before_destroy
proper health checks
names that won’t collide
designs that support rolling changes

3. Security

In practice, this means:

no secrets in Terraform code
tighter security group rules
safer state handling
least-privilege thinking

4. Observability

In practice, this means:

consistent tagging
alerts for important metrics
basic operational visibility

5. Maintainability

In practice, this means:

README files for modules
pinned provider versions
reusable module boundaries
runnable examples
tests

That checklist turned Day 16 into an architecture refactor instead of just another provisioning exercise.

What I Refactored

I split the infrastructure into smaller modules:

modules/networking/alb
modules/cluster/asg-rolling-deploy
modules/services/hello-world-app
examples/hello-world-app

That made the design much easier to understand and test.

Refactor 1: Centralized Tagging

Before

resource "aws_instance" "web" {
  tags = {
    Name = "web-instance"
  }
}

After

locals {
  common_tags = merge(
    {
      Environment = var.environment
      ManagedBy   = "terraform"
      Project     = var.project_name
      Owner       = var.team_name
    },
    var.custom_tags
  )
}

resource "aws_lb_target_group" "app" {
  tags = merge(local.common_tags, {
    Name = "${var.cluster_name}-tg"
  })
}

Why this matters:

less repeated code
consistent tagging
easier filtering, billing, and operations

Refactor 2: Variable Validation

Before

variable "environment" {
  type = string
}

After

variable "environment" {
  description = "Deployment environment"
  type        = string

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

And for instance type:

variable "instance_type" {
  description = "EC2 instance type for the app cluster"
  type        = string

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

Why this matters:

bad values fail early
module expectations are clearer
future users make fewer mistakes

Refactor 3: Safer Replacements

Before

resource "aws_launch_template" "this" {
  # ...
}

After

resource "aws_launch_template" "this" {
  # ...

  lifecycle {
    create_before_destroy = true
  }
}

Why this matters:

safer rolling replacements
less disruption during changes
better production behavior

Refactor 4: Tighter Security Rules

Before

cidr_blocks = ["0.0.0.0/0"]

After

resource "aws_vpc_security_group_ingress_rule" "app_from_alb" {
  security_group_id            = aws_security_group.instance.id
  referenced_security_group_id = var.alb_security_group_id
  from_port                    = var.server_port
  to_port                      = var.server_port
  ip_protocol                  = "tcp"
}

Why this matters:

instances are not exposed directly to the internet
only the ALB can reach the app port
networking intent is much safer and clearer

Refactor 5: Basic Observability

I added an SNS topic and CloudWatch CPU alarm:

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
  statistic           = "Average"
  threshold           = 80
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.this.name
  }
}

Why this matters:

infrastructure should not just run
it should also tell you when it is unhealthy

How I Tested It

I tested Day 16 in two ways.

Manual test

I ran the example root module in:

day_16/examples/hello-world-app

Then I:

applied the stack
got the ALB DNS output
opened it in the browser
confirmed it returned:

Hello from Day 16

Then I destroyed everything.

Automated test with Terratest

I also added a Go test:

func TestHelloWorldApp(t *testing.T) {
    t.Parallel()

    terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: "../examples/hello-world-app",
        Vars: map[string]interface{}{
            "cluster_name":     "test-cluster",
            "instance_type":    "t3.micro",
            "min_size":         1,
            "max_size":         1,
            "desired_capacity": 1,
            "environment":      "dev",
            "server_text":      "Hello from Day 16",
        },
    })

    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)

    albDnsName := terraform.Output(t, terraformOptions, "alb_dns_name")
    url := "http://" + albDnsName

    http_helper.HttpGetWithRetryWithCustomValidation(t, url, nil, 60, 10*time.Second, func(statusCode int, body string) bool {
        return statusCode == 200 && strings.Contains(body, "Hello from Day 16")
    })
}

Why Automated Testing Matters

Manual testing is useful, but automated infrastructure testing gives you things manual testing cannot:

repeatability
faster regression checks
confidence after refactors
executable proof that the infrastructure behaves as expected
easier team validation in CI/CD later

Manual testing told me:

“it works right now”

Terratest moves closer to:

“it keeps working when I change the code”

That is a big difference.

My Main Takeaway

Day 16 changed how I think about Terraform quality.

The goal is not just:

“Can I provision this?”

The better question is:

“Can another engineer understand, trust, reuse, test, and operate this safely?”

That is what production-grade infrastructure really means.

Full Code

GitHub reference:
👉 Github Link

Follow My Journey

This is Day 16 of my 30-Day Terraform Challenge.
See you on Day 17 🚀

Deploying Multi-Cloud Infrastructure with Terraform Modules

Mary Mutua — Mon, 06 Apr 2026 20:52:18 +0000

Day 15 of my Terraform journey was about moving from basic provider usage into more advanced provider patterns.

This was the day where Terraform started to feel much more like a real infrastructure orchestration tool rather than just a way to create isolated cloud resources.

The main focus was learning how to:

build modules that accept provider configurations from their callers
use multiple providers in one Terraform project
manage Docker locally with Terraform
prepare an AWS EKS + Kubernetes deployment using Terraform

GitHub reference:
👉 Github Link

Why This Topic Matters

In real infrastructure, one provider configuration is often not enough.

You may need:

one AWS region for primary infrastructure
another AWS region for replicas
a separate AWS account for production
Kubernetes to deploy workloads after AWS creates the cluster
Docker locally for quick testing before cloud deployment

That means the real question is no longer just:

“How do I use a provider?”

It becomes:

“How do I pass the right provider configuration into the right part of my Terraform code?”

That is what Day 15 was really about.

The Core Rule: Modules Should Not Define Their Own Providers

This was the biggest lesson of the day.

A reusable module should not hardcode provider blocks inside itself.

Why?

Because a reusable module should not decide:

which region to deploy into
which account to authenticate to
which alias to use
which credentials or access path the caller should depend on

Those decisions belong to the root module.

If the child module defines its own providers, it becomes harder to:

reuse it across regions
reuse it across accounts
test it cleanly
compose it into larger infrastructure setups

So the better pattern is:

the child module declares which providers it expects
the root module creates the real provider configurations
the root module passes them in explicitly

The `configuration_aliases` Pattern

Inside a reusable module, Terraform needs to know which aliased provider configurations the module expects.

That is where configuration_aliases comes in.

Example:

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

This tells Terraform:

this module expects two aliased AWS provider configurations
one named aws.primary
one named aws.replica

This is important because the child module is not defining the providers itself.
It is declaring the provider interfaces it expects the caller to supply.

That was the cleanest way for me to understand it:
the module is declaring its provider dependencies, not its provider setup.

Wiring Providers into a Module with the `providers` Map

Once the child module declares what it expects, the root module passes the actual provider configurations using the providers map.

Example root module:

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

provider "aws" {
  alias  = "replica"
  region = "us-west-2"
}

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

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

This part is the key wiring step.

The root module is saying:

when the child module asks for aws.primary, give it this provider
when the child module asks for aws.replica, give it this other provider

That keeps the responsibilities clean:

child module = reusable logic
root module = environment-specific provider wiring

My Multi-Region Module Lab

To make the concept practical, I built a reusable module that deploys S3 buckets in two regions.

Inside the child module:

one bucket uses provider = aws.primary
the other uses provider = aws.replica

In the root module:

the primary AWS provider points to one region
the replica AWS provider points to another region
both are passed into the module with the providers map

That gave me a very concrete understanding of how Terraform decides where each resource should go.

The important distinction here is:

provider is used on individual resources and data sources
providers is used when calling a module

That is one of the most important details from Day 15.

Docker as a Quick Multi-Provider Win

Before getting into EKS, I used the Docker provider for a simpler live example.

This was a great bridge between theory and the more expensive AWS/Kubernetes setup.

The Terraform configuration used:

the Docker provider
a Docker image resource
a Docker container resource

Example pattern:

provider "docker" {}

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

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

  ports {
    internal = 80
    external = 8080
  }
}

After applying it, I confirmed nginx was serving locally on:

http://localhost:8080

That was a very useful reminder that Terraform is not just for cloud resources.
It can also manage local platform resources through providers.

In this case:

Terraform managed Docker resources
Docker handled the actual container runtime

EKS + Kubernetes: The Real Multi-Provider Pattern

The most advanced part of Day 15 was preparing an EKS + Kubernetes deployment.

This is where Terraform starts using multiple provider types together in a realistic way.

The basic pattern is:

AWS provider creates the cloud infrastructure
Kubernetes provider connects to the cluster and deploys workloads

In the EKS lab, Terraform was prepared to create:

a VPC
public subnets
an EKS cluster
a managed node group
a Kubernetes namespace
a Kubernetes Deployment
a Kubernetes Service of type LoadBalancer

That is the real Day 15 milestone:
one Terraform project managing both infrastructure and the application platform on top of it.

Why I Stopped at `terraform plan` for EKS

I prepared the full EKS configuration and validated that Terraform could generate a real plan.

The plan showed that Terraform was ready to create:

AWS networking
EKS resources
node group resources
Kubernetes workload resources after the cluster became available

However, I intentionally stopped before terraform apply for the EKS part.

Why?

Because EKS is the first part of the challenge that can use credits more noticeably due to:

EKS control plane charges
worker nodes
load balancer resources
supporting AWS infrastructure

So I made a practical engineering decision:

complete the Docker lab live
complete the EKS configuration and plan
avoid unnecessary credit consumption by not applying the cluster today

I think that still reflects an important real-world skill:
sometimes the right infrastructure decision is not just “can I deploy it?”
but also “should I deploy it right now?”

What I Learned

Day 15 made a few things much clearer for me:

1. Root modules should own provider configuration

Reusable modules should stay flexible and let the caller decide region, account, and authentication strategy.

2. `configuration_aliases` is the missing link

It tells Terraform which aliased providers a module expects.

3. The `providers` map is how modules get wired

This is what connects root-module providers to child-module expectations.

4. Terraform can orchestrate multiple platforms

A single Terraform project can manage:

AWS
Docker
Kubernetes

That makes Terraform much more powerful than a simple cloud provisioning tool.

5. Docker is a great stepping stone before Kubernetes

It gives a quick, low-cost way to understand provider-based container management before moving into a much larger EKS deployment.

My Main Takeaway

The biggest shift for me today was understanding that multi-provider Terraform is really about separation of responsibilities.

child modules define reusable infrastructure logic
root modules define the real provider wiring
each provider handles a specific platform
Terraform coordinates the whole thing

Once that clicked, the Day 15 material became much easier to understand.

Full Code

GitHub reference:
👉 Github Link

Follow My Journey

This is Day 15 of my 30-Day Terraform Challenge.
See you on Day 16 🚀

Getting Started with Multiple Providers in Terraform

Mary Mutua — Sat, 04 Apr 2026 19:55:49 +0000

Day 14 of my Terraform journey was about understanding one of the most important Terraform building blocks: providers.

Until now, most of my Terraform configurations had only used one provider configuration at a time. That was enough for simple examples, but real infrastructure often spans:

multiple AWS regions
multiple AWS accounts
and sometimes multiple cloud platforms

Today I learned how Terraform providers actually work under the hood, how Terraform installs and pins them, and how provider aliases make multi-region and multi-account setups possible.

GitHub reference:
👉 Github Link

What Is a Provider in Terraform?

A provider is a plugin that Terraform uses to communicate with an external platform such as AWS, Azure, or Google Cloud.

A simple way to think about it is this:

Terraform Core handles:
- reading your .tf files
- building the plan
- understanding dependencies
- managing state
the provider handles:
- the real API calls to AWS or another platform

So when I declare something like:

resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"
}

Terraform Core understands the structure of the resource, but the AWS provider is the part that actually knows how to call AWS and create that bucket.

That was one of the biggest mindset shifts for me today: providers are not just configuration details. They are what connect Terraform to the outside world.

How Terraform Installs Providers

Terraform installs providers when you run:

terraform init

During initialization, Terraform reads the required_providers block and downloads the provider binaries from the Terraform Registry.

A production-friendly pattern looks like this:

terraform {
  required_version = ">= 1.0.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

This tells Terraform:

use the AWS provider
download it from hashicorp/aws
allow versions in the 5.x range, but not 6.0 or above

The version constraint:

version = "~> 5.0"

means:

use any version >= 5.0
but < 6.0

That helps avoid unexpected breaking changes from a future major version.

Why Provider Version Pinning Matters

This was one of the clearest best-practice lessons from today.

If provider versions are not controlled:

terraform init on a different machine may install a different provider version
that can cause unexpected plan changes
or even break a working configuration

Pinning provider versions makes the setup more stable and repeatable.

In other words:

no version pinning = more surprises
version pinning = more predictability

What `.terraform.lock.hcl` Does

After running terraform init, Terraform creates:

.terraform.lock.hcl

This file records the exact provider versions Terraform selected.

For example, in my Day 14 lab it recorded:

the provider source
the exact provider version
the version constraints
package hashes used to verify the provider binaries

This matters because it keeps provider installation consistent across:

my machine
teammates’ machines
CI/CD systems

That is why .terraform.lock.hcl should be committed to version control.

It does not store secrets.
It stores dependency lock information.

That was an important clarification for me.

Using a Single Provider

A simple provider configuration looks like this:

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

This means:

AWS is the provider
resources without any explicit override will use us-east-1

That default provider configuration applies automatically to all AWS resources in the configuration unless told otherwise.

Working with Multiple Copies of the Same Provider

The most practical concept I learned today was provider aliases.

If I want Terraform to deploy some resources in one region and other resources in another region, I need multiple configurations of the same provider.

Here is the pattern:

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

provider "aws" {
  alias  = "us_west"
  region = "us-west-2"
}

Now I have:

a default AWS provider in us-east-1
an aliased AWS provider named us_west in us-west-2

Any resource that should use the secondary region must reference that aliased provider explicitly.

Example:

resource "aws_s3_bucket" "primary" {
  bucket = "my-app-primary-bucket"
}

resource "aws_s3_bucket" "replica" {
  provider = aws.us_west
  bucket   = "my-app-replica-bucket"
}

That means:

primary goes to the default region
replica goes to the aliased provider region

My Multi-Region Day 14 Lab

For the hands-on part, I built a multi-region AWS example using provider aliases.

The lab included:

a primary S3 bucket in us-east-1
a replica S3 bucket in us-west-2
IAM resources for replication
an S3 replication configuration between the two buckets

That gave me a practical example of how multiple provider configurations can work together in one Terraform project.

This was much more useful than just reading about aliases in theory.

Multi-Account Pattern with `assume_role`

I also reviewed the multi-account pattern.

For multiple AWS accounts, Terraform can use aliased providers with assume_role:

provider "aws" {
  region = "us-east-1"
  alias  = "production"

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

provider "aws" {
  region = "us-east-1"
  alias  = "staging"

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

I did not apply this part live because I do not yet have multiple AWS account roles set up, but I documented the configuration pattern as part of the lesson.

The important idea is that aliases are not only for regions.
They are also for:

multiple accounts
different access contexts
more advanced module usage later on

My Main Takeaway

Day 14 made Terraform providers feel much less magical.

Before today, I mostly saw providers as something you add near the top of a file and then move on.

Now I understand that providers control:

which platform Terraform talks to
where infrastructure gets deployed
which account or region is used
which provider version is installed
how multi-region and multi-account architectures become possible

The biggest lessons for me were:

always pin provider versions
always understand what terraform init is doing
commit .terraform.lock.hcl
use aliases carefully when working across regions or accounts

That is the foundation for more advanced provider and module work coming next.

Full Code

GitHub reference:
👉 Github Link

Follow My Journey

This is Day 14 of my 30-Day Terraform Challenge.

See you on Day 15 🚀

How to Handle Sensitive Data Securely in Terraform

Mary Mutua — Sat, 04 Apr 2026 02:32:18 +0000

Day 13 of my Terraform journey focused on one of the most important topics in real infrastructure work: secrets.

Every serious deployment eventually needs sensitive values:

database passwords
API keys
tokens
TLS material
provider credentials

The challenge is not just using those secrets. The challenge is making sure they do not leak into places they should never be.

Terraform makes infrastructure easy to define, but if you are careless with secrets, they can leak through your code, your terminal output, your Git history, and even your state file.

This post is the guide I wish I had before learning this lesson.

Why Secrets Leak in Terraform

There are three major ways secrets leak in Terraform.

If you understand these clearly, you will avoid most beginner and intermediate Terraform security mistakes.

Leak Path 1: Hardcoded in `.tf` Files

This is the most obvious mistake.

Wrong

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

Why this is bad:

the password is now in source control
if you run git add, the secret is part of Git history
even if you delete it later, the old commit still contains it

Once a secret is committed, you must treat it as compromised.

Better

Do not write the secret directly in Terraform code.

Instead, fetch it from a secret store such as 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" {
  engine         = "mysql"
  engine_version = "8.0"
  instance_class = "db.t3.micro"
  db_name        = "appdb"

  username = local.db_credentials["username"]
  password = local.db_credentials["password"]

  allocated_storage   = 10
  skip_final_snapshot = true
}

This keeps the secret out of your .tf files.

Leak Path 2: Secret Stored as a Variable Default

This one looks cleaner, but it is still wrong.

Wrong

variable "db_password" {
  default = "super-secret-password"
}

Why this is bad:

the secret is still in source control
it still ends up in the file
it is just hidden behind a variable name

A variable default is not a secure secret store.

Better

If a variable may carry a secret:

do not give it a default
mark it sensitive

variable "db_password" {
  description = "Database administrator password"
  type        = string
  sensitive   = true
}

Then pass the value from:

environment variables
your CI/CD secret store
a secure runtime mechanism

This helps reduce accidental exposure in code and CLI output.

Leak Path 3: Plaintext in Terraform State

This is the most important and most overlooked problem.

Even if you do everything else correctly:

no hardcoded secrets
no secret defaults
values pulled from Secrets Manager
outputs marked as sensitive

Terraform can still store secret values in terraform.tfstate.

That means:

anyone with access to the state file may be able to read secrets
protecting state is just as important as protecting code

This is what separates security-aware Terraform usage from surface-level secret handling.

AWS Secrets Manager Integration Pattern

For Day 13, I used AWS Secrets Manager as the secret source.

First, create the secret manually:

aws secretsmanager create-secret \
  --name "prod/db/credentials" \
  --secret-string '{"username":"dbadmin","password":"your-secure-password-here"}'

Then read it in Terraform:

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
  )
}

Then use it inside your resource:

resource "aws_db_instance" "example" {
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = "db.t3.micro"
  allocated_storage    = 10
  db_name              = "appdb"
  username             = local.db_credentials["username"]
  password             = local.db_credentials["password"]
  skip_final_snapshot  = true
}

Why this is better:

the secret is not hardcoded in Terraform
the secret stays centralized in Secrets Manager
secret updates can be managed outside the codebase

But remember:

this still does not eliminate the state-file risk

HashiCorp Vault Integration Pattern

For teams already using Vault, the pattern is similar.

Instead of pulling from AWS Secrets Manager, Terraform can read from Vault.

Example pattern:

data "vault_generic_secret" "db_credentials" {
  path = "secret/data/prod/db"
}

locals {
  db_username = data.vault_generic_secret.db_credentials.data["username"]
  db_password = data.vault_generic_secret.db_credentials.data["password"]
}

Then use those values in resources just like any other data source.

Why Vault is useful:

strong secret lifecycle management
centralized policy control
dynamic secrets in more advanced setups
useful when teams already standardize on Vault across environments

The same warning still applies:

if Terraform consumes the value in a resource, the secret can still end up in state

Using `sensitive = true`

Terraform provides a sensitive = true flag for variables and outputs.

Example variable:

variable "db_password" {
  description = "Database administrator password"
  type        = string
  sensitive   = true
}

Example output:

output "db_connection_string" {
  value     = "mysql://${aws_db_instance.example.username}@${aws_db_instance.example.endpoint}"
  sensitive = true
}

What it does:

prevents Terraform from printing the raw value in plan/apply output
helps keep logs and terminal output cleaner

What it does not do:

it does not encrypt the secret
it does not remove it from state
it does not make a bad secret-handling design safe

So sensitive = true is helpful, but it is not enough on its own.

Provider Credentials: Use Environment Variables

Never put provider credentials directly in Terraform code.

Wrong

provider "aws" {
  region     = "us-east-1"
  access_key = "AKIA..."
  secret_key = "..."
}

Better

Use environment variables:

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export AWS_DEFAULT_REGION="us-east-1"

This is much safer because:

credentials stay out of .tf files
CI/CD systems can inject them securely
they are easier to rotate than hardcoded values

In real environments, even better options are:

IAM roles
OIDC
short-lived credentials

State File Security Checklist

Because secrets can land in state, protecting the state file is mandatory.

Use this checklist:

store state remotely, not just on a laptop
enable S3 encryption
enable bucket versioning
block all public access
restrict bucket access with least-privilege IAM
enable DynamoDB locking
keep state files out of Git
treat anyone with state access as having potential secret access

A good backend pattern looks like this:

terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket"
    key            = "production/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-locks"
    encrypt        = true
  }
}

`.gitignore` Template for Terraform Projects

Every Terraform project should ignore these files:

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

This reduces the chance of accidentally committing:

local cache files
state files
variable files with secrets

Least-Privilege IAM for the State Bucket

Your state bucket should not be wide open.

At minimum, access should be limited to:

the IAM user/role that runs Terraform
only the necessary S3 actions
only the specific state bucket and key paths

A simple principle is:

allow read/write to the Terraform state bucket
allow lock-table access to the DynamoDB table
deny everyone else

The exact policy will vary by environment, but the mindset is the important part:

state is sensitive
access to state should be tightly controlled

My Main Takeaway

Day 13 changed how I think about Terraform security.

The big lesson was not just:
“don’t hardcode passwords.”

The real lesson was:

secrets can leak in code
secrets can leak through defaults
secrets can still leak through state even when the code looks clean

That means secure Terraform work requires both:

better secret input patterns
better state protection

Using AWS Secrets Manager and sensitive = true is a strong start.

But the deeper lesson is this:
if you protect the code but ignore the state file, you have not really solved the problem.

Full Code

GitHub reference:
👉 Github Link

Follow My Journey

This is Day 13 of my 30-Day Terraform Challenge.

See you on Day 14 🚀

Mastering Zero-Downtime Deployments with Terraform

Mary Mutua — Sat, 04 Apr 2026 00:50:09 +0000

Day 12 of my Terraform journey focused on one of the most practical infrastructure problems: how to deploy changes without taking an application offline.

This is the kind of Terraform topic that matters immediately in real systems. It is one thing to provision infrastructure. It is another thing entirely to update that infrastructure safely while users are still depending on it.

Today I worked through:

why Terraform’s default replacement behavior can cause downtime
how create_before_destroy changes the order of operations
why Auto Scaling Group naming becomes a problem
how blue/green deployment works with a load balancer
how to test the difference between a rolling replacement and an atomic traffic switch

Why Default Terraform Can Cause Downtime

By default, if Terraform needs to replace a resource that cannot be updated in place, it often destroys the old resource before creating the new one.

For a live service, that is risky.

In a setup using an Auto Scaling Group and a load balancer, the default replacement flow can look like this:

old ASG is destroyed
instances are terminated
traffic has nowhere healthy to go
new ASG is created
new instances boot and pass health checks
the app finally comes back

That gap between old capacity disappearing and new capacity becoming healthy is the downtime window.

For production workloads, that is not acceptable.

The Fix: `create_before_destroy`

Terraform provides a lifecycle rule for this exact problem:

lifecycle {
  create_before_destroy = true
}

This changes the replacement order:

create the new resource first
let the replacement become ready
destroy the old resource only after that

In my Day 12 lab, I used this on both:

launch templates
Auto Scaling Groups

That let Terraform attempt a safer rolling replacement instead of immediately dropping the old infrastructure.

The ASG Naming Problem

There is an important catch.

When create_before_destroy = true is enabled, Terraform needs the old and new versions of the resource to exist at the same time for a short period.

That becomes a problem with Auto Scaling Groups because AWS does not allow two ASGs with the same name to exist at once.

If the name is hardcoded, the deployment fails even though the lifecycle rule is correct.

Solving It with `random_id`

The solution is to give the replacement ASG a unique name.

I used a random_id resource tied to the application version:

resource "random_id" "rolling" {
  keepers = {
    app_version = var.app_version
  }

  byte_length = 4
}

Then I used that value in the rolling launch template and ASG naming.

That solved a real deployment problem:

the old ASG could stay alive
the new ASG could be created beside it
Terraform could shift traffic without a name collision

This was one of the most important practical lessons of the day.

Rolling Zero-Downtime Deployment

To test the rolling replacement flow, I deployed a versioned response behind an Application Load Balancer.

The app initially returned:

Hello World v1

Then I changed the Terraform input to:

Hello World v2

and ran terraform apply again while continuously hitting the ALB.

The goal was simple:

traffic should continue working throughout the apply
at some point the response should switch from v1 to v2
there should be no outage during the transition

That is the essence of a zero-downtime rolling update.

What I Observed During Testing

One important real-world lesson came up during testing: zero-downtime often requires temporary extra capacity.

Because the old and new ASGs briefly coexist, AWS may need to run both old and new instances at the same time. On a small AWS quota, that can hit vCPU limits.

That happened in my lab, so I had to test the rolling and blue/green parts separately instead of running everything at once.

That is actually a useful lesson in itself:

zero-downtime is safer
but it can temporarily cost more capacity

Blue/Green Deployment

I also implemented a blue/green deployment pattern.

Instead of gradually replacing one environment, blue/green keeps two separate environments:

blue = currently live
green = next version

Traffic is controlled by the load balancer listener rule:

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

That means traffic switching is not done by rebuilding the environment live. It is done by changing a single routing decision.

In practice:

blue served traffic first
I changed active_environment to green
ran terraform apply
traffic switched to green

This made the cutover feel much cleaner and more atomic than a normal replacement.

One Testing Detail That Matters

During the blue/green test, I initially thought the switch had not worked because the browser kept showing the old environment.

The real issue was browser caching.

Using curl or a hard refresh made it clear that Terraform had updated the listener rule correctly and the green environment was serving traffic.

That was a small but very real operational lesson:

always verify deployment changes with tools that are less likely to hide the truth behind cached responses

Rolling vs Blue/Green

The two patterns solve similar problems, but in different ways.

Rolling zero-downtime:

replaces the existing infrastructure safely
uses create_before_destroy
depends on overlap and health checks

Blue/green:

keeps two environments ready
switches traffic at the load balancer
makes the cutover more explicit and atomic

Both are valuable. Blue/green feels cleaner, but it also requires more duplicate infrastructure.

My Main Takeaway

Day 12 made one thing very clear: zero-downtime is not just about writing Terraform syntax correctly.

It depends on:

resource lifecycle order
naming strategy
healthy load balancer targets
enough temporary capacity
good testing discipline

Terraform gives you the tools, but understanding how those tools behave during replacement is what makes a production deployment safe.

Full Code

GitHub reference:
👉 Github Link

Terminal Transition

Example transition to include from your terminal testing:

Hello World v1
Hello World v1
Hello World v1
Hello World v2
Hello World v2
Hello World v2

And for blue/green:

Blue environment v1
Blue environment v1
Green environment v2
Green environment v2

Follow My Journey

This is Day 12 of my 30-Day Terraform Challenge.

See you on Day 13 🚀

How Conditionals Make Terraform Infrastructure Dynamic and Efficient

Mary Mutua — Wed, 01 Apr 2026 18:40:00 +0000

Day 11 of my Terraform journey was all about going deeper on conditionals.

I had already used conditionals briefly before, but today I focused on how they make a single Terraform configuration behave differently across environments without duplicating code.

This is what makes Terraform feel much smarter in real projects:

dev and production can use the same module
optional resources can be turned on or off cleanly
invalid input can be caught before deployment
one codebase can support different use cases

Why Conditionals Matter

Without conditionals, infrastructure code becomes repetitive very quickly.

You end up with:

separate dev and production files that mostly repeat the same logic
optional resources that require manual commenting in and out
brittle outputs that fail when a resource is disabled
confusing module behavior when bad input slips through

Conditionals solve that by making Terraform react to input values in a controlled way.

1. The Ternary Expression

The basic Terraform conditional is the ternary expression:

condition ? true_value : false_value

A common mistake is scattering that logic directly inside many resource arguments.

Before

resource "aws_instance" "web" {
  instance_type = var.environment == "production" ? "t3.small" : "t3.micro"
}

This works, but if you repeat the same logic in many places, the configuration becomes hard to read.

Better Pattern: Use `locals`

locals {
  is_production = var.environment == "production"
  instance_type = local.is_production ? "t3.small" : "t3.micro"
  min_size      = local.is_production ? 3 : 1
  max_size      = local.is_production ? 10 : 3
}

resource "aws_instance" "web" {
  instance_type = local.instance_type
}

This solves a real problem:

the decision logic stays in one place
resources stay easier to read
testing environment differences becomes simpler

2. Optional Resources with `count = condition ? 1 : 0`

This is one of the most useful Terraform patterns.

It lets you create a resource only when a condition is true.

resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  count = var.enable_detailed_monitoring ? 1 : 0

  alarm_name          = "${var.cluster_name}-high-cpu"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 120
  statistic           = "Average"
  threshold           = 80
}

This solves the problem of optional infrastructure.

Instead of:

duplicating code
maintaining separate files
commenting blocks in and out

you can simply say:

create it when enabled
skip it when disabled

I used the same idea for optional DNS creation too.

resource "aws_route53_record" "web" {
  count = var.create_dns_record ? 1 : 0

  zone_id = data.aws_route53_zone.primary[0].zone_id
  name    = var.domain_name
  type    = "A"
  ttl     = 300
  records = [aws_instance.web.public_ip]
}

3. Referencing Conditionally Created Resources Safely

This is where many people get tripped up.

If a resource uses count, Terraform no longer sees it as a single object. It becomes a list.

Wrong

output "alarm_arn" {
  value = aws_cloudwatch_metric_alarm.high_cpu.arn
}

This breaks when count = 0 because the resource does not exist.

Correct

output "alarm_arn" {
  value = var.enable_detailed_monitoring ? aws_cloudwatch_metric_alarm.high_cpu[0].arn : null
}

This solves a very real problem:

outputs remain safe
Terraform does not crash when the optional resource is missing
the module can behave differently without breaking downstream consumers

In my Day 11 module, I used the same pattern for both:

alarm_arn
dns_record_fqdn

4. Input Validation Blocks

Validation is one of the most practical Terraform features for shared modules.

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

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

This solves the problem of bad input reaching plan or apply.

Without validation:

someone could pass prodution by mistake
the module might behave unexpectedly
debugging becomes harder

With validation:

Terraform fails early
the error is clear
invalid values are caught before deployment starts

That is especially useful when modules are shared across teams.

5. The Environment-Aware Module Pattern

This was the biggest takeaway of the day.

Instead of maintaining separate modules for dev and production, I built one module that changes behavior based on a single environment variable.

locals {
  is_production = var.environment == "production"

  instance_type               = local.is_production ? "t3.small" : "t3.micro"
  min_cluster_size            = local.is_production ? 3 : 1
  max_cluster_size            = local.is_production ? 10 : 3
  detailed_monitoring_enabled = local.is_production
  dns_record_enabled          = local.is_production
}

Then the root configurations become very small.

Dev

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

  cluster_name = "day11-web-dev"
  environment  = "dev"
}

Production

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

  cluster_name               = "day11-web-production"
  environment                = "production"
  create_dns_record          = false
  enable_detailed_monitoring = true
}

This solves a major real-world problem:

one reusable module
environment-specific behavior
less duplication
fewer chances for config drift between environments

A Real Problem I Hit

One useful lesson from today came from Route53.

Because production defaulted to enabling DNS, Terraform tried to look up a hosted zone during planning. Since that hosted zone did not exist in my AWS account, terraform plan failed.

That showed why conditionals matter so much:

optional behavior must be guarded carefully
data lookups should only happen when the related feature is actually enabled
environment-aware defaults sometimes need explicit overrides

That is exactly why I made DNS override-friendly in the production caller.

My Main Takeaway

Day 11 showed me that conditionals are not just small syntax tricks.

They are what make Terraform:

reusable
environment-aware
safer
easier to maintain

The biggest lessons for me were:

keep conditionals in locals
use count = condition ? 1 : 0 for optional resources
reference count-based resources safely with [0] and null
add validation blocks to fail early
let one module adapt to multiple environments instead of duplicating code

That is what makes Terraform infrastructure dynamic and efficient.

Full Code

👉 https://github.com/mary20205090/30-day-Terraform-Challenge/tree/main/day_11

Follow My Journey

This is Day 11 of my 30-Day Terraform Challenge.

See you on Day 12 🚀

Mastering Loops and Conditionals in Terraform

Mary Mutua — Wed, 01 Apr 2026 17:51:15 +0000

Day 10 of my Terraform journey was all about writing less repetitive infrastructure code.

Up to this point, most resources had been declared one by one. That works for small labs, but it becomes painful fast when you need multiple IAM users, repeated rules, or environment-specific behavior.

Today I learned the four Terraform tools that make configurations dynamic:

count
for_each
for expressions
ternary conditionals

This was one of the most practical Terraform topics so far.

Why This Matters

Terraform is declarative, but these features make it feel much closer to a programming language.

They help you:

reduce repetition
create multiple resources safely
transform data cleanly
make infrastructure behavior change by environment

They are also heavily tested in the Terraform Associate exam.

1. Loops with `count`

count is the simplest loop in Terraform.

Use it when you want Terraform to create a fixed number of similar resources.

resource "aws_iam_user" "example" {
  count = 3
  name  = "user-${count.index}"
}

This creates:

user-0
user-1
user-2

The important part is count.index, which gives each resource its position.

The `count` Index Problem

count becomes risky when it is tied to a list that can change.

variable "user_names" {
  type    = list(string)
  default = ["alice", "bob", "charlie"]
}

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

At first, Terraform maps the list like this:

index 0 → alice
index 1 → bob
index 2 → charlie

Now imagine I remove alice from the list:

default = ["bob", "charlie"]

Terraform now sees:

index 0 → bob
index 1 → charlie

The configuration still runs, but the identities shift. Terraform tracks these resources by position, so when the list changes, later resources can be updated or recreated unexpectedly.

That is why count can be destructive when list order changes.

2. Loops with `for_each`

for_each solves that problem by using keys or values as identity instead of numeric positions.

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

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

Now Terraform tracks users by value, not by index.

If I remove alice, only alice is affected.

bob and charlie keep their identities.

That makes for_each much safer for collections that may change over time.

`for_each` with a Map

for_each becomes even more useful when paired with a map.

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

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

  tags = {
    Department = each.value.department
  }
}

This lets each item carry extra configuration.

3. `for` Expressions

for expressions do not create resources. They transform data.

For example, this outputs uppercase names:

output "upper_names" {
  value = [for name in var.user_names : upper(name)]
}

And this creates a map of usernames to ARNs:

output "user_arns" {
  value = { for name, user in aws_iam_user.example : name => user.arn }
}

A good way to think about it is:

count and for_each create resources
for expressions reshape data

4. Ternary Conditionals

Terraform conditionals use this form:

condition ? true_value : false_value

They are useful when you want infrastructure behavior to change based on input.

Example:

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

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

This means:

if environment is production, use t2.medium
otherwise use t2.micro

Then you can use it like this:

resource "aws_instance" "web" {
  instance_type = local.instance_type
}

Conditionals with `count`

Conditionals also work well with count when you want a resource to be optional.

variable "enable_autoscaling" {
  description = "Enable autoscaling for the cluster"
  type        = bool
  default     = true
}

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

This means:

if enable_autoscaling = true, create the policy
if enable_autoscaling = false, skip it

When to Use `count` vs `for_each`

This was the biggest lesson of the day.

Use count when:

you need a fixed number of nearly identical resources
order does not matter
the collection is unlikely to change

Use for_each when:

items have stable names or keys
the collection may change over time
each item may have different configuration

In practice, for_each is often safer.

My Main Takeaway

Day 10 made Terraform feel much more dynamic.

The most important lesson for me was this:

count is simple
for_each is safer
for expressions clean up data
conditionals make infrastructure flexible

Together, these four tools make Terraform much more powerful.

Full Code

👉 Github LInk

Follow My Journey
This is Day 10 of my 30-Day Terraform Challenge.

See you on Day 11 🚀

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

Mary Mutua — Mon, 30 Mar 2026 20:01:00 +0000

Day 9 of my Terraform journey focused on the part of modules that feels more real-world: not just creating them, but using them safely across environments.

After building my first reusable module on Day 8, today I went deeper into:

module gotchas
version pinning
using different module versions in different environments

This is where Terraform modules start to feel production-ready.

Why This Matters

A module is useful when it is reusable.

A module becomes powerful when:

it is versioned
environments can adopt changes at different times
teams can avoid accidental breakage from untested module updates

That was the core lesson of Day 9.

Gotcha 1: File Paths Inside Modules

One easy mistake is referencing files inside a module using a plain relative path like this:

user_data = templatefile("./user-data.sh", {
  server_port = var.server_port
})

The problem is that Terraform may resolve that path relative to where Terraform is run, not relative to the module itself.

The safer pattern is:

user_data = templatefile("${path.module}/user-data.sh", {
  server_port = var.server_port
})

This matters because:

path.module always points to the module’s own folder
file lookups stay predictable
the module works correctly when called from different root configurations

Gotcha 2: Inline Blocks vs Separate Resources

Some Terraform resources can be configured in two ways.

For example, security groups can use:

inline ingress and egress blocks
separate aws_security_group_rule resources

Mixing both patterns can cause conflicts and make the module harder to extend.

For reusable modules, separate resources are usually the better choice because they are more flexible and easier for callers to extend without editing the module itself.

Gotcha 3: Broad Module Dependencies

Another subtle issue is depending on an entire module with depends_on.

If a root configuration depends on a whole module, Terraform can treat the entire module as the dependency instead of just the specific resource or output that was actually needed.

That can create unnecessary dependency chains and make plans more confusing than they need to be.

The better pattern is:

expose more specific outputs
depend on the exact value you need
avoid broad module-level dependencies unless they are truly necessary

Versioning the Module

This was the most practical part of the day.

Instead of calling the module only from a local path, I versioned it with Git tags and pinned environments to specific versions.

Local Source

For quick development, a local source is useful:

source = "../../../../modules/services/webserver-cluster"

This is great for fast iteration, but not ideal for shared environments.

Git Source

For versioned usage, I used a Git source with ref=:

source = "github.com/mary20205090/30-day-Terraform-Challenge//day_8/modules/services/webserver-cluster?ref=v0.0.1"

This means:

pull the module from GitHub
use the module subdirectory
pin it to the exact version tag v0.0.1

Registry Source

A registry source is cleaner when modules are published more formally:

source  = "namespace/webserver-cluster/aws"
version = "1.0.0"

That is easier to read, but the Git source pattern was enough for my lab.

Multi-Environment Versioning Pattern

I then used different module versions intentionally across environments:

dev used v0.0.2
production stayed on v0.0.1

That is the real pattern teams use:

dev tests the newer module version
production stays pinned to the older stable version until the new one is validated

This makes module rollouts safer and reduces the risk of untested changes reaching production too early.

What I Observed

In my Day 9 setup:

dev picked up the new module version and exposed the additional output I added
production remained on the previous version and continued using the older stable module behavior

That confirmed the main idea:

same reusable module
different pinned versions
different environments can move at different speeds safely

Takeaway

Day 9 made one thing very clear to me: creating a reusable module is only the beginning.

The real strength comes from:

understanding the gotchas
versioning modules properly
testing newer versions in lower-risk environments
promoting those versions only when they are ready

That is what makes Terraform modules practical for teams at scale.

Full Code

👉 Github LInk

Follow My Journey

This is Day 9 of my 30-Day Terraform Challenge.

See you on Day 10 🚀

Building Reusable Infrastructure with Terraform Modules

Mary Mutua — Sun, 29 Mar 2026 17:52:52 +0000

Day 8 of my Terraform journey focused on one of Terraform’s most important ideas: modules.

After a week of building infrastructure, I started noticing the same patterns repeating:

security groups
launch templates
Auto Scaling Groups
Application Load Balancers
listeners
target groups

So today I stopped copying that logic and turned it into a reusable Terraform module.

Why Modules Matter

A module is a reusable package of Terraform code.

Instead of rewriting the same infrastructure for every environment, you write it once and call it from different root configurations with different inputs.

That gives you:

less duplication
cleaner code
easier maintenance
more consistency across environments

Module Structure

I organized my module like this:

modules/
└── services/
    └── webserver-cluster/
        ├── main.tf
        ├── variables.tf
        ├── outputs.tf
        └── README.md

This module packages a reusable web server cluster made of:

an ALB
a target group
a listener
security groups
a launch template
an Auto Scaling Group

Inputs and Outputs

To make the module reusable, I moved environment-specific values into inputs such as:

cluster_name
environment
instance_type
min_size
max_size
desired_capacity
server_port

I also exposed outputs that a caller would need, including:

alb_dns_name
asg_name

That means the module hides the repeated infrastructure logic, while still letting the caller configure what matters.

Calling the Module

I then created root configurations that reused the same module with different values.

For example:

dev used smaller settings
production used larger settings

So the pattern became:

same module
different inputs
zero code duplication

That was the biggest lesson of the day.

What Makes a Good Module

After building one, I think a good Terraform module should be:

focused on one job
easy to understand
configurable where needed
not overloaded with too many inputs
documented clearly in a README

A painful module is one that:

hardcodes too much
exposes too many confusing variables
has weak outputs
has no usage guidance

My Takeaway

Earlier days taught me how to build the infrastructure itself.

Day 8 taught me how to package that infrastructure into something reusable.

That shift feels important. Modules are what make Terraform code easier to scale across environments, projects, and teams.

I kept the full module code and root usage examples in GitHub here:

👉 Github Link

Follow My Journey

This is Day 8 of my 30-Day Terraform Challenge.

See you on Day 9 🚀

DEV Community: Mary Mutua

How to Convince Your Team to Adopt Infrastructure as Code

1. Start With the Business Case, Not the Tool

2. Adopt Incrementally, Not All at Once

3. Give the Team Time and Safety to Learn

4. Common Failure Modes to Avoid

A 4‑Phase Adoption Plan That Works

Final Thought

GitHub (Day 19):

Follow My Journey

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

Why One Test Type Is Not Enough

Layer 1: Unit Tests with terraform test

Layer 2: Integration Tests with Terratest

Layer 3: End-to-End Tests with Terratest

The CI/CD Pipeline That Ties It Together

What Each Layer Contributed

Unit tests

Integration tests

End-to-end tests

My Main Takeaway

Full Code

Follow My Journey

The Importance of Manual Testing in Terraform

Why Manual Testing Still Matters

What a Structured Manual Test Should Cover

1. Provisioning Verification

2. Resource Correctness

3. Functional Verification

4. State Consistency

5. Regression Check

6. Cleanup

Provisioning Verification vs Functional Verification

Provisioning verification asks:

Functional verification asks:

The Day 17 Test Environments

My Actual Day 17 Results

Dev environment

Production environment

Why Cleanup Discipline Matters So Much

What Manual Testing Gives You That Automation Alone Cannot

My Main Takeaway

Full Code

Follow My Journey

Creating Production-Grade Infrastructure with Terraform

The Production-Grade Checklist

1. Structure

2. Reliability

3. Security

4. Observability

5. Maintainability

What I Refactored

Refactor 1: Centralized Tagging

Before

After

Refactor 2: Variable Validation

Before

After

Refactor 3: Safer Replacements

Before

After

Refactor 4: Tighter Security Rules

Before

After

Refactor 5: Basic Observability

How I Tested It

Manual test

Automated test with Terratest

Why Automated Testing Matters

My Main Takeaway

Full Code

Follow My Journey

Deploying Multi-Cloud Infrastructure with Terraform Modules

Why This Topic Matters

The Core Rule: Modules Should Not Define Their Own Providers

The configuration_aliases Pattern

Wiring Providers into a Module with the providers Map

My Multi-Region Module Lab

Docker as a Quick Multi-Provider Win

EKS + Kubernetes: The Real Multi-Provider Pattern

Layer 1: Unit Tests with `terraform test`

The `configuration_aliases` Pattern

Wiring Providers into a Module with the `providers` Map

Why I Stopped at `terraform plan` for EKS

2. `configuration_aliases` is the missing link

3. The `providers` map is how modules get wired

What `.terraform.lock.hcl` Does

Multi-Account Pattern with `assume_role`

Leak Path 1: Hardcoded in `.tf` Files

Using `sensitive = true`

`.gitignore` Template for Terraform Projects

The Fix: `create_before_destroy`

Solving It with `random_id`

Better Pattern: Use `locals`

2. Optional Resources with `count = condition ? 1 : 0`