Forem: Stephanie Makori

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

Stephanie Makori — Fri, 17 Apr 2026 06:17:36 +0000

High availability is one of the most important goals when designing cloud infrastructure. In a production environment, deploying resources in a single region is not enough because a regional outage can make the entire application unavailable. To solve this, I built a 3-tier multi-region high availability architecture on AWS using Terraform, designed to remain available even if one AWS region fails.

This infrastructure consists of five reusable Terraform modules that provision networking, load balancing, compute, database, and DNS failover resources across two AWS regions. The result is a resilient architecture where traffic automatically shifts to a secondary region if the primary region becomes unhealthy.

Architecture Overview

The infrastructure follows a standard 3-tier architecture:

Presentation Tier

Route53 directs traffic to an Application Load Balancer (ALB) in the active region.
Application Tier

EC2 instances are managed by an Auto Scaling Group (ASG) across multiple Availability Zones.
Database Tier

Amazon RDS runs in Multi-AZ mode in the primary region with a cross-region read replica in the secondary region.

Traffic flows like this:

Route53 → ALB → EC2 Auto Scaling Group → RDS

This design ensures redundancy at every layer. If one Availability Zone fails, traffic is served from another AZ. If the primary region fails, Route53 automatically redirects traffic to the secondary region.

Why Use Five Terraform Modules?

To keep the infrastructure maintainable and reusable, I split the deployment into five Terraform modules:

VPC Module provisions networking resources such as VPCs, public/private subnets, route tables, internet gateways, and NAT gateways.
ALB Module provisions the Application Load Balancer, listeners, target groups, and ALB security groups.
ASG Module provisions launch templates, EC2 instances, scaling policies, alarms, and instance security groups.
RDS Module provisions the Multi-AZ primary database and cross-region replica.
Route53 Module provisions health checks and failover DNS records.

Using modules avoids duplicating code and allows each infrastructure component to manage a single responsibility. This also makes troubleshooting easier because changes can be isolated to one module without affecting the others.

Data Flow Between Modules

One of the biggest advantages of modular Terraform is how outputs from one module become inputs to another.

For example, the ALB module creates a target group and exports its ARN. That ARN is then passed to the ASG module so the EC2 instances register with the load balancer target group.

Similarly, the RDS primary database module exports its database ARN, which is passed into the secondary region RDS module as the replication source. This creates a cross-region read replica.

This flow creates a dependency chain:

VPC outputs → ALB inputs → ASG inputs → RDS inputs → Route53 inputs

This keeps the root Terraform configuration clean while each module handles its own internal complexity.

Route53 Failover in Action

A major feature of this architecture is automatic DNS failover using Route53 health checks.

Route53 continuously checks the health of the primary region ALB endpoint. If the primary region fails health checks, Route53 marks it unhealthy and redirects DNS traffic to the ALB in the secondary region.

The failover process works like this:

Route53 detects the failed health check in the primary region
DNS failover policy marks the primary record unhealthy
Traffic is routed to the secondary ALB
Users continue accessing the application with minimal downtime

This failover typically takes about 1 to 2 minutes, depending on DNS TTL and health check intervals.

This approach provides automatic disaster recovery without manual intervention.

Multi-AZ vs Cross-Region Replication

The database layer uses both Multi-AZ and cross-region replication, but they serve different purposes.

Multi-AZ

Multi-AZ creates a standby database in another Availability Zone within the same region. If the primary database instance fails, AWS automatically promotes the standby.

This protects against:

AZ failures
hardware failures
maintenance downtime

Cross-Region Read Replica

Cross-region replication copies data asynchronously to another AWS region.

This protects against:

regional outages
disaster recovery scenarios
geographic redundancy needs

Together, these strategies provide both high availability and regional resilience.

Benefits of This Architecture

This deployment provided several important benefits:

High availability through Multi-AZ EC2 and RDS deployment
Disaster recovery through cross-region redundancy
Automatic failover using Route53 health checks
Scalability through Auto Scaling Groups
Reusability through modular Terraform design
Consistency through infrastructure as code

Instead of manually configuring resources in AWS, Terraform made it possible to define the entire infrastructure in reusable modules and deploy it consistently across regions.

Final Thoughts

This project was an excellent demonstration of how Terraform modules can be combined to build a production-style multi-region high availability architecture on AWS.

By separating the infrastructure into reusable modules and wiring them together with outputs and inputs, I created an environment that is scalable, fault tolerant, and easy to manage.

The most valuable takeaway from this project was understanding how Route53 failover, Auto Scaling Groups, Multi-AZ RDS, and cross-region replicas work together to provide resilience at every layer of the application stack.

This is the kind of architecture that forms the foundation for real-world production systems where uptime and fault tolerance are critical.

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

Stephanie Makori — Thu, 16 Apr 2026 16:54:34 +0000

On Day 26 of the Terraform Challenge, I moved from deploying static infrastructure to building a scalable web application architecture on AWS using Terraform. This project brought together EC2 Launch Templates, an Application Load Balancer, an Auto Scaling Group, and CloudWatch alarms into a modular infrastructure design that can automatically respond to changes in demand.

This was one of the most practical labs in the challenge because it demonstrated how multiple Terraform modules can work together to create a production-style environment where traffic is distributed across healthy instances and scaling decisions happen automatically.

Project Architecture

The infrastructure was split into three reusable Terraform modules:

EC2 Module

This module created the launch template and security group for the web application instances.
ALB Module

This module provisioned the Application Load Balancer, listener, target group, and the ALB security group.
ASG Module

This module created the Auto Scaling Group, attached instances to the ALB target group, and configured CPU-based scaling policies with CloudWatch alarms.

By separating the resources into modules, the deployment stayed organized and reusable. Each module focused on one responsibility, and outputs from one module were passed as inputs to another.

Why Modular Design Matters

Instead of placing all AWS resources in one Terraform file, I separated them into modules so that each part of the infrastructure could be reused independently.

For example:

The EC2 module outputs the launch template ID
The ALB module outputs the target group ARN
The ASG module consumes both outputs to launch instances and attach them behind the load balancer

This modular structure keeps the environment configuration clean and makes it easier to maintain or expand the infrastructure later.

The envs/dev configuration only needed to define environment-specific variables like:

AMI ID
desired capacity
subnet IDs
VPC ID

All the infrastructure logic remained inside the modules.

Deployment Workflow

After building the modules, I deployed the infrastructure using the normal Terraform workflow:

terraform init
terraform validate
terraform plan
terraform apply

Terraform created:

EC2 Launch Template
Application Load Balancer
Target Group
Auto Scaling Group
CPU scale-out and scale-in policies
CloudWatch alarms

After deployment, Terraform returned the ALB DNS endpoint, which served as the public URL for the application.

When I opened the ALB URL in the browser, the application returned:

Deployed with Terraform — environment: dev

This confirmed that:

the EC2 instances launched successfully
the load balancer was routing traffic correctly
the Auto Scaling Group registered healthy targets

How Auto Scaling Works

The Auto Scaling Group was configured with:

minimum capacity: 1 instance
desired capacity: 2 instances
maximum capacity: 4 instances

CloudWatch alarms monitored average CPU utilization:

If CPU reached 70%, Terraform triggered a scale-out policy to add one instance
If CPU dropped to 30%, Terraform triggered a scale-in policy to remove one instance

This creates elasticity in the infrastructure, allowing the application to handle increased load while reducing costs during low usage.

One important configuration in the Auto Scaling Group was:

health_check_type = "ELB"

This setting ensures that scaling decisions are based on the Application Load Balancer health checks rather than only EC2 instance status.

Without it, an EC2 instance could remain "healthy" from AWS's perspective even if the web server application had failed. Using ELB health checks ensures only working instances receive traffic.

Benefits of This Architecture

This infrastructure design provides several key advantages:

1. High Availability

The Application Load Balancer distributes requests across multiple instances, reducing the risk of downtime.

2. Elastic Scaling

The Auto Scaling Group increases or decreases capacity based on CPU demand automatically.

3. Modular Reusability

Each module can be reused in other environments such as staging or production.

4. Maintainability

Because the modules are separated by function, updates can be made without affecting unrelated components.

5. Cost Efficiency

Scaling policies ensure resources are only added when needed.

Cleanup

Once the deployment was verified, I ran:

terraform destroy

This removed the Auto Scaling Group, load balancer, target group, launch template, and CloudWatch alarms.

Cleaning up after testing is important because EC2 instances and ALBs continue incurring charges if left running.

Final Thoughts

This project was a major step forward in understanding how scalable infrastructure is built on AWS with Terraform.

It was not just about provisioning EC2 instances, but about connecting multiple services into a self-managing system:

Launch Templates define compute
ALB distributes traffic
ASG manages instance count
CloudWatch triggers scaling actions

The biggest lesson was understanding how Terraform modules can model real infrastructure relationships while keeping the code reusable and organized.

This project felt like the first truly production-style deployment in the challenge, combining modularity, scalability, automation, and resilience into one infrastructure workflow.

Day 26 showed how Infrastructure as Code moves beyond provisioning resources into designing systems that can adapt automatically to real demand.

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

Stephanie Makori — Wed, 15 Apr 2026 09:23:42 +0000

Introduction

In this project, I deployed a fully functional static website using AWS S3 and CloudFront with Terraform. The goal was to apply everything learned throughout the Terraform challenge, including modular design, environment separation, remote state, and Infrastructure as Code best practices.

This project represents a complete real-world workflow where infrastructure is defined, reviewed, deployed, and destroyed in a controlled and repeatable manner.

Project Overview

The architecture of the solution follows a simple but powerful flow:

User requests website → CloudFront distributes content globally → S3 bucket serves static files

Key Components

S3 bucket for static website hosting
CloudFront distribution for global content delivery and HTTPS support
Terraform module for reusable infrastructure design
Environment-based configuration for dev deployment
Remote backend for state management and locking

Project Structure

The project was organized using a modular approach:

A modules directory containing reusable infrastructure logic for the static website
An envs directory containing environment-specific configurations
A backend configuration for remote state storage
A provider configuration for AWS setup

This structure ensures a clear separation between reusable infrastructure components and environment-specific deployment settings.

Module Design Decisions

The module was designed to encapsulate all infrastructure complexity related to the static website.

Key design choices:

The bucket name is required with no default because it must be globally unique in AWS
The environment variable is restricted to predefined values to prevent misconfiguration
Tags are optional to allow flexibility while still supporting cost tracking and resource organization
Default values are used for index and error documents because most static websites follow standard conventions

The module also centralizes tagging, security configuration, and CloudFront setup to ensure consistency across deployments.

Why Modules Were Used

Modules were introduced to:

Avoid duplication of infrastructure code
Promote reusability across environments
Improve maintainability of the codebase
Enforce consistent architecture patterns
Support scaling to multiple environments such as staging and production

Without modules, each environment would require repeated configuration, increasing the risk of inconsistency and errors.

Calling Configuration (Dev Environment)

The dev environment configuration acts as a lightweight wrapper around the module.

It only defines:

The bucket name
The environment type
Any overrides for defaults
Basic tagging information

All infrastructure logic remains inside the module, keeping the environment configuration clean and easy to manage.

Deployment Workflow

The deployment followed a structured Terraform workflow:

Initialization of the working directory and backend configuration
Validation of configuration correctness
Planning of infrastructure changes to preview modifications
Application of the planned changes to create real AWS resources

Each step ensured that infrastructure changes were predictable and reviewable before being applied.

Deployment Output

After successful execution, Terraform output provided a CloudFront distribution domain.

This domain represents the live endpoint of the deployed static website, served globally through AWS edge locations.

The deployment confirmed that:

S3 bucket was created and configured correctly
CloudFront distribution was provisioned successfully
Static website content was accessible via HTTPS

Live Website Confirmation

The deployed website was successfully accessed using the CloudFront URL.

The site displayed:

A simple static HTML page
A confirmation message indicating deployment via Terraform
Dynamic values such as environment and bucket information

This confirmed that both S3 and CloudFront were correctly integrated.

Cleanup Process

After verification, all infrastructure was destroyed using Terraform destroy.

This ensured:

No unnecessary AWS costs were incurred
All resources were properly removed
State was updated to reflect the destroyed infrastructure

This step reinforces the importance of infrastructure lifecycle management in real-world environments.

DRY Principle in Practice

The DRY (Don’t Repeat Yourself) principle was applied through module usage.

Instead of repeating S3 and CloudFront configurations across environments:

All logic was centralized in a single module
Environments only supplied configuration values
Infrastructure changes could be made in one place and applied everywhere

This significantly reduces complexity and improves long-term maintainability.

Key Learnings

CloudFront requires propagation time before the site becomes fully available globally
S3 static websites require careful configuration of public access policies
Modules are essential for scalable infrastructure design
Remote state improves collaboration and prevents configuration drift
Terraform outputs are critical for validating successful deployments

Conclusion

This project demonstrates how Terraform transforms simple infrastructure into a scalable and maintainable system. A static website deployment becomes more than just hosting files; it becomes a fully automated, version-controlled, and reproducible cloud architecture.

By combining S3, CloudFront, modules, and remote state, infrastructure is treated like software — predictable, reusable, and safe to evolve over time.

My Final Preparation for the Terraform Associate Exam

Stephanie Makori — Wed, 15 Apr 2026 05:43:19 +0000

After 24 days of consistent hands-on practice and study, I shifted fully into exam preparation mode. This stage was not about learning new tools, but about refining precision and confidence under pressure.

Exam Simulation Results

I completed a full 60-minute simulation with 57 questions and scored 44 out of 57 (77%). This gave me a realistic view of my readiness. While the score is above the passing mark, it exposed specific weak areas that needed focused attention.

The main gaps were:

Terraform CLI edge cases
State management scenarios
Terraform Cloud features

Most mistakes came from confusing similar commands and misunderstanding how state behaves in real situations.

Focus Areas and Improvements

I spent time drilling the highest-weight domains:

Terraform Basics

Clear understanding of state as the source of truth
Difference between resources and data sources
Proper use of lifecycle rules like prevent_destroy

Terraform CLI

Knowing exactly what each command does in practice
Understanding flags like -target and -auto-approve
Distinguishing between apply, destroy, and refresh-only

Infrastructure as Code Concepts

Idempotency ensures consistent results
Declarative approach defines desired state
Drift detection highlights real vs expected infrastructure differences

Terraform Purpose

Provider-agnostic design
Workflow: Write → Plan → Apply
Importance of state in tracking infrastructure

Common Exam Traps

A few patterns stood out during practice:

terraform state rm does not delete resources, only removes them from state
sensitive = true hides output but still stores values in state
Using branch references instead of version tags breaks reproducibility

My Exam Strategy

To stay efficient during the exam:

Spend no more than 60–90 seconds per question
Flag difficult questions and revisit later
Eliminate wrong answers first to improve accuracy
Pay close attention to keywords like state, destroy, and drift
Follow instructions strictly for multi-select questions

Final Thoughts

This preparation phase helped me move from general understanding to precise execution. The biggest shift was learning to think in terms of Terraform’s behavior, not just memorizing commands.

At this point, I am confident in both my knowledge and my approach. The goal is not just to pass the exam, but to truly understand how Terraform works in real-world scenarios.

Next step: exam day.

Preparing for the Terraform Associate Exam: Key Resources and Tips

Stephanie Makori — Mon, 13 Apr 2026 05:16:19 +0000

As I move deeper into Terraform exam preparation, I realized that success is not just about building infrastructure, but about understanding how Terraform behaves under different scenarios. Day 23 focused on auditing my knowledge against the official exam domains and identifying gaps early enough to fix them before the exam.

The first step was reviewing all exam domains and honestly rating my confidence level. I found that I am strongest in core Terraform concepts, modules, and general workflow, where I consistently operate in real projects. However, my weaker areas are Terraform CLI commands, state management, and Terraform Cloud internals. These are not difficult concepts, but they require deliberate hands on repetition rather than passive reading.

One of the most important parts of my preparation is the Terraform CLI. Commands like plan, apply, init, state mv, state rm, and import are heavily tested. The exam does not only ask what they do, but also what happens to infrastructure when they are executed. This means understanding the difference between modifying state and modifying real resources is critical.

I also reviewed non cloud providers such as random and local. These are often overlooked but appear frequently in exam questions because they test understanding of Terraform beyond AWS or cloud infrastructure.

Based on my audit, I created a structured study plan focusing on three key areas: CLI commands, state management, and Terraform Cloud features. Each topic has a clear practice method such as running commands in a test environment or writing out scenarios from memory.

The most valuable takeaway from this stage is that Terraform mastery is not about memorizing syntax. It is about understanding the lifecycle of infrastructure, especially how state connects configuration to real-world resources.

Moving forward, my focus is repetition, practice questions, and reinforcing weak areas until they become automatic.

Putting It All Together: Application and Infrastructure Workflows with Terraform

Stephanie Makori — Mon, 13 Apr 2026 04:50:48 +0000

Over the past three weeks, I have moved from writing basic Terraform code to building a complete, production-ready workflow that combines application and infrastructure deployment into one unified system.

The biggest takeaway is that Infrastructure as Code must follow the same discipline as software engineering. Version control, testing, code reviews, and CI/CD pipelines are not optional. They are essential for safe and scalable infrastructure.

In this final stage, I built an integrated CI pipeline using GitHub Actions. Every pull request triggers formatting checks, validation, and a Terraform plan. That plan is saved as an immutable artifact, ensuring that what gets reviewed is exactly what gets applied. This removes uncertainty and prevents unexpected changes during deployment.

I also implemented Sentinel policies in Terraform Cloud to enforce rules across all deployments. Restricting instance types prevents costly mistakes, while mandatory tagging ensures every resource is traceable and properly managed. These policies act as guardrails, allowing teams to move quickly without compromising safety.

Another key addition is the cost estimation gate. Terraform Cloud calculates the expected monthly cost before deployment and blocks changes that exceed a defined threshold. This introduces financial accountability directly into the workflow.

What makes this approach powerful is the concept of immutable infrastructure promotion. Instead of rebuilding environments differently, the same reviewed Terraform plan is promoted across environments. This ensures consistency, reduces drift, and aligns infrastructure workflows with modern application deployment practices.

Reflecting on this journey, the most important shift for me was thinking of infrastructure as a controlled, versioned system rather than manual configuration. This mindset is what enables teams to scale safely and confidently.

This is no longer just about writing Terraform. It is about building reliable systems.

A Workflow for Deploying Infrastructure Code with Terraform

Stephanie Makori — Sun, 12 Apr 2026 16:37:40 +0000

Yesterday, I mapped the standard application deployment workflow. Today, I applied the same seven-step process to infrastructure code and the difference is clear: deploying infrastructure is not just riskier, it demands stricter discipline.

I implemented a real change by adding a CloudWatch CPU alarm to a webserver instance using Terraform.

The workflow began with version control, enforcing protected branches and pull request reviews. This is familiar from application development, but far more critical when changes can affect live infrastructure.

Next, I ran terraform plan locally. This is where the workflows begin to diverge. Instead of running code, Terraform generates a diff against the current state, showing exactly what will change. This step is non-negotiable because even a small misconfiguration can have a large impact.

After creating a feature branch and committing the change, I opened a pull request and included the full plan output. Unlike application code reviews, this is not just about logic. Reviewers must evaluate cost, security, and potential blast radius.

Once approved, the change was merged and tagged. Deployment was then executed using a saved plan file:

terraform apply day21.tfplan

This ensures that what was reviewed is exactly what gets applied, eliminating drift between plan and execution.

To make the workflow safe, I implemented key safeguards: plan file pinning, blast radius documentation, and approval gates for changes. I also explored Sentinel policies, which act as a guardrail by enforcing rules before any deployment can proceed.

The biggest lesson is this: infrastructure deployments are not forgiving. Application failures can often be rolled back quickly. Infrastructure mistakes can cascade across systems.

Infrastructure as Code only works at scale when it is treated with the same rigor as software engineering, plus an extra layer of caution.

A Workflow for Deploying Application Code with Terraform

Stephanie Makori — Sun, 12 Apr 2026 11:18:12 +0000

Modern Infrastructure as Code becomes truly effective when it follows the same disciplined workflows used in application development. In this exercise, I mapped the standard seven step software delivery pipeline to a Terraform-based infrastructure workflow.

The process begins with version control, where all infrastructure code is stored in Git with a protected main branch. This ensures that no changes are applied directly without review, maintaining consistency and control across the system.

Next, I worked locally by modifying the application user data script to update the deployed web response to version 3. I validated this change using terraform plan, which provides a safe preview of all infrastructure modifications before execution.

A feature branch was created to isolate the change, and standard Git practices were followed for commit and push operations. This ensures traceability and clean collaboration.

During the review stage, a pull request was opened and the Terraform plan output was attached. This allows reviewers to assess infrastructure impact without needing to execute Terraform, improving both safety and transparency.

Automated validation was handled through CI pipelines using GitHub Actions, ensuring that formatting and configuration checks passed before merging.

Once approved, the change was merged into the main branch and tagged for version tracking. Deployment was then executed using terraform apply, and the updated application was verified through the browser.

Terraform Cloud enhanced this workflow by introducing remote state management, secure variable storage, and detailed audit logs. The private registry further enables reusable, versioned infrastructure modules across teams.

The key insight from this exercise is that Infrastructure as Code must follow structured engineering workflows. When teams skip planning, review, or automation, they introduce unnecessary risk, drift, and instability.

When properly implemented, Terraform transforms infrastructure into a predictable, versioned, and collaborative engineering system aligned with modern software delivery practices.

Day 19 - Adopting Infrastructure as Code in Practice

Stephanie Makori — Sun, 12 Apr 2026 10:30:25 +0000

Infrastructure as Code (IaC) is often presented as a technical skill, but in real environments, it is primarily an adoption and culture problem.

Today focused on understanding how teams transition from manual infrastructure management to a fully version-controlled and automated approach using Terraform.

What I worked on

I started by setting up a secure Terraform backend using an S3 bucket and DynamoDB for state locking. This ensured safe remote state management and collaboration.

Next, I provisioned infrastructure using Terraform by creating an S3 bucket. This reinforced the standard workflow of:

Writing configuration
Running terraform plan
Applying infrastructure changes safely

I also practiced importing existing infrastructure using terraform import, which demonstrated how real-world systems can be gradually brought under Terraform management without disruption.

After importing, I verified the state using:

terraform plan and terraform show

This confirmed that Terraform correctly recognized the existing infrastructure.

Key takeaway

The biggest challenge in Infrastructure as Code adoption is not technical — it is organizational and cultural.

Common blockers include:

Lack of trust in automation
Dependence on manual cloud operations
Resistance to workflow change
Unclear migration strategy

Adoption strategy that works

A successful IaC rollout should be incremental:

Start with new infrastructure
Gradually import existing resources
Establish team standards (PR reviews, CI checks, version control)
Introduce automation last, after trust is established

Final thought

Infrastructure as Code is not just about automation tools like Terraform.

It is about building repeatable, reliable, and collaborative infrastructure systems.

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