DEV Community: Stephanie Makori

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

Stephanie Makori — Tue, 07 Apr 2026 11:03:15 +0000

Infrastructure as code (IaC) is powerful, but deploying untested changes can be risky. On Day 18 of my 30-Day Terraform Challenge, I focused on automating testing for Terraform code, covering unit tests, integration tests, and end-to-end tests, all tied together in a CI/CD pipeline.

Unit Tests

Unit tests are fast, cheap, and safe because they test your module plan only—no real resources are created. Each unit test ensures your resources are configured correctly, such as validating cluster names, instance types, and open ports. These tests catch configuration errors and bad variables before anything reaches production.

Unit tests run on pull requests, giving developers fast feedback and confidence that changes won’t break the module.

Integration Tests

Integration tests deploy real infrastructure, assert behavior, then destroy everything. They check how modules interact with actual cloud resources, like verifying that the application load balancer responds correctly and that EC2 instances are running as expected.

Integration tests run only on pushes to the main branch, because they are slower and use real AWS resources. Using defer destroy ensures all resources are cleaned up after the test, preventing cost leaks.

End-to-End Tests

End-to-end (E2E) tests validate the entire stack—from networking and databases to applications. They ensure that the full system works as a whole. E2E tests are slow and costlier, so they are run less frequently.

CI/CD Test Strategy

Unit tests run on pull requests (fast, free)
Integration tests run only on push to main (slower, real AWS)

Lessons Learned

Test Type	Tool	Deploys Real Infra	Time	Cost	What It Catches
Unit	terraform test	No	Seconds	Free	Config errors, bad variables
Integration	Terratest	Yes	Minutes	Low	Resource behavior
End-to-End	Terratest	Yes	15–30 min	Medium	Full system issues

Integration vs End-to-End: Integration tests focus on a module in isolation, while E2E tests validate the full stack.
Unit tests on PRs → fast feedback
E2E tests less frequent → expensive & slower

Challenges & Fixes

Missing required variables → added dummy values for unit tests
Go module errors → used go mod tidy
Terraform syntax mistakes → corrected .tftest.hcl content
Application Load Balancer slow startup → added retry logic
AWS credentials setup → properly configured GitHub secrets

Apply Screenshot

Conclusion

Automated testing with Terraform ensures infrastructure deploys reliably and safely. Combining unit, integration, and E2E tests gives full confidence while minimizing cost and risk. With CI/CD, every commit is validated, enabling rapid and safe iteration.

Additional Resources

Terraform Test Documentation
Terratest Documentation
GitHub Actions Terraform Setup
Go Testing Package
AWS Documentation

The Importance of Manual Testing in Terraform

Stephanie Makori — Mon, 06 Apr 2026 07:20:34 +0000

Manual testing is often overlooked in infrastructure as code workflows, especially with powerful tools like Terraform. However, before introducing automated tests, manual testing is essential to fully understand how your infrastructure behaves in real-world conditions.

On Day 17 of my 30-Day Terraform Challenge, I focused on building a structured manual testing process for my webserver cluster (Application Load Balancer + Auto Scaling Group + EC2 instances). This experience reinforced one key idea: you cannot automate what you do not understand.

Why Manual Testing Matters

Manual testing helps answer critical questions:

Does the infrastructure deploy correctly?
Does it behave as expected under real conditions?
Are there hidden misconfigurations that validation tools miss?

While terraform validate and terraform plan ensure correctness at a configuration level, they do not guarantee real-world functionality. Manual testing bridges that gap.

Building a Structured Test Checklist

Instead of randomly clicking around the AWS Console, I created a structured checklist to guide my testing process.

Provisioning Verification

Run terraform init and confirm initialization completes successfully
Run terraform validate and ensure configuration is valid
Run terraform plan and verify expected resources
Run terraform apply and confirm successful provisioning

Resource Correctness

Verify resources exist in AWS Console (EC2, ALB, Target Groups)
Confirm names, tags, and region match configuration
Ensure security group rules are correctly applied

Functional Verification

Retrieve ALB DNS using terraform output
Run curl http://<alb-dns> and verify response
Confirm all instances pass health checks
Terminate one instance and verify ASG replaces it

State Consistency

Run terraform plan after apply → expect “No changes”
Confirm Terraform state matches actual infrastructure

Regression Check

Make a small configuration change (e.g., add a tag)
Ensure only intended changes appear in terraform plan
Apply and verify the plan is clean afterward

Test Execution: What Worked and What Didn’t

Running the checklist revealed both successes and failures.

Successful Tests

Terraform Initialization

terraform init

Result: PASS

Terraform Apply

terraform apply -auto-approve

Result: PASS

All resources were successfully created (see screenshots).

ALB Functional Test

curl http://my-app-alb-123456.us-east-1.elb.amazonaws.com

Result: PASS

Returned: "Hello World v1" (confirmed via browser)

Auto Scaling Self-Healing

aws ec2 terminate-instances --instance-ids i-xxxx

Result: PASS

A replacement instance was automatically launched.

Failure and Fix

Test: Terraform Plan Consistency

terraform plan

Expected: No changes
Actual: 1 resource change detected
Result: FAIL

Root Cause:

A missing tag in the security group configuration.

Fix:

Added the missing tag in the Terraform code and re-applied:

terraform apply

Retest Result: PASS

This failure highlighted how manual testing uncovers real issues that static validation cannot.

Testing Across Environments

I ran the same tests in both development and production environments.

Key Differences:

Dev used t2.micro, production used t3.medium
Production had stricter security group rules

Unexpected Issue:

The application initially failed in production because HTTP (port 80) was blocked.

Fix:

Updated the security group to allow inbound HTTP traffic.

This demonstrated a common real-world problem: something works in dev but fails in production due to configuration differences.

The Importance of Cleanup

After testing, I destroyed all resources to avoid unnecessary costs.

terraform destroy -auto-approve

Verification

aws ec2 describe-instances --filters "Name=tag:ManagedBy,Values=terraform"

Output:

[]

aws elbv2 describe-load-balancers

Output:

[]

Why Cleanup Matters

Cleaning up sounds simple, but it is often where engineers fail. Terraform may partially destroy resources, leaving orphaned infrastructure behind.

If cleanup is ignored:

AWS costs can accumulate quickly
Old resources can interfere with future tests
Infrastructure drift becomes harder to manage

Lessons from Terraform Import

The terraform import lab introduced a critical concept: bringing existing infrastructure under Terraform management.

What It Solves

Allows Terraform to manage manually created resources

What It Does NOT Solve

It does not generate Terraform configuration
You must manually write .tf files

This reinforces that Terraform is not just a tool — it requires discipline and understanding.

Key Challenges and Fixes

Issue	Root Cause	Fix
Missing tag	Not defined in config	Added tag block
ALB not accessible	Port 80 blocked	Updated security group
Plan inconsistency	Config drift	Re-applied configuration

Final Thoughts

Manual testing is not optional — it is the foundation of reliable infrastructure.

It helps you:

Understand your system deeply
Catch real-world failures early
Build confidence before automation

Every failure discovered during manual testing becomes a future automated test case.

As I move forward in this challenge, the next step is clear: turn these manual checks into automated tests.

Day 17 Summary

Built a structured manual testing checklist
Tested both dev and production environments
Identified and fixed real infrastructure issues
Practiced strict cleanup discipline

Manual testing isn’t just a step — it’s a mindset.

Refactoring Terraform Toward Production-Grade Standards

Stephanie Makori — Tue, 31 Mar 2026 13:00:58 +0000

Day 16 of my 30-Day Terraform Challenge was all about improving infrastructure quality rather than simply adding more resources.

Today I took an existing Terraform setup and refactored it to make it more production-ready.

What I improved

I focused on several key areas:

reusable module structure
consistent tagging
lifecycle protection
input validation
CloudWatch monitoring
basic automated testing with Terratest

Biggest Refactors

One of the most useful improvements was introducing a shared common_tags block so I could apply consistent metadata across resources without repeating the same tag definitions everywhere.

I also added lifecycle rules like:

create_before_destroy
prevent_destroy

These are small changes in code, but they make a huge difference in real environments where accidental deletion or downtime can be expensive.

Monitoring and Validation

I added a CloudWatch CPU alarm and input validation rules to make the infrastructure safer and easier to operate.

That helped shift my thinking from:

“Will this deploy?”

to:

“Will this still be safe, maintainable, and observable later?”

Real Challenge I Hit

The most realistic issue today was with ALB access logging.

Terraform failed because the Application Load Balancer didn’t have permission to write logs to my S3 bucket. I had to fix that by adding the correct bucket policy.

That was a great reminder that “working Terraform” and “production-grade Terraform” are not the same thing.

Key Takeaway

Today showed me that strong infrastructure is not just about provisioning resources - it is about designing for:

safety
maintainability
observability
operational reliability

Terraform #IaC #AWS #DevOps #CloudComputing #30DayTerraformChallenge #TerraformChallenge

Working with Multiple Providers in Terraform

Stephanie Makori — Tue, 31 Mar 2026 11:00:24 +0000

Day 15 of my 30-Day Terraform Challenge was all about understanding how Terraform works across different provider ecosystems.

Today I explored three areas:

AWS multi-provider modules
Docker
Kubernetes on EKS

Multi-Provider Modules

One of the biggest lessons from today was learning how reusable Terraform modules handle provider aliases.

Instead of defining providers inside the module, the root configuration passes them in. This makes modules much more reusable across:

regions
accounts
environments

I used this pattern to deploy AWS resources across multiple regions and better understand how Terraform maps resources to the correct provider instance.

Docker with Terraform

I also worked with the Docker provider to define a local nginx container using Terraform.

This was a nice reminder that Terraform is not limited to cloud infrastructure — it can also manage local containerized workloads and other platforms through providers.

EKS and Kubernetes

The most advanced part of today was provisioning an EKS cluster and configuring the Kubernetes provider to deploy workloads into it.

I successfully created the EKS infrastructure, but I also ran into a very realistic issue:

the Kubernetes provider timed out when trying to reach the cluster API endpoint.

That challenge helped me understand an important real-world distinction:

provisioning infrastructure is one step
connecting workloads to it is another

Key Takeaways

Today helped me understand:

why configuration_aliases matters
how providers are passed into modules
how Terraform can work with AWS, Docker, and Kubernetes in one workflow
why EKS troubleshooting often goes beyond just “Terraform code”

Even though Kubernetes deployment was not fully completed, this was one of the most practical learning days so far.

Terraform #IaC #AWS #Docker #Kubernetes #EKS #DevOps #30DayTerraformChallenge #TerraformChallenge

Getting Started with Multiple Providers in Terraform

Stephanie Makori — Mon, 30 Mar 2026 13:03:16 +0000

Day 14 of my 30-Day Terraform Challenge focused on understanding how Terraform providers work and why they are so important in real-world infrastructure.

A provider is the plugin Terraform uses to communicate with a platform like AWS. When you run terraform init, Terraform reads the required_providers block, downloads the correct provider versions from the Terraform Registry, and records the exact versions in .terraform.lock.hcl.

That lock file turned out to be one of the most important things I learned about today. It keeps provider versions consistent across machines and CI/CD pipelines, which helps avoid “it works on my machine” problems. It should always be committed to version control.

Why Provider Versioning Matters

I used version constraints such as:

~> 6.0 for AWS
~> 3.6 for the random provider

This means Terraform can use safe updates within a version range while avoiding unexpected breaking changes.

Multi-Region Deployment with Provider Aliases

The most practical part of today was using provider aliases to deploy resources into multiple AWS regions.

I configured:

a default AWS provider for us-east-1
an aliased AWS provider for us-west-2

Then I used them to create:

a primary S3 bucket in one region
a replica S3 bucket in another region

This made it much easier to understand how Terraform decides which AWS API endpoint to call for each resource.

Key Takeaways

What stood out to me most today:

Providers are what connect Terraform to cloud APIs
terraform init is where provider installation and setup happens
.terraform.lock.hcl is essential for consistency
Provider aliases make multi-region deployments clean and manageable

Day 14 gave me a much deeper understanding of how Terraform works under the hood, and it made multi-region infrastructure feel much more approachable.

Terraform #IaC #AWS #DevOps #MultiRegion #CloudComputing #30DayTerraformChallenge #TerraformChallenge

Protecting Secrets in Terraform: What I Learned About Sensitive Data Management

Stephanie Makori — Mon, 30 Mar 2026 10:04:10 +0000

Day 13 of my 30-Day Terraform Challenge was focused on one of the most important production topics in Infrastructure as Code: handling secrets securely.

Today’s work was less about deploying flashy infrastructure and more about learning how easily sensitive data can leak if Terraform is not configured carefully.

It was a very practical lesson because secrets are everywhere in cloud environments:

database passwords
API keys
tokens
access credentials
connection strings

And if they are not handled properly, they can end up exposed in places you might not immediately think about.

Why Secret Management Matters in Terraform

Terraform makes it very easy to define infrastructure in code, but that also creates risk.

The moment you start working with values like passwords or credentials, you have to think about where those values live and who can see them.

A secret does not have to be directly printed in your code to be leaked.

It can show up in:

Terraform files
terminal output
logs
state files
version control
backend storage

That means secret management is not just one problem — it is a set of security risks across the Terraform workflow.

The Three Main Secret Leak Paths

One of the biggest takeaways from today was learning that there are three major places secrets can leak when using Terraform.

1. Secrets hardcoded in `.tf` files

This is the most obvious mistake.

If you directly write a password or API key in a Terraform file, then anyone who has access to the codebase can see it.

That includes:

teammates
collaborators
Git history
backups
accidental commits

This is the easiest kind of leak to avoid, but it is also one of the most common mistakes beginners make.

2. Secrets exposed in plan and apply output

Even if a secret is not hardcoded in a file, Terraform can still print it to the terminal if you are not careful.

That means secrets can accidentally appear in:

screenshots
logs
CI/CD pipelines
recorded demos
shell history

This is especially dangerous because people often assume that if a secret is not in the .tf file, then it is automatically safe.

That is not true.

3. Secrets stored in Terraform state

This was the most important lesson of the day.

Even if a secret is hidden in terminal output and not stored directly in code, Terraform may still keep it in the state file.

That means the state file becomes one of the most sensitive assets in your Terraform workflow.

If someone can access your state file, they may still be able to retrieve sensitive information.

That is why protecting state is such a critical part of Terraform security.

Using AWS Secrets Manager Instead of Hardcoding Values

To avoid placing secrets directly in my Terraform files, I used AWS Secrets Manager.

This was a much better pattern because the secret value lived in AWS instead of inside my code.

Terraform only referenced the secret when it needed to use it.

That gave me a much safer workflow because:

the actual password did not appear in my .tf files
the secret was centrally stored
the secret could be managed outside the Terraform codebase

This is a much more realistic pattern for production infrastructure.

Why `sensitive = true` Matters

Another important thing I practiced today was using sensitive = true on variables and outputs.

This tells Terraform to hide the value in CLI output.

That means instead of printing the actual value, Terraform shows:

(sensitive value)

This is useful because it helps reduce accidental leaks in:

terminal output
logs
screenshots
demos

And it worked exactly as expected during my apply output.

That said, today also taught me something very important:

`sensitive = true` is not enough on its own

It only protects display output.

It does not mean Terraform stops storing the value in state.

That distinction is extremely important.

Securing Terraform State Properly

Since Terraform state may still contain sensitive values, securing the backend is essential.

For this challenge, I used an S3 backend with the right protections in mind.

The security measures I focused on included:

encryption enabled
versioning enabled
public access blocked
access restricted through IAM

This made me realize that in real-world Terraform usage, protecting state is just as important as protecting code.

A lot of teams focus on hiding secrets in variables but forget that state is often where the real exposure risk still exists.

That was one of the strongest lessons from today.

Why `.gitignore` Matters More Than It Seems

Another small but very important part of today’s work was making sure Terraform files that should never be committed are excluded from Git.

That includes things like:

.tfstate
.tfvars
.terraform/
backup state files

This matters because many secret leaks happen not from Terraform itself, but from accidental commits.

A strong .gitignore is a simple but important layer of protection.

It is one of those small things that can prevent very big mistakes.

HashiCorp Vault vs AWS Secrets Manager

Today also pushed me to think more broadly about where secrets should live.

I learned that:

AWS Secrets Manager is great when:

your infrastructure is mostly in AWS
you want native AWS integration
you need a simpler managed secrets workflow

HashiCorp Vault is better when:

you are working across multiple clouds
you need dynamic secrets
you want more advanced centralized secrets management

That comparison was useful because it showed that secure secret handling is not only about Terraform syntax — it is also about choosing the right tool for your environment.

Challenges I Faced

One issue I ran into was that Terraform could not read the secret until it actually existed in AWS Secrets Manager.

That meant I had to create the secret first before Terraform could successfully reference it.

I also had to make sure the JSON structure inside the secret matched exactly with what Terraform expected.

That is a small detail, but if the keys do not match, Terraform will fail when trying to decode and reference the values.

Finally, I had to be very clear in my understanding of what sensitive = true actually does.

At first glance, it feels like full protection, but in reality it is just output masking, not full secret protection.

That was probably the biggest conceptual lesson from today.

What I Learned from Day 13

Day 13 taught me that secret management in Terraform is not just about “hiding passwords.”

It is about understanding the entire lifecycle of sensitive data:

where it is defined
where it is displayed
where it is stored
where it might accidentally leak

The biggest lessons for me were:

never hardcode secrets in Terraform files
use a secret manager whenever possible
mark sensitive values properly
protect Terraform state seriously
never assume a hidden CLI value means the secret is fully safe

This was one of the most practical and security-focused challenge days so far.

Final Thoughts

Day 13 reminded me that secure infrastructure is not just about provisioning resources — it is also about protecting the information that makes those resources work.

Terraform is powerful, but with that power comes responsibility.

Learning how to handle secrets properly is one of the most important habits to build early.

And I’m glad this challenge included it, because it made me think more like someone building real production infrastructure, not just completing labs.

Connect With Me

I’m documenting my journey through the 30-Day Terraform Challenge as I continue learning more about:

Terraform
AWS
Infrastructure as Code
DevOps best practices
Cloud security

If you are also learning cloud or IaC, feel free to connect.

Terraform #IaC #AWS #DevOps #CloudSecurity #SecretsManagement #InfrastructureAsCode #30DayTerraformChallenge #TerraformChallenge

Mastering Zero-Downtime Deployments with Terraform

Stephanie Makori — Mon, 30 Mar 2026 08:52:08 +0000

Day 12 of my 30-Day Terraform Challenge was all about one of the most practical and important DevOps concepts: deploying updates without taking an application offline.

Today I learned how Terraform handles infrastructure replacement, why its default behavior can cause downtime, and how to solve that using:

create_before_destroy
Auto Scaling Groups
Application Load Balancers
a full blue/green deployment strategy

This was one of the most exciting challenge days so far because it felt much closer to how production systems are actually managed.

Why Default Terraform Can Cause Downtime

Terraform is great at managing infrastructure, but not every resource can be updated in place.

Some resources — especially those tied to EC2 instance configuration, such as Launch Templates or Launch Configurations — often require replacement instead of modification.

By default, Terraform follows this sequence:

Destroy the old resource
Create the new resource

That is a problem for live infrastructure.

If an Auto Scaling Group is destroyed before the replacement is ready, then:

the old EC2 instances are terminated
the application stops serving traffic
users experience downtime
only after that does the new infrastructure come online

That gap is the outage window.

In real systems, even a short outage like that can be unacceptable.

The `create_before_destroy` Solution

Terraform provides a lifecycle rule called create_before_destroy to fix this.

Instead of deleting the old resource first, Terraform reverses the order:

Create the new resource
Wait for it to become healthy
Destroy the old resource

That simple change makes a huge difference.

It allows new infrastructure to come online before the old infrastructure disappears, which is exactly what you want during updates.

This was the key pattern behind today’s zero-downtime deployment.

The Auto Scaling Group Naming Problem

There is an important catch with create_before_destroy.

When Terraform creates the replacement resource before destroying the original one, both resources must exist at the same time.

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

So if your ASG name is fixed, the deployment fails.

The Fix

The correct solution is to avoid hardcoding the name and instead use something like:

name_prefix
or a generated unique suffix

I used name_prefix so AWS could generate unique names for replacement Auto Scaling Groups during deployment.

That solved the conflict and made zero-downtime replacement possible.

Deploying Version 1

For the first deployment, I launched my infrastructure with a simple application response showing version 1.

Once the Auto Scaling Group instances passed health checks and the Load Balancer became healthy, I verified the application in the browser.

This gave me my initial “live” environment.

At that point, traffic was being served successfully by the original deployment.

Verifying Zero Downtime with a Traffic Loop

To actually prove that my deployment was zero-downtime, I opened a second terminal and ran a continuous traffic check against the ALB.

The goal was simple:

keep sending requests during deployment
observe whether traffic ever failed
confirm that the application stayed available the whole time

This is a very practical way to test infrastructure changes because it simulates a real user continuously accessing the app while updates are happening.

Deploying Version 2

Next, I updated the application response from v1 to v2.

This forced Terraform to replace the underlying instance configuration.

Normally, this kind of change could cause downtime.

But because I had configured Terraform with create_before_destroy, the update behaved differently:

the replacement infrastructure was created first
the new instances came online
health checks passed
traffic remained available
then the old resources were removed

What I Observed

The traffic loop kept returning responses during the entire deployment.

At one point, the output changed from:

to:

The important part is that there were:

no connection errors
no timeouts
no interruption in service

That was my clearest proof that the deployment was truly zero-downtime.

This was honestly one of the most satisfying Terraform experiments I’ve done so far.

Taking It Further with Blue/Green Deployment

After proving a rolling zero-downtime update, I moved on to a more advanced deployment strategy:

Blue/Green Deployment

Blue/green deployment keeps two complete environments running at the same time:

Blue = current live environment
Green = new environment

Instead of replacing the live environment directly, you deploy the new version separately and then shift traffic when it is ready.

This pattern is extremely powerful because it makes rollbacks much easier and reduces deployment risk.

How the Traffic Switch Works

I implemented blue/green using:

two target groups
two Auto Scaling Groups
one ALB listener rule

A variable called active_environment controlled which target group received traffic.

That meant I could switch between:

blue
green

just by changing one Terraform variable and applying again.

Why This Is So Effective

The traffic switch happens at the load balancer level.

That means Terraform does not need to tear down one environment before enabling the other.

Instead, the ALB updates where traffic is routed.

This makes the cutover:

fast
clean
effectively instantaneous

That is what makes blue/green deployment such a strong production deployment pattern.

Testing the Blue/Green Switch

After both environments were deployed, I tested switching traffic from:

blue → green
then green → blue

Each time, the Terraform apply completed successfully and traffic moved to the selected environment.

There was no observable interruption while switching.

This was a really useful demonstration because it showed how infrastructure can support safe application rollouts and fast rollback paths.

That is exactly the kind of deployment flexibility teams want in production systems.

Limitations of `create_before_destroy`

Even though create_before_destroy is powerful, it has tradeoffs.

Some limitations include:

You temporarily run duplicate infrastructure, which increases cost
Some AWS resources still have naming or uniqueness constraints
It does not provide fine-grained traffic control
It is still tied to replacement behavior rather than explicit traffic switching

This is where blue/green becomes more powerful.

Tradeoffs of Blue/Green Deployment

Blue/green solves several of the limitations of create_before_destroy, but it introduces its own tradeoffs.

Advantages:

safer rollouts
fast rollback
cleaner traffic switching
better deployment isolation

Tradeoffs:

higher cost because two environments run at once
more infrastructure complexity
more moving parts to manage

So while blue/green is more powerful, it also requires more operational discipline.

What I Learned from Day 12

Today taught me that infrastructure updates are not just about changing code — they are about changing systems safely.

The biggest lessons for me were:

why Terraform’s default replacement behavior can be dangerous
how create_before_destroy avoids downtime
why naming strategy matters in AWS
how blue/green deployment gives even more control
how to verify deployment safety using real traffic

This was one of the most production-relevant challenge days so far.

Final Thoughts

Day 12 made Terraform feel much closer to real-world DevOps work.

It moved beyond simply provisioning infrastructure and into something more valuable:

deploying live updates safely and predictably

That is one of the most important skills in cloud and infrastructure engineering.

And honestly, seeing traffic switch from v1 → v2 and blue → green without downtime was very satisfying.

Connect With Me

I’m documenting my journey through the 30-Day Terraform Challenge as I continue learning more about:

Terraform
AWS
Infrastructure as Code
DevOps best practices

If you are also learning cloud or IaC, feel free to connect.

Terraform #IaC #AWS #DevOps #ZeroDowntime #CloudComputing #30DayTerraformChallenge #TerraformChallenge #InfrastructureAsCode

How Conditionals Make Terraform Infrastructure Dynamic and Efficient

Stephanie Makori — Mon, 30 Mar 2026 06:29:28 +0000

Day 11 of my 30-Day Terraform Challenge was all about going deeper into conditionals in Terraform.

Yesterday I used conditionals briefly alongside loops, but today the focus was entirely on how conditionals make Terraform configurations more flexible, reusable, and environment-aware.

This was one of the most practical Terraform days so far because it showed how a single codebase can behave differently in development and production without duplication.

Why Conditionals Matter in Terraform

Without conditionals, it is very easy to end up maintaining multiple copies of similar infrastructure code.

For example, you might create:

one version for development
another for staging
another for production

That quickly becomes hard to maintain.

Conditionals solve this by allowing Terraform to make decisions at plan time and apply time based on input variables and local values.

That means one configuration can support multiple use cases while staying clean and reusable.

The Ternary Expression

The core Terraform conditional is the ternary expression.

It follows this pattern:

if condition is true → use one value
otherwise → use another value

I used this pattern to make my infrastructure behave differently depending on the environment.

Instead of scattering conditional logic directly inside resource arguments, I moved all the decisions into a locals block.

That made the module much easier to read and much easier to maintain.

Why Centralizing Logic in `locals` Matters

One of the most useful lessons from today was learning that locals are the right place for conditional decisions.

I used locals to control:

instance type
minimum cluster size
maximum cluster size
whether monitoring is enabled
environment-specific behavior

This made my module cleaner because the resources themselves stayed focused on infrastructure, while the locals block handled the logic.

That separation is important when your Terraform grows beyond small examples.

Conditional Resource Creation with `count`

One of the most powerful Terraform patterns I practiced today was:

count = condition ? 1 : 0

This is how you make an entire resource optional.

I used this for resources such as:

CloudWatch alarms
Route53 records

This pattern is very useful because some resources should only exist in specific environments or use cases.

For example:

production might need monitoring
development might not
DNS records might only be created when explicitly requested

This pattern lets Terraform create or skip resources based on simple boolean toggles.

Referencing Conditional Resources Safely

A very important lesson today was that conditionally created resources cannot be referenced like normal resources.

If a resource uses count, then Terraform treats it like a list.

That means if the count is zero, there is no resource at index [0].

So if you reference it directly without checking whether it exists, Terraform throws an error.

The correct pattern is to guard the reference with another conditional so Terraform only tries to read the resource when it was actually created.

This is one of those details that seems small until it breaks your plan.

Building an Environment-Aware Module

The most practical part of today’s work was making my webserver cluster module fully environment-aware.

I used a single input variable:

environment

That one variable then controlled multiple infrastructure decisions.

In development:

smaller instance type
smaller cluster size
monitoring disabled

In production:

larger instance type
larger cluster size
monitoring enabled

This was a really good example of how one Terraform module can behave like multiple infrastructure configurations without duplicating code.

That is exactly the kind of pattern that becomes valuable in real teams.

Input Validation: Catching Errors Early

Another feature I added today was an input validation block.

This made sure that only valid environment names could be used, such as:

dev
staging
production

If someone passed an invalid value, Terraform returned a clear error before any infrastructure was deployed.

This is such a useful pattern because it helps catch mistakes early and prevents confusing downstream issues.

It is a small addition, but it makes a module much safer to share and reuse.

Conditional Data Sources: Existing vs New Infrastructure

One of the most interesting patterns from today was using conditionals with data sources.

I used this to support two deployment styles:

Brownfield deployment

Use an existing VPC

Greenfield deployment

Create a new VPC

This was controlled with a simple boolean toggle.

That pattern makes a module much more flexible because it can work in environments where infrastructure already exists, as well as in environments where everything needs to be created from scratch.

That is a very realistic real-world use case.

Challenges I Faced

One of the key things I had to be careful with today was making sure conditionally created resources were referenced safely.

Without the proper guards, Terraform would throw index errors when trying to access a resource that did not exist.

I also had to make sure my validation logic only accepted the intended environment values and behaved correctly when testing invalid input.

These were not huge blockers, but they were useful reminders that Terraform logic has to be designed carefully, especially when conditions affect whether resources exist at all.

What I Learned from Day 11

Today helped me understand the difference between:

conditional expressions → choosing between values
conditional resource creation → deciding whether a resource exists at all

That distinction is very important.

I also learned that conditionals become much more powerful when combined with:

locals
validation
optional resources
data sources
environment-aware design

This made Terraform feel much more like writing reusable infrastructure logic rather than just declaring resources one by one.

Final Thoughts

Day 11 was one of the most practical and useful Terraform challenge days so far.

It showed me how to write Terraform that is:

cleaner
more flexible
easier to reuse
safer across environments

Most importantly, it showed how one Terraform configuration can support multiple environments and deployment patterns without needing multiple codebases.

That is a huge step toward writing production-ready Infrastructure as Code.

Connect With Me

I’m documenting my journey through the 30-Day Terraform Challenge as I continue learning more about:

Terraform
AWS
Infrastructure as Code
DevOps best practices

If you are also learning cloud or IaC, feel free to connect.

Terraform #IaC #AWS #DevOps #CloudComputing #30DayTerraformChallenge #TerraformChallenge #InfrastructureAsCode

Mastering Loops and Conditionals in Terraform

Stephanie Makori — Sun, 29 Mar 2026 12:12:23 +0000

Day 10 of my 30-Day Terraform Challenge was all about making Terraform configurations more dynamic, scalable, and less repetitive.

Until now, most of my Terraform resources were declared one by one. That works for small labs, but it quickly becomes inefficient when you need multiple similar resources. Today’s focus was on the features that solve that problem:

count
for_each
for expressions
conditional logic

These are the Terraform features that make Infrastructure as Code feel much closer to programming.

Why This Matters

When working with infrastructure, repetition becomes a problem very quickly.

If you need:

multiple IAM users
repeated security group resources
optional scaling policies
different environment-specific configurations

…copy-pasting resource blocks is not a good long-term solution.

Terraform’s looping and conditional tools help make configurations:

more reusable
easier to maintain
safer to update
more scalable

That is exactly what I worked on today.

Using `count`

The simplest loop in Terraform is count.

It is useful when you want to create N copies of the same resource.

For my lab, I used count to create multiple IAM users from a list.

This worked well for creating a fixed number of users and helped me understand how count.index works.

What `count.index` Does

count.index gives the numeric position of the resource currently being created.

So if I have three usernames in a list:

index 0 → first user
index 1 → second user
index 2 → third user

This makes count very straightforward.

The Problem with `count`

The downside is that Terraform tracks these resources by position, not by identity.

That means if I remove an item from the middle of the list, Terraform shifts the indexes of everything after it.

As a result, resources can be unexpectedly recreated even if their names did not logically change.

This is one of those Terraform behaviors that can easily surprise you if you do not know how resource indexing works.

Using `for_each`

for_each solves the biggest weakness of count.

Instead of tracking resources by numeric position, Terraform tracks them by a key or value.

That means resources are more stable when the input collection changes.

For today’s challenge, I used for_each in two ways:

with a set
with a map

`for_each` with a Set

This is useful when you just need unique values, such as usernames.

Terraform creates one resource per value.

`for_each` with a Map

This is more powerful because it lets each resource carry its own extra configuration.

For example, each IAM user could have:

a department
an admin status

This made the configuration more descriptive and closer to a real-world use case.

Why `for_each` Is Safer

If I remove one user from a for_each collection, Terraform only removes that specific resource.

It does not renumber the rest of them.

That makes it much safer than count for collections that may change over time.

Using `for` Expressions

for expressions are different from count and for_each.

They do not create resources.

Instead, they are used to transform data.

For this challenge, I used a for expression in an output to create a clean map of IAM user ARNs keyed by username.

This was useful because it turned raw Terraform resource data into a much more readable and reusable structure.

I liked this part because it made outputs feel more intentional and structured rather than just dumping raw values.

Using Conditional Logic

Terraform conditionals use a ternary-style pattern:

if condition is true → use one value
otherwise → use another value

I used conditionals in two practical ways today.

1. Optional Autoscaling

I added an enable_autoscaling variable to my webserver cluster module.

When it is set to true, Terraform creates the autoscaling policies.

When it is set to false, Terraform skips them.

This is a great example of how conditionals can make infrastructure optional without duplicating code.

2. Environment-Based Instance Sizing

I also used conditional logic to vary instance size by environment.

This meant:

dev could use a smaller instance
production could use a larger instance

That is a realistic pattern and something I would absolutely expect to see in a real deployment.

Refactoring My Existing Infrastructure

The most useful part of today’s challenge was applying these ideas to infrastructure I had already built.

I refactored my webserver-cluster module from previous challenge days and improved it using what I learned.

What I Changed

I updated my module to:

replace repeated resource patterns with for_each
use count for optional autoscaling policies
use locals to centralize environment-based logic
use a for expression in outputs to create cleaner maps

This made the module much more reusable and much easier to maintain.

That is one of the biggest things I am starting to appreciate with Terraform: a lot of the improvement is not about adding more resources, but about writing infrastructure more intelligently.

A Challenge I Ran Into

One issue I hit during the for_each lab was accidentally trying to create duplicate IAM usernames in two different resource blocks.

Terraform returned an EntityAlreadyExists error because IAM usernames must be unique.

That problem was not really about Terraform syntax — it was about understanding how the configuration behaved as a whole.

I fixed it by changing the usernames in one of the collections so there was no overlap.

That was a useful reminder that infrastructure logic still needs careful thinking, even when the syntax is correct.

I also hit a temporary provider registry connection issue during terraform init, but retrying resolved it.

My Verdict: `count` vs `for_each`

After today, my takeaway is this:

Use `count` when:

you need a fixed number of almost identical resources
indexing is acceptable
you want a simple optional toggle pattern

Use `for_each` when:

resources are tied to meaningful names or keys
the collection may change over time
you want more stable infrastructure behavior

So while count is still useful, I would generally choose for_each for anything that is likely to evolve.

Key Lessons from Day 10

Today taught me that Terraform becomes much more powerful when you stop thinking in terms of static resource blocks and start thinking in terms of:

collections
transformations
reusable logic
controlled optional behavior

That shift makes Terraform feel much more expressive and much more maintainable.

Final Thoughts

Day 10 was one of the most practical challenge days so far.

It was not just about learning new syntax — it was about learning how to write better Terraform.

I now have a much clearer understanding of:

when to use count
when to use for_each
how to use for expressions
how to make infrastructure conditional and environment-aware

These are the kinds of patterns that make Infrastructure as Code more maintainable in real projects.

Connect With Me

I’m documenting my journey through the 30-Day Terraform Challenge as I continue learning more about:

Terraform
AWS
Infrastructure as Code
DevOps best practices

If you are also learning cloud or IaC, feel free to connect.

Terraform #IaC #AWS #DevOps #CloudComputing #30DayTerraformChallenge #TerraformChallenge #InfrastructureAsCode

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

Stephanie Makori — Sun, 29 Mar 2026 08:36:34 +0000

Day 9 of my 30-Day Terraform Challenge focused on moving beyond basic Terraform modules into more practical, real-world infrastructure patterns.

Today’s learning was centered around three key areas:

Module gotchas
Module versioning
Reusing modules safely across multiple environments

This was one of the most useful Terraform days so far because it introduced concepts that are essential when working in real teams and production environments.

Why This Matters

Terraform modules make infrastructure reusable and easier to manage, but they can also introduce subtle bugs and inconsistencies if not designed carefully.

In real-world DevOps and cloud engineering work, infrastructure should be:

Reusable
Predictable
Versioned
Safe across environments

That is exactly what today’s work helped me understand.

Module Gotcha #1: File Paths Inside Modules

One of the most common mistakes when working with Terraform modules is referencing files using relative paths without considering where Terraform is being executed from.

This becomes a problem when a module depends on files such as startup scripts, templates, or configuration files. If the file path is not handled correctly, Terraform may fail to locate the file.

The safer and more reliable approach is to always reference files relative to the module itself rather than where Terraform is being run. This makes the module portable and easier to reuse.

This was a very useful reminder that modules should always be written with portability in mind.

Module Gotcha #2: Inline Blocks vs Separate Resources

Another common issue comes from mixing inline resource configuration with separate resource definitions.

A good example is security group rules. Some Terraform resources allow rules to be defined directly inside the resource, while also allowing them to be created separately.

Mixing both approaches in the same module can lead to conflicts, confusing behavior, and harder debugging.

The better practice is to choose one style and remain consistent. Using separate resources tends to be more flexible and makes it easier to extend modules later without editing their internal structure too much.

This is a small design decision, but it has a big impact on maintainability.

Module Gotcha #3: Module Output Dependencies

One subtle but important gotcha is depending on an entire module when only one specific output or resource is needed.

When Terraform treats a whole module as a dependency, it can cause more resources than necessary to be recreated or reevaluated. This makes plans noisier and can lead to avoidable infrastructure changes.

The better design approach is to expose specific outputs and structure modules so dependencies remain as granular as possible.

This is one of those issues that may not seem serious at first, but in larger projects it can create a lot of unnecessary complexity.

Building a Reusable Module

For this challenge, I worked with a reusable Terraform module called webserver-cluster.

The purpose of this module is to provision a complete web server cluster setup in AWS, including the supporting infrastructure needed to serve traffic reliably.

The module provisions resources such as:

A VPC lookup
Subnets
Security groups
An Application Load Balancer
A Launch Template
An Auto Scaling Group
EC2 instances configured to run a simple Python-based web server

It was exciting to see how much infrastructure could be abstracted into a reusable module that can be called from multiple environments.

Versioning the Module

One of the most important parts of today’s challenge was learning how to version Terraform modules.

Instead of always referencing a module directly from a local folder or an unpinned GitHub repository, I learned how to use version tags to control exactly which module release an environment should use.

This is a very important practice because infrastructure code changes over time. Without versioning, an environment could suddenly behave differently just because the source module was updated.

To solve this, I created versioned releases for my module:

v0.0.1 — the initial reusable module release
v0.0.2 — an updated version with a new customizable input variable

This allowed me to safely introduce improvements while keeping full control over which environments used which version.

What Changed Between Versions

The key improvement I introduced in the second version of the module was the ability to customize the text displayed by the web server.

This made the module more flexible and more useful across different environments.

For example, development environments can now display a custom message that clearly identifies them as development deployments, while production can remain more stable and unchanged.

This may seem like a small feature, but it demonstrates the real value of versioning: making controlled improvements without breaking existing environments.

Multi-Environment Reuse

This was the part of the challenge that tied everything together.

I configured different environments to intentionally use different module versions:

Development uses the newer module version
Production stays pinned to the older stable version

This is a best practice because development is where changes should be tested first. Production should only move to a newer module version after that version has been validated.

This approach helps teams reduce risk, avoid unexpected infrastructure changes, and maintain confidence in production deployments.

It also reflects how real engineering teams manage infrastructure releases in a controlled way.

Why Version Pinning Matters

One of the biggest lessons from today is that not pinning module versions is risky.

If a shared module changes and environments are not pinned to a specific release, then different engineers may end up deploying different infrastructure without realizing it.

That can lead to:

Inconsistent deployments
Unexpected behavior
Hard-to-debug infrastructure issues
Production instability

Version pinning helps solve this by making infrastructure behavior consistent and predictable.

It gives teams control over when and how changes are introduced.

Challenges I Faced

One of the biggest practical challenges I encountered was accidentally committing Terraform-generated files into Git.

These included:

.terraform directories
terraform.tfstate files
provider binaries

This made my repository extremely large and caused push failures.

I fixed this by cleaning up the repository and adding a proper .gitignore file so that only the actual source files were tracked.

This turned out to be a valuable lesson on its own.

Infrastructure repositories should be clean, lightweight, and focused only on reusable source code—not generated artifacts.

Key Takeaways

Today’s challenge taught me several practical lessons:

Modules should be written to be portable and reusable
Small design choices inside modules can cause major issues later
Versioning is essential for safe infrastructure reuse
Development and production should not always move at the same speed
Clean Git practices are just as important in Infrastructure as Code as they are in software development

These are the kinds of details that make the difference between writing Terraform that “works” and writing Terraform that is safe, maintainable, and team-ready.

Final Thoughts

Day 9 was one of the most practical and eye-opening parts of my Terraform challenge so far.

I moved beyond simply creating modules and started thinking more like a real infrastructure engineer:

How do I make this reusable?
How do I make this safe for teams?
How do I control change across environments?

Those are the kinds of questions that matter in real production work.

I’m really enjoying how each day of this challenge builds not just technical skill, but also better engineering habits.

Connect With Me

I’m documenting my journey through the 30-Day Terraform Challenge as I continue learning more about:

Terraform
AWS
Infrastructure as Code
DevOps best practices

If you're also learning cloud or IaC, feel free to connect.

Terraform #IaC #AWS #DevOps #CloudComputing #30DayTerraformChallenge #TerraformChallenge #Inf

Building Reusable Infrastructure with Terraform Modules

Stephanie Makori — Fri, 27 Mar 2026 13:21:31 +0000

Building Reusable Infrastructure with Terraform Modules

As I progress through my 30-Day Terraform Challenge, Day 8 introduced one of the most practical and transformative concepts in Infrastructure as Code: Terraform modules.

Up to this point, I had been writing Terraform configurations directly for each environment. While this approach works for simple setups, it quickly becomes inefficient and repetitive when the same infrastructure needs to be deployed multiple times. This is where modules come in.

Why Modules Matter

Terraform modules allow you to package infrastructure into reusable components. Instead of rewriting the same resources—such as load balancers, auto scaling groups, and security groups—you define them once and reuse them wherever needed.

For this challenge, I created a reusable module for a complete web server cluster. This module includes all the necessary components required to run a scalable application behind an Application Load Balancer.

Applying the Module Across Environments

Once the module was created, I used it in two different environments: development and production.

The key difference between these environments was not the infrastructure itself, but the input values passed into the module. For example, development used smaller instances and fewer resources, while production used larger instances and higher scaling limits.

This demonstrated a key advantage of Terraform modules: the ability to reuse the same infrastructure while adapting it to different needs.

Understanding Inputs and Outputs

A major part of working with modules is understanding how inputs and outputs function.

Inputs (variables) allow you to customize how the module behaves.
Outputs expose important information from the module, such as the load balancer DNS name used to access the deployed application.

This separation makes modules flexible and easy to integrate into different environments.

Root Modules vs Child Modules

Another important concept I learned is the distinction between root modules and child modules.

A root module is the main Terraform configuration you execute.
A child module is a reusable component called by the root module.

This structure encourages better organization and makes infrastructure easier to manage as projects grow.

Challenges and Lessons Learned

One of the main challenges I faced was using the wrong relative path when referencing the module. This caused Terraform to fail until I corrected the path. It was a small mistake, but it reinforced how important structure and accuracy are when working with Terraform.

Final Thoughts

This challenge changed how I think about Terraform. It is not just a tool for provisioning resources—it is a way to build clean, reusable, and scalable infrastructure.

By using modules, I was able to reduce duplication, improve organization, and create a setup that can easily be extended in the future. This is a critical skill for anyone working in DevOps or cloud engineering.

Moving forward, I will approach Terraform projects with modular design in mind, knowing that it leads to more efficient and maintainable infrastructure.

Terraform Workspaces vs File Layout for Environment Isolation

Stephanie Makori — Tue, 24 Mar 2026 09:13:52 +0000

Day 7 focused on solving a real world problem in infrastructure management, handling multiple environments safely and efficiently.

In most projects, we need separate environments such as development, staging, and production. Terraform provides different ways to isolate these environments, and today I explored two of them.

Using Terraform Workspaces

Workspaces allow you to reuse the same configuration while maintaining separate state files for each environment.

I created three workspaces:

terraform workspace new dev

terraform workspace new staging

terraform workspace new production

Then I used the active workspace inside my configuration:

instance_type = var.instance_type[terraform.workspace]

This allowed me to dynamically change the instance type based on the environment.

Each workspace created its own infrastructure with separate state, even though the code was identical.

Using File Layout Isolation

The second approach was using separate directories for each environment.

environments/
dev/
staging/
production/

Each folder had its own Terraform configuration and backend pointing to a different state file in S3.

Example backend configuration:

backend "s3" {
bucket = "stephanie-day6-terraform-state-2026-unique"
key = "environments/dev/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-state-locks"
encrypt = true
}

This ensured that each environment was completely isolated at both the code and state level.

Comparing the Two Approaches

Workspaces are simple and fast to use. They are ideal when you want to manage multiple environments using the same configuration with minimal setup.

However, they rely heavily on selecting the correct workspace. A mistake here can lead to changes being applied to the wrong environment.

File layout isolation is more structured. Each environment has its own directory and backend configuration, which reduces the risk of accidental changes. This approach is more suitable for production systems where safety is critical.

Key Takeaways

Workspaces provide quick and flexible environment separation
File layouts provide stronger isolation and clarity
Both approaches use separate state files to manage infrastructure
Choosing the right approach depends on project size and team needs

Final Thoughts

This lab showed that managing infrastructure is not just about creating resources. It is about organizing environments in a way that is safe, scalable, and easy to understand.

Understanding these patterns is essential for building reliable systems in real world DevOps workflows.

Terraform #AWS #DevOps #InfrastructureAsCode #CloudComputing

DEV Community: Stephanie Makori

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

Unit Tests

Integration Tests

End-to-End Tests

CI/CD Test Strategy

Lessons Learned

Challenges & Fixes

Apply Screenshot

Conclusion

Additional Resources

The Importance of Manual Testing in Terraform

Why Manual Testing Matters

Building a Structured Test Checklist

Provisioning Verification

Resource Correctness

Functional Verification

State Consistency

Regression Check

Test Execution: What Worked and What Didn’t

Successful Tests

Failure and Fix

Testing Across Environments

Key Differences:

Unexpected Issue:

The Importance of Cleanup

Verification

Why Cleanup Matters

Lessons from Terraform Import

What It Solves

What It Does NOT Solve

Key Challenges and Fixes

Final Thoughts

Day 17 Summary

Refactoring Terraform Toward Production-Grade Standards

What I improved

Biggest Refactors

Monitoring and Validation

Real Challenge I Hit

Key Takeaway

Terraform #IaC #AWS #DevOps #CloudComputing #30DayTerraformChallenge #TerraformChallenge

Working with Multiple Providers in Terraform

Multi-Provider Modules

Docker with Terraform

EKS and Kubernetes

Key Takeaways

Terraform #IaC #AWS #Docker #Kubernetes #EKS #DevOps #30DayTerraformChallenge #TerraformChallenge

Getting Started with Multiple Providers in Terraform

Why Provider Versioning Matters

Multi-Region Deployment with Provider Aliases

Key Takeaways

Terraform #IaC #AWS #DevOps #MultiRegion #CloudComputing #30DayTerraformChallenge #TerraformChallenge

Protecting Secrets in Terraform: What I Learned About Sensitive Data Management

Why Secret Management Matters in Terraform

The Three Main Secret Leak Paths

1. Secrets hardcoded in .tf files

2. Secrets exposed in plan and apply output

3. Secrets stored in Terraform state

Using AWS Secrets Manager Instead of Hardcoding Values

Why sensitive = true Matters

sensitive = true is not enough on its own

Securing Terraform State Properly

Why .gitignore Matters More Than It Seems

HashiCorp Vault vs AWS Secrets Manager

AWS Secrets Manager is great when:

HashiCorp Vault is better when:

Challenges I Faced

What I Learned from Day 13

Final Thoughts

Connect With Me

Terraform #IaC #AWS #DevOps #CloudSecurity #SecretsManagement #InfrastructureAsCode #30DayTerraformChallenge #TerraformChallenge

Mastering Zero-Downtime Deployments with Terraform

Why Default Terraform Can Cause Downtime

The create_before_destroy Solution

The Auto Scaling Group Naming Problem

The Fix

Deploying Version 1

Verifying Zero Downtime with a Traffic Loop

Deploying Version 2

What I Observed

1. Secrets hardcoded in `.tf` files

Why `sensitive = true` Matters

`sensitive = true` is not enough on its own

Why `.gitignore` Matters More Than It Seems

The `create_before_destroy` Solution

Limitations of `create_before_destroy`

Why Centralizing Logic in `locals` Matters

Conditional Resource Creation with `count`

Using `count`

What `count.index` Does

The Problem with `count`

Using `for_each`

`for_each` with a Set

`for_each` with a Map

Why `for_each` Is Safer

Using `for` Expressions

My Verdict: `count` vs `for_each`

Use `count` when:

Use `for_each` when: