DEV Community: Mary Mutua

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

Mary Mutua — Sat, 02 May 2026 02:14:18 +0000

Day 30 of my 30-Day Terraform Challenge is complete.

This was the final day of the challenge, and the focus was clear: consolidate, assess readiness, and reflect on the full journey.

There was no new infrastructure to deploy today. No new AWS service to debug. No new Terraform module to refactor.

Today was about proving readiness.

After 29 days of building, testing, documenting, troubleshooting, and preparing, I used Day 30 to complete one final simulated exam, test command recall with fill-in-the-blank questions, and assess whether I am ready for the Terraform Associate certification.

GitHub reference:

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

Final Practice Exam

I completed Practice Exam 5 as my final simulated exam.

Result:

57 / 57
100%
Time taken: 45 minutes

This was the strongest possible way to end the practice exam phase.

More importantly, it confirmed that the consistency I saw on Days 28 and 29 was real. My earlier practice exams had already shown strong scores, but this final exam gave me confidence that the core concepts were sticking under timed conditions.

Across the final five practice exams, my trend looked like this:

Exam	Score	Accuracy	Time
Practice Exam 1	54 / 57	94.7%	55 min
Practice Exam 2	56 / 57	98.2%	50 min
Practice Exam 3	56 / 57	98.2%	40 min
Practice Exam 4	56 / 57	98.2%	45 min
Practice Exam 5	57 / 57	100%	45 min

The trend matters more than any single score.

It showed steady performance, comfortable timing, and fewer weak spots by the final day.

Fill-in-the-Blank Review

After the final practice exam, I completed a 20-question fill-in-the-blank review.

Result:

19 / 20
95%

This was useful because fill-in-the-blank questions test recall differently from multiple choice.

With multiple choice, you can sometimes recognize the correct answer. With fill-in-the-blank questions, you have to retrieve it from memory.

The one question I missed was about the S3 backend encryption argument.

I answered:

server_side_encryption_configuration

The correct backend argument is:

encrypt = true

That was a good final reminder: Terraform exam prep is often about precision. server_side_encryption_configuration is related to configuring encryption on an actual S3 bucket resource. The S3 backend uses encrypt.

Small distinction. Important distinction.

Final Readiness Assessment

My final readiness rating is:

Ready

The evidence is clear:

Practice Exam 5: 100%
Fill-in-the-blank review: 95%
Strong score trend across five practice exams
Comfortable timing within the exam window
Remaining weak areas are narrow and specific
Core Terraform workflow, modules, state, providers, lifecycle rules, and HCP Terraform concepts are solid

The only final topics I want to lightly review before the real exam are:

S3 backend encryption: encrypt = true
saved plan staleness
variable precedence
state command distinctions
provider alias usage

At this point, I do not need to learn brand-new material.

I need to stay calm, review lightly, and trust the work.

What Changed Over These 30 Days

This challenge changed how I think about infrastructure.

At the beginning, Terraform was mostly a tool for provisioning cloud resources.

Now I see it differently.

Terraform is not just about creating infrastructure. It is about managing change safely.

That means:

writing infrastructure as code
storing and protecting state
designing reusable modules
isolating environments
reviewing plans before applying
testing infrastructure code
thinking about blast radius
documenting decisions
cleaning up resources responsibly
understanding how teams collaborate around infrastructure

The biggest shift was moving from “Can I make this work?” to “Can I make this safe, repeatable, and understandable?”

That is a very different mindset.

What I Built During the Challenge

Across the 30 days, I worked through a wide range of Terraform and AWS concepts.

Some of the major areas included:

EC2 instances and security groups
Application Load Balancers
Auto Scaling Groups
launch templates
remote state with S3 and DynamoDB
Terraform workspaces and environment isolation
reusable modules
loops and conditionals
zero-downtime deployment patterns
secrets management concepts
multiple providers and provider aliases
Docker and Kubernetes provider usage
production-grade module design
manual and automated testing
Terratest and native terraform test
CI/CD workflow concepts
Sentinel and policy-as-code concepts
static website hosting with S3
scalable web application architecture
multi-region high availability architecture
Terraform Associate exam preparation

That list is long, but the real value was not the number of topics.

The value was seeing how the topics connect.

State affects collaboration. Modules affect maintainability. Testing affects confidence. Provider aliases affect multi-region design. Plans affect safety. Documentation affects whether someone else can understand what was built.

That is what made the challenge feel real.

What I Am Most Proud Of

The part I am most proud of is pushing through the harder practical labs.

Remote state, reusable modules, automated testing, and the multi-region high-availability architecture were not simple checklist items. They required debugging, rethinking, and patience.

The multi-region architecture especially stood out because it brought many earlier lessons together:

provider aliases
region-specific module wiring
networking
load balancing
Auto Scaling
RDS
Route 53 concepts
cleanup and cost awareness

It felt like the kind of work that moves Terraform from tutorial knowledge into real engineering practice.

What This Challenge Taught Me

The biggest lesson is that Terraform is not just syntax.

Syntax matters, but the deeper skill is judgment.

Terraform asks you to think about:

what should be managed
where state should live
how teams should make changes
how to reduce risk
how to recover from mistakes
when to modularize
when not to overcomplicate
how to prove infrastructure works

That is why hands-on practice matters so much.

Reading about Terraform is useful, but building with it every day exposes the real lessons: backend bootstrapping, state locking, provider behavior, naming limits, account restrictions, cleanup order, and the difference between a clean plan and a safe deployment.

What Comes Next

Next, I will take the Terraform Associate certification exam.

After that, the goal is to keep applying these skills in real projects.

I want to continue building infrastructure that is:

reusable
documented
tested
secure
cost-aware
team-friendly

This challenge gave me a strong foundation, but the real value comes from continuing to use it.

Final Takeaway

Day 30 confirmed that I am ready for the Terraform Associate exam.

But more than that, it marked the end of a challenge that changed how I think about infrastructure.

I started by learning Terraform.

I finished by understanding infrastructure delivery more deeply: how to build, review, test, document, and operate infrastructure in a professional way.

The certification is the next milestone.

The real achievement is the confidence and discipline built over 30 days.

Follow My Journey

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

The challenge is complete.

Now it is time to go pass the certification.

Fine-tuning My Terraform Exam Prep with Practice Exams

Mary Mutua — Sat, 02 May 2026 00:44:27 +0000

Day 29 of my 30-Day Terraform Challenge was focused on exam readiness.

There was no new infrastructure to deploy today. Instead, I continued preparing for the Terraform Associate exam by taking two more full practice exams and reviewing the results alongside my Day 28 scores.

The goal was simple: use four practice exams as data.

I wanted to know whether my preparation was consistent, which domains were already strong, and which areas still needed one final review before Day 30.

GitHub reference:

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

The Day 29 folder contains my notes and question sets for Practice Exams 3 and 4.

What I Did Today

Today I completed:

Practice Exam 3
Practice Exam 4
score tracking across all four practice exams
wrong-answer review for today’s exams
domain review using both Day 28 and Day 29 results

I treated both exams as timed simulations and reviewed the missed questions immediately afterward.

This was less about learning new material and more about checking consistency, speed, and exam readiness.

Day 29 Scores

For Practice Exam 3, I scored:

56 / 57
98.2%
Time taken: 40 minutes

For Practice Exam 4, I scored:

56 / 57
98.2%
Time taken: 45 minutes

Both scores were strong and consistent with my Day 28 results.

The main thing I wanted from today was not just another pass. I wanted to see whether my performance stayed steady across multiple attempts.

It did.

Four-Exam Score Trend

After today, I now have four practice exam attempts across Day 28 and Day 29.

Exam	Score	Accuracy	Time
Practice Exam 1	54 / 57	94.7%	55 min
Practice Exam 2	56 / 57	98.2%	50 min
Practice Exam 3	56 / 57	98.2%	40 min
Practice Exam 4	56 / 57	98.2%	45 min

Across all four exams:

Total questions: 228
Correct answers: 222
Overall accuracy: 97.4%

The trend is encouraging.

The first score was already above the passing target, and the next three exams stayed at 98.2%. My timing also improved compared with the first attempt.

That tells me my preparation is stable. I am not relying on one good practice score.

Domain Review Across All Four Exams

I used the Day 28 and Day 29 results to assess my readiness by topic area.

Topic Area	Missed Questions	Assessment
Terraform CLI and workflow	0	Strong
Modules	0	Strong
HCP Terraform / Terraform Cloud	0	Strong
Lifecycle rules	0	Strong
State management and refactoring	1	Light review
Providers and aliases	1	Improved after review
Variables and configuration	2	Main Day 29 review area
IaC concepts and Terraform purpose	2	Light conceptual review

The pattern was clear.

My strongest areas are the Terraform workflow, modules, lifecycle behavior, and HCP Terraform concepts. The areas that need light review are not broad weaknesses. They are specific precision topics.

For Day 29, the main review area was variables and configuration, especially:

custom variable validation
variable value precedence

What Today’s Review Showed Me

The two questions I missed today were both in the variables and configuration area.

That gave me a clear final review target.

The key reminders were:

variable validation checks input values
variable defaults are fallback values
CLI-provided values have higher precedence than defaults and automatically loaded variable files
Terraform language behavior and provider behavior are not the same thing

These are small details, but they are exactly the kind of details that matter in a certification exam.

My Assessment

After four practice exams, I feel much more confident about my readiness.

The scores are consistently above the passing threshold, the timing is comfortable, and the missed questions are concentrated in a few narrow areas.

That is a good sign.

It means I do not need to restart from broad revision. I need one final focused review before Day 30.

My final review areas are:

variable precedence
variable validation
state command distinctions
provider alias usage
Terraform purpose compared with cloud-specific tooling

Final Takeaway

Day 29 helped me move from general preparation to exam readiness assessment.

The biggest win was not only the score. It was the consistency across four exams.

At this stage, my focus is precision:

knowing the exact behavior of Terraform commands
separating similar concepts clearly
reviewing the few domains where mistakes still appeared
staying calm under timed conditions

The four-exam trend shows that the foundation is strong.

Now the work is to sharpen the final details before Day 30.

Follow My Journey

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

See you on Day 30.

How I Prepared for the Terraform Associate Exam with Practice Questions

Mary Mutua — Thu, 30 Apr 2026 20:58:38 +0000

Day 28 of my 30-Day Terraform Challenge was different from the previous days.

There was no new infrastructure to deploy, no AWS resource to troubleshoot, and no module to refactor. The focus shifted from building to proving. After weeks of hands-on Terraform work, I wanted to know whether the concepts were actually sticking under pressure.

So I treated the day like an exam simulation.

The plan was simple:

take two full practice exams
answer 57 questions in each exam
work under timed conditions
avoid looking anything up mid-exam
review every wrong answer properly afterward

This was not casual revision. It was a deliberate test of recall, reasoning, and speed.

GitHub reference:

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

My Scores

I completed two full practice exams.

Practice Exam 1

Score: 54/57
Accuracy: 94.7%

Practice Exam 2

Score: 56/57
Accuracy: 98.2%

What I found interesting was not just that both scores were strong, but that the second one was slightly better.

That told me something useful about how I perform under repetition. Instead of fading, I seemed to settle into the exam rhythm. The warm-up effect was real.

Still, the scores were only part of the story.

The real value of the day came from reviewing the misses.

The Most Valuable Part Was the Wrong-Answer Review

After each exam, I did not want to stop at “correct” or “incorrect.” I wanted to understand the reasoning behind every miss.

For each wrong answer, I reviewed it using this structure:

question topic
what I answered
correct answer
why I was wrong
what I needed to reinforce

That last part mattered a lot.

It is easy to read the correct answer and move on. It is much harder, and much more useful, to identify the real gap in your thinking.

Sometimes the gap is a missing concept.
Sometimes it is misreading the wording.
Sometimes it is mixing up two Terraform features that sound similar but behave differently.

That kind of review is what makes practice exams useful instead of just repetitive.

What I Got Wrong

Across both exams, I only missed a few questions, but they were interesting misses because they were not about broad fundamentals. They were about precision.

Exam 1

I missed questions related to:

immutable infrastructure
CloudFormation vs Terraform provider scope
provider alias syntax

Exam 2

I missed one question related to:

terraform state mv

That pattern actually gave me confidence.

I was not struggling with the main Terraform workflow. I was not missing modules, state concepts, or core CLI usage at a high level. What I needed to sharpen were the finer distinctions that often appear in certification exams.

Those are the kinds of questions that can catch you off guard if you rely only on familiarity instead of understanding.

What Surprised Me

The biggest surprise was not my score. It was which topics felt easiest and which ones still created small mistakes.

My stronger areas were:

Terraform CLI
core workflow
state basics
modules
HCP Terraform / Terraform Cloud
general configuration structure

The weaker spots were much narrower:

immutable vs mutable infrastructure thinking
cloud-specific tooling vs provider-agnostic tooling
exact provider alias usage
state subcommands during refactoring

That was a good reminder that exam readiness is not only about knowing the “big ideas.”

Sometimes the harder questions are the ones that test whether you can clearly separate two concepts that look similar on the surface.

The Hands-On Reinforcement That Helped

I did not want my review to be passive.

Instead of just rereading the answers, I used small practical reinforcements to close the gaps.

Provider alias syntax

One of my misses came from confusing alias declaration with alias usage.

To reinforce it, I went back to the exact pattern:

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

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

resource "aws_s3_bucket" "west_bucket" {
  provider = aws.west
  bucket   = "example-west-bucket-12345"
}

That helped lock in the difference between:

declaring alias = "west" in the provider block
using provider = aws.west inside a resource

That is a small distinction, but it is exactly the kind of thing that can cost points if your memory is fuzzy.

State command review

Another useful review point was around terraform state mv.

That made me revisit the difference between:

terraform import
terraform state mv
terraform state rm

The distinction became much clearer once I framed them by purpose:

terraform import brings existing infrastructure into Terraform state
terraform state mv changes the address of an object Terraform already tracks
terraform state rm removes an object from state without deleting the real resource

That is not just exam trivia. It is practical Terraform knowledge that matters when refactoring real infrastructure.

What This Taught Me About Exam Prep

The biggest lesson from Day 28 was this:

A practice exam is only as valuable as the review that follows it.

A high score can be encouraging, but it is not enough on its own.

What really improves exam readiness is being able to say:

this is what I misunderstood
this is why I misunderstood it
this is how I will stop making the same mistake

That turns a wrong answer into a useful learning asset.

Without that step, practice questions can become little more than scorekeeping.

What Helped Me Most

A few things made this study session much more effective:

answering under timed conditions
not interrupting the exam to look things up
taking two separate full-length practice runs
reviewing the misses immediately afterward
paying attention to whether my second score improved or dropped

That last point was especially helpful.

If the second score had been significantly worse, it would have suggested fatigue. Since it improved, it suggested that a short warm-up before the real exam might actually help me perform better.

That is the kind of insight I would not get from doing random untimed questions here and there.

Final Takeaway

Day 28 was one of the most useful preparation days in the whole challenge because it forced me to move from learning Terraform to testing my command of it.

It reminded me that exam readiness is not just about memorizing commands.

It is about being able to:

reason quickly
separate similar concepts accurately
stay calm under time pressure
review mistakes honestly

The scores were strong, but the biggest win was getting clarity on the few areas that still need sharper recall.

That is what makes practice exams worth doing.

Follow My Journey

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

See you on Day 29.

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

Mary Mutua — Tue, 28 Apr 2026 16:22:42 +0000

Day 27 of my Terraform journey moved from a single-region scalable app to a multi-region high-availability design.

Yesterday, I built a scalable web application in one AWS region. Today, I expanded that pattern into a 3-tier architecture spread across two regions using:

a VPC per region
an ALB per region
an Auto Scaling Group per region
a primary Multi-AZ RDS instance
a cross-region read replica
optional Route53 failover DNS
reusable Terraform modules
remote state with S3 and DynamoDB

GitHub reference:

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

Project Structure

For Day 27, I separated the infrastructure into five focused modules:

day27-multi-region-ha/
├── modules/
│   ├── vpc/
│   ├── alb/
│   ├── asg/
│   ├── rds/
│   └── route53/
├── envs/
│   └── prod/
├── bootstrap/
├── backend.tf
└── provider.tf

The goal was not just to make the stack work.

The goal was to make the design reusable, understandable, and safe to change across regions.

Why Five Modules Instead of One?

I split the project into five modules because each part has a different responsibility.

The vpc module owns networking:

VPC
public subnets
private subnets
internet gateway
NAT gateways
route tables

The alb module owns traffic entry:

Application Load Balancer
target group
listener
ALB security group

The asg module owns compute and scaling:

launch template
instance security group
Auto Scaling Group
scaling policies
CloudWatch CPU alarms

The rds module owns the database layer:

DB subnet group
RDS security group
primary RDS instance
cross-region replica logic

The route53 module owns failover DNS:

health checks
primary failover record
secondary failover record

If everything lived in one large file, it would still work, but it would be harder to reuse and harder to reason about.

Modules make the boundaries clear.

How the Modules Connect

The most important part of today was understanding the data flow between modules.

The VPC modules create the base networking:

module.vpc_primary.vpc_id
module.vpc_primary.public_subnet_ids
module.vpc_primary.private_subnet_ids

module.vpc_secondary.vpc_id
module.vpc_secondary.public_subnet_ids
module.vpc_secondary.private_subnet_ids

Those outputs feed the rest of the stack.

The ALB module in the primary region creates a target group:

module.alb_primary.target_group_arn

That output flows into the primary ASG module:

target_group_arns = [module.alb_primary.target_group_arn]

That tells the Auto Scaling Group where its EC2 instances should register.

Then the RDS primary module creates the main database and outputs:

module.rds_primary.db_instance_arn

That output flows into the replica module:

replicate_source_db = module.rds_primary.db_instance_arn

That tells AWS to create the secondary database as a cross-region read replica of the primary database.

This closes the loop:

VPC → ALB → Target Group → ASG → Primary RDS → Cross-Region Replica

That is what made the architecture feel like one connected system instead of separate AWS resources.

Deployment Output

After applying the Terraform plan, Terraform returned regional ALB DNS names.

I verified the primary ALB in the browser and the app responded with:

Region: us-east-1 | AZ: us-east-1b | Environment: prod

That confirmed the ALB, target group, Auto Scaling Group, and EC2 user data were all working together correctly.

Route53 Failover Design

The Route53 module was included in the project design to support DNS failover between the two regions.

In my actual lab run, I left Route53 disabled because I did not have a hosted zone and domain ready in the account. So I verified the stack through the ALB DNS names directly instead.

Still, the failover behavior is important to understand.

If the primary region fails, the sequence looks like this:

the primary Route53 health check fails
Route53 stops returning the primary record
clients continue using cached DNS until TTL expires
after TTL expiry, new DNS lookups resolve to the secondary record
traffic shifts to the secondary ALB
the secondary ALB continues serving the application tier in the backup region

That means failover is not instant in the same way an internal service failover might be. It depends on:

health check detection
Route53 failover policy
DNS cache expiry

Multi-AZ vs Cross-Region Read Replicas

One of the most useful lessons today was understanding that these solve different problems.

Multi-AZ protects against Availability Zone failure within one region.

If one AZ in us-east-1 fails, AWS can fail the database over to another AZ in that same region.

Cross-region read replicas protect against a full regional outage.

If the primary region has a larger failure, the replica already exists in the secondary region and can become part of the recovery plan.

So the difference is:

Multi-AZ = resilience within a region
cross-region replica = resilience across regions

You need both ideas to think clearly about high availability.

A Useful Debugging Lesson

Day 27 had a few real-world AWS constraints that made the project more realistic.

A few examples:

ALB naming had to be shortened to stay within AWS limits
the RDS module needed the application security group ID, not the ASG name
the cross-region replica needed proper encryption handling to be created from an encrypted source
the backend had to be bootstrapped first before the main environment could use remote state

That was a good reminder that Terraform can describe the architecture, but AWS service rules still matter.

Remote State and Bootstrap

Like previous days, I used a remote backend with:

S3 for Terraform state
DynamoDB for state locking

For this project, I also used a separate bootstrap stack to create the backend resources first.

That mattered because Terraform cannot use a backend bucket and lock table until they already exist.

Remote state keeps the stack safer and more realistic, especially once infrastructure starts growing beyond one simple environment.

Cleanup

After verifying the app worked, I destroyed both:

the Day 27 production stack
the bootstrap backend resources

This matters because NAT Gateways, ALBs, EC2 instances, and RDS resources can keep generating cost even after the learning task is complete.

Final Takeaway

Day 27 helped me connect several Terraform lessons into one practical multi-region system.

A high-availability architecture is not just “more resources.” It is the relationship between networking, load balancing, scaling, database topology, failover strategy, and state management.

The biggest lesson:

Terraform modules are not just for organizing files. They help define the boundaries of responsibility in infrastructure.

That is what makes the system easier to understand, reuse, and safely change.

Follow My Journey

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

See you on Day 28.

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

Mary Mutua — Wed, 22 Apr 2026 22:27:12 +0000

Day 26 of my Terraform journey moved from static hosting to dynamic compute.

Yesterday, I deployed a static website on S3. Today, I built a scalable web application stack on AWS using:

EC2 Launch Template
Application Load Balancer
Auto Scaling Group
CloudWatch alarms
scaling policies
reusable Terraform modules
remote state with S3 and DynamoDB

GitHub reference:

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

Project Structure

For Day 26, I separated the infrastructure into three focused modules:

day26-scalable-web-app/
├── modules/
│   ├── ec2/
│   ├── alb/
│   └── asg/
├── envs/
│   └── dev/
├── bootstrap/
├── backend.tf
└── provider.tf

The goal was not just to make the app work.

The goal was to make the design reusable, understandable, and safe to change.

Why Three Modules Instead of One?

I split the project into three modules because each part has a different responsibility.

The ec2 module owns the compute template:

Launch Template
instance security group
user data script

The alb module owns traffic entry:

Application Load Balancer
target group
listener
ALB security group

The asg module owns scaling:

Auto Scaling Group
scaling policies
CloudWatch CPU alarms
dashboard

If everything lived in one large file, it would still work, but it would be harder to reuse and harder to reason about.

Modules make the boundaries clear.

How the Modules Connect

The most important part of today was understanding the data flow between modules.

The EC2 module creates the launch template:

module.ec2.launch_template_id
module.ec2.launch_template_version

Those outputs flow into the ASG module:

launch_template_id      = module.ec2.launch_template_id
launch_template_version = module.ec2.launch_template_version

That tells the Auto Scaling Group what kind of EC2 instances to launch.

Then the ALB module creates a target group:

module.alb.target_group_arn

That output flows into the ASG module too:

target_group_arns = [module.alb.target_group_arn]

This closes the loop:

EC2 Launch Template → ASG → ALB Target Group → ALB DNS

The ASG creates instances from the launch template, then registers those instances behind the load balancer target group.

Deployment Output

After applying the Terraform plan, Terraform returned the ALB DNS name:

day26-web-alb-dev-400577037.us-east-1.elb.amazonaws.com

When I opened it in the browser, the app responded:

Deployed with Terraform - Day 26
Environment: dev
Served by an Auto Scaling Group behind an Application Load Balancer.

ASG healthy instances screenshot:

[Paste AWS Console screenshot here showing the Auto Scaling Group with healthy instances]

Why health_check_type = "ELB" Matters

One important setting today was:

health_check_type = "ELB"

This tells the Auto Scaling Group to use load balancer health checks, not only EC2 instance status checks.

That matters because an EC2 instance can be “running” but still not serving the application correctly.

With ELB health checks enabled, the ASG checks whether the instance is healthy from the load balancer’s point of view. If the app fails behind the ALB, the ASG can replace the instance.

This is much closer to real production behavior.

What Happens When CPU Exceeds 70%

The ASG module includes CloudWatch alarms and scaling policies.

When average CPU goes above 70%, this happens:

CloudWatch alarm enters ALARM state.
The alarm triggers the scale-out policy.
The scale-out policy increases ASG capacity by 1.
The ASG launches a new EC2 instance using the Launch Template.
The new instance registers with the ALB target group.
The ALB starts sending traffic to the new healthy instance.

That is the feedback loop:

CPU spike → CloudWatch alarm → scaling policy → new EC2 instance → ALB target group

There is also a scale-in policy for low CPU, so the system can reduce capacity when traffic drops.

Remote State

Like previous days, I used a remote backend with:

S3 for Terraform state
DynamoDB for state locking

This prevents local-only state problems and protects against two people applying changes at the same time.

Remote state is one of those things that feels small at first, but it becomes critical as soon as infrastructure work becomes collaborative.

A Useful Debugging Lesson

I hit a Terraform planning issue around for_each.

The lesson was simple but important:

for_each keys must be known during planning.

If Terraform cannot know the keys until apply time, it cannot build the dependency graph safely. The fix was to use stable keys and put dynamic values inside the map values instead.

That was a good reminder that Terraform is very strict about what must be known at plan time.

Cleanup

After verifying the app worked, I destroyed both:

the dev application stack
the bootstrap backend resources

This matters because ALBs and EC2 instances can keep generating cost even after the learning task is complete.

Final Takeaway

Day 26 helped me connect several Terraform lessons into one practical system.

A scalable web application is not just EC2. It is the relationship between compute, networking, health checks, monitoring, scaling policies, and state management.

The biggest lesson:

Terraform modules are not just for organizing files. They help define the boundaries of responsibility in infrastructure.

That is what makes the system easier to understand, reuse, and safely change.

Follow My Journey

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

See you on Day 27.

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

Mary Mutua — Tue, 21 Apr 2026 17:36:12 +0000

Day 25 of my 30-Day Terraform Challenge was a practical build: deploy a static website on AWS using Terraform.

The goal was to apply the habits from the previous days in one small project:

reusable modules
environment separation
remote state
clean variables
consistent tagging
reviewed plans
safe cleanup

GitHub reference:

Day 25 code

What I Built

I built a static website stack with:

an S3 bucket
S3 static website hosting
uploaded index.html and error.html
bucket policy for public website reads
reusable Terraform module
dev environment configuration
remote backend with S3 and DynamoDB
optional CloudFront support

The website was verified through the S3 website endpoint:

http://mary-mutua-day25-static-website-dev-718417034043.s3-website-us-east-1.amazonaws.com

Note: I destroyed the resources after verification to avoid AWS charges.

Project Structure

I used this structure:

day_25/day25-static-website/
├── bootstrap/
│   ├── main.tf
│   ├── outputs.tf
│   └── variables.tf
├── envs/
│   └── dev/
│       ├── backend.tf
│       ├── main.tf
│       ├── outputs.tf
│       ├── provider.tf
│       ├── terraform.tfvars
│       └── variables.tf
└── modules/
    └── s3-static-website/
        ├── main.tf
        ├── outputs.tf
        └── variables.tf

The module lives in:

modules/s3-static-website

The dev environment calls that module from:

envs/dev

This separation matters because the module should be reusable, while the environment folder should contain environment-specific values.

Why I Used a Module

I could have put everything in one main.tf, but that would not scale well.

A module lets me define the static website once and reuse it later for:

dev
staging
production
another website
another AWS account

The module accepts inputs like:

bucket_name
environment
index_document
error_document
tags
enable_cloudfront

Then the dev environment passes values into it:

module "static_website" {
  source = "../../modules/s3-static-website"

  bucket_name       = var.bucket_name
  environment       = var.environment
  index_document    = var.index_document
  error_document    = var.error_document
  enable_cloudfront = var.enable_cloudfront

  tags = {
    Owner = "terraform-challenge"
    Day   = "25"
  }
}

That is the DRY principle in practice: define the infrastructure pattern once, then reuse it with different inputs.

The S3 Website Module

The module creates an S3 bucket:

resource "aws_s3_bucket" "website" {
  bucket        = var.bucket_name
  force_destroy = var.environment != "production"

  tags = local.common_tags
}

The force_destroy setting is useful for dev because it allows Terraform to delete the bucket even when it contains uploaded objects.

But I would not want that behavior in production, so the condition protects production:

force_destroy = var.environment != "production"

The module also enables static website hosting:

resource "aws_s3_bucket_website_configuration" "website" {
  bucket = aws_s3_bucket.website.id

  index_document {
    suffix = var.index_document
  }

  error_document {
    key = var.error_document
  }
}

Then Terraform uploads the HTML files:

resource "aws_s3_object" "index" {
  bucket       = aws_s3_bucket.website.id
  key          = "index.html"
  content_type = "text/html"

  content = <<-HTML
    <!DOCTYPE html>
    <html>
    <head><title>Terraform Static Website</title></head>
    <body>
      <h1>Deployed with Terraform</h1>
      <p>Environment: ${var.environment}</p>
      <p>Bucket: ${var.bucket_name}</p>
    </body>
    </html>
  HTML
}

Remote State

Before deploying the website, I created a remote backend using a bootstrap folder.

That created:

an S3 bucket for Terraform state
a DynamoDB table for state locking
S3 encryption
S3 versioning

Remote state matters because Terraform state is how Terraform tracks real infrastructure. Keeping it locally is risky when working with teams or across machines.

The backend protects the workflow by:

storing state remotely
preventing concurrent changes with locking
keeping state versions for recovery
avoiding local-only state files

One important cleanup lesson: if your state bucket has versioning enabled, deleting the bucket later requires deleting all object versions and delete markers first.

That was a useful real-world reminder.

CloudFront Configuration

The module includes optional CloudFront support:

resource "aws_cloudfront_distribution" "website" {
  count = var.enable_cloudfront ? 1 : 0

  enabled             = true
  default_root_object = var.index_document
  price_class         = "PriceClass_100"

  origin {
    domain_name = aws_s3_bucket_website_configuration.website.website_endpoint
    origin_id   = "s3-website"

    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "http-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }
  }
}

For this lab, CloudFront creation was blocked by AWS account verification.

Terraform and the AWS Console both returned the same issue:

Your account must be verified before you can add new CloudFront resources.

So I disabled CloudFront in dev:

enable_cloudfront = false

The module is still CloudFront-ready, but the working deployment used the S3 website endpoint.

Deployment Commands

From the bootstrap folder, I created the remote backend:

terraform init
terraform validate
terraform plan -out=bootstrap.tfplan
terraform apply bootstrap.tfplan

Then I initialized the dev environment:

terraform -chdir=day_25/day25-static-website/envs/dev init -reconfigure
terraform -chdir=day_25/day25-static-website/envs/dev validate
terraform -chdir=day_25/day25-static-website/envs/dev plan -out=day25.tfplan
terraform -chdir=day_25/day25-static-website/envs/dev apply day25.tfplan

The plan showed:

Plan: 7 to add, 0 to change, 0 to destroy.

After apply, I checked the output:

terraform -chdir=day_25/day25-static-website/envs/dev output -raw website_endpoint

Then I opened the S3 website endpoint in the browser and confirmed the site loaded.

Cleanup

Because this was a lab, cleanup mattered.

I destroyed the website stack first:

terraform -chdir=day_25/day25-static-website/envs/dev plan -destroy -out=day25-destroy.tfplan
terraform -chdir=day_25/day25-static-website/envs/dev apply day25-destroy.tfplan

Then I cleaned up the bootstrap backend after deleting versioned objects from the state bucket.

That final cleanup was a good reminder: production-grade safety features like S3 versioning are excellent, but they also change how cleanup works.

Key Takeaways

Day 25 was not just about S3.

The bigger lessons were:

reusable modules make infrastructure easier to scale
environment folders keep dev/staging/prod cleanly separated
remote state protects collaboration and recovery
saved plans make changes reviewable
cleanup is part of the workflow
real cloud provider account limits can block otherwise-correct Terraform

This was a small project, but it pulled together many best practices from the challenge so far.

Final Thought

A static website may look simple, but deploying it properly with Terraform teaches important infrastructure habits.

The goal is not just to make a page load.

The goal is to make the deployment repeatable, reviewable, reusable, and safe to clean up.

Full Code

GitHub reference:

👉 GitHub Link

Follow My Journey

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

See you on Day 26.

My Final Preparation for the Terraform Associate Exam

Mary Mutua — Tue, 21 Apr 2026 14:32:05 +0000

Day 24 of my 30-Day Terraform Challenge was pure exam preparation.

No new AWS resources.

No new modules.

No new deployments.

Just one goal:

to close the gap between “I understand Terraform” and “I can answer Terraform questions accurately under time pressure.”

After spending the last few weeks building real infrastructure with Terraform, today was about sharpening the details that matter for the Terraform Associate exam.

GitHub reference:

👉 Day 24 GitHub Link

Why Day 24 Was Different

Most of the challenge so far has been hands-on:

EC2
ALBs
Auto Scaling Groups
remote state
modules
testing
GitHub Actions
Terraform Cloud concepts
Sentinel policies
deployment workflows

That hands-on work helped a lot.

But certification exams test precision.

It is not enough to know that Terraform uses state.

You need to know exactly what happens when you run:

terraform state rm
terraform import
terraform init -upgrade
terraform apply -refresh-only

That was the focus for today.

The Resources I Used

For Day 24, I focused on the official HashiCorp exam preparation resources:

Terraform Associate Study Guide

https://developer.hashicorp.com/terraform/tutorials/certification-004/associate-study-004
Official Sample Questions

https://developer.hashicorp.com/terraform/tutorials/certification-004/associate-questions-004
Terraform Associate Review Tutorial

https://developer.hashicorp.com/terraform/tutorials/certification-004/associate-review-004

The official sample questions were especially useful for understanding the style of questions, but they are not a full mock exam. They are more like a format check.

The review tutorial was useful as a checklist of what to study, not as a question bank.

My Exam Simulation Result

I did a 57-question timed simulation based on the official domains and my weak areas from Day 23.

Result:

Total questions: 57
Correct answers: 44
Wrong answers: 13
Score: 77.2%
Passing target: 70%
Result: Pass

That was encouraging.

But more importantly, it showed me exactly where my weak spots were.

Topics I Missed

The questions I missed were not random. They clustered around common exam traps:

.terraform.lock.hcl vs terraform.tfstate
terraform init -upgrade
provider alias syntax
terraform apply -refresh-only
Terraform Cloud vs Terraform Enterprise
backend migration behavior
random_password and secrets in state
terraform state rm vs real infrastructure
terraform import behavior

This was actually good news.

It means the gap is not “I do not understand Terraform.”

The gap is “I need to memorize exact command behavior.”

That is much easier to fix.

The Biggest Exam Traps I Reviewed

1. State vs lock file

This is one of the easiest things to mix up.

terraform.tfstate

Tracks real infrastructure and maps it to Terraform resources.

.terraform.lock.hcl

Tracks provider versions and checksums.

The lock file is about dependency consistency.

The state file is about infrastructure reality.

2. `terraform state rm`

This command does not destroy infrastructure.

It only removes the resource from Terraform state.

So if you run:

terraform state rm aws_instance.web

the EC2 instance still exists in AWS. Terraform just stops managing it.

That is a very exam-friendly trap.

3. `terraform import`

terraform import brings an existing real-world object into Terraform state.

But it does not write the .tf resource block for you.

You still need to write the matching configuration yourself.

4. `terraform apply -refresh-only`

This updates Terraform state to match real infrastructure.

It is not the same as a normal apply.

It is useful when you want Terraform to refresh its understanding of reality without making normal create/update/destroy changes.

5. Sensitive values

This one matters a lot.

sensitive = true

masks values in CLI output.

But it does not guarantee the value is absent from state.

That means state security is still important.

6. Provider aliases

The correct syntax is:

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

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

resource "aws_s3_bucket" "example" {
  provider = aws.west
  bucket   = "example-west-bucket"
}

The key part is:

provider = aws.west

Not alias = aws.west.

My Exam-Day Strategy

The Terraform Associate exam is time-sensitive.

The strategy I am taking is:

Move quickly through easy questions.
Flag uncertain questions.
Do not spend too long on one hard question.
Return to flagged questions at the end.
Watch carefully for wording like “state,” “real infrastructure,” “configuration,” and “select TWO.”
Eliminate obviously wrong answers first.

The biggest reminder for myself:

hard questions and easy questions are worth the same.

So it is better to secure all the easy points first.

The Topics I Will Review Again

Before the exam, I want to revisit:

Terraform state commands
backend migration
provider aliases
HCP Terraform vs Terraform Enterprise
sensitive values in state
terraform init -upgrade
terraform import
terraform apply -refresh-only

These are now my final review targets.

What Helped Most

The most useful preparation was not just reading.

It was combining:

real hands-on Terraform work
official documentation
practice questions
timed simulation
reviewing every wrong answer

The timed simulation was especially helpful because it showed how easy it is to make small mistakes under pressure.

My Main Takeaway

The Terraform Associate exam rewards precise understanding.

It tests whether you know what Terraform does:

to configuration
to state
to real infrastructure
during each command

That precision only comes from practice.

Day 24 gave me a clear picture of where I stand:

I am in passing range, but I still have a few sharp edges to clean up.

And honestly, that feels like a good place to be.

Follow My Journey

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

The book is complete.

The labs are done.

Now the focus is certification readiness.

See you on Day 25.

Preparing for the Terraform Associate Exam - Key Resources and Tips

Mary Mutua — Mon, 20 Apr 2026 12:37:08 +0000

Day 23 of my Terraform journey marked a clear shift.

The book is done.

The labs are running.

The workflows are built.

Now the focus is exam preparation.

For the past three weeks, I have been building real Terraform infrastructure: EC2 instances, load balancers, Auto Scaling Groups, reusable modules, remote state examples, manual tests, Terratest, GitHub Actions, Sentinel policies, and full deployment workflows.

But certification preparation requires a different mindset.

It is not enough to say:

“I have used Terraform.”

The better question is:

“Can I explain what Terraform is doing, why it is doing it, and what happens in edge cases?”

That was the focus of Day 23.

Official study guide:

Terraform Associate 004 Study Guide

Starting With the Official Objectives

The first thing I did was go back to the official HashiCorp Terraform Associate study material.

That matters because the exam is not based on what I personally used most during the challenge.

It is based on the published exam objectives.

Some topics came up almost every day in my hands-on work:

terraform init
terraform plan
terraform apply
variables
outputs
providers
modules
state
remote state
workspaces
lifecycle rules
testing workflows

Other topics appeared less often but are still important for the exam:

terraform state mv
terraform state rm
terraform import
provider aliases
non-cloud providers
HCP Terraform workspaces
Terraform Cloud variable handling
private registry
cost estimation
Sentinel policy concepts

That is why Day 23 was not about deploying another big stack.

It was about auditing what I know honestly.

My Self-Audit Approach

I used a simple Green / Yellow / Red rating system.

Green

I can explain it clearly and I have done it hands-on.

Examples:

core Terraform workflow
modules
variables and outputs
terraform plan
terraform apply
remote state concepts
GitHub Actions workflow basics

Yellow

I understand it conceptually, but I need more practice.

Examples:

state subcommands
provider alias syntax
complex Terraform functions
non-cloud providers
import edge cases

Red

I am not confident enough yet and need focused study.

For me, the closest Red/Yellow area is HCP Terraform detail.

I understand the purpose, but I still need to review:

remote runs vs local runs
HCP Terraform workspaces vs CLI workspaces
variable sets
Sentinel policy timing
private registry behavior
cost estimation limitations

The biggest benefit of this audit was clarity.

Instead of saying “I need to study Terraform,” I now know exactly what to study.

The Areas I Found Most Challenging

The hardest areas are not the big visible Terraform commands.

They are the small operational details.

1. State Commands

This is one section I think many people underestimate.

Commands like these matter:

terraform state list
terraform state show
terraform state mv
terraform state rm
terraform import

The exam can ask scenario-based questions such as:

“What happens when you run terraform state rm?”

The answer is important:

terraform state rm removes the resource from Terraform state only.

It does not destroy the real infrastructure.

That distinction is exactly the kind of thing the exam tests.

2. Provider Aliases

Provider aliases are easy to understand, but the syntax needs to be familiar.

Example:

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

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

resource "aws_s3_bucket" "west_bucket" {
  provider = aws.west
  bucket   = "example-west-bucket"
}

The key idea:

Terraform uses the default provider unless you explicitly tell a resource or module to use an aliased provider.

3. HCP Terraform

HCP Terraform is another area I want to review carefully.

The exam expects you to understand concepts like:

remote execution
workspace variables
sensitive variables
environment variables
private registry
policy enforcement
cost estimation
team workflows

Even if you mostly use local Terraform or an S3 backend, these concepts are still exam material.

4. Non-Cloud Providers

Terraform is not only for AWS, Azure, or Google Cloud.

It also has providers like:

resource "random_id" "example" {
  byte_length = 8
}

resource "local_file" "example" {
  content  = "Hello from Terraform"
  filename = "${path.module}/output.txt"
}

This is a good exam reminder:

A Terraform provider is a plugin that exposes resource types.

It does not have to manage a cloud platform.

My Study Plan Structure

Instead of creating a vague study plan like:

“Review Terraform state”

I made the plan action-based.

For example:

Topic	Confidence	Study Method	Time
State commands	Yellow	Run `state list`, `state show`, `state mv`, `state rm`, and `import` on test resources	60 min
HCP Terraform	Yellow/Red	Review workspaces, variable sets, remote runs, policies, and registry	75 min
Provider aliases	Yellow	Write one AWS alias example and one module provider mapping example	30 min
Non-cloud providers	Yellow	Create a tiny `random` + `local_file` config	30 min
Complex types/functions	Yellow	Practice maps, objects, `for`, `merge`, `lookup`, `toset`, and splats	45 min
Official sample questions	Yellow	Complete questions and explain wrong answers	45 min

That kind of plan is much easier to follow because every study block has an output.

CLI Commands People Underestimate

If there is one section I would tell people not to ignore, it is the Terraform CLI.

Most people remember:

terraform init
terraform plan
terraform apply
terraform destroy

But the exam also expects you to understand commands like:

terraform fmt
terraform validate
terraform output
terraform state list
terraform state show
terraform state mv
terraform state rm
terraform import
terraform workspace
terraform providers
terraform login
terraform graph

The important thing is not just memorizing command names.

You need to know what they affect.

For example:

terraform fmt changes formatting only
terraform validate checks configuration, not live infrastructure health
terraform state rm removes something from state, not from AWS
terraform import adds an existing object to state but does not write a full configuration for you
terraform graph outputs a dependency graph
terraform login authenticates the CLI to HCP Terraform

Those details matter.

Practice Questions Help More Than Passive Reading

I also worked through the official sample questions and wrote a few of my own.

Writing your own questions is surprisingly useful because it forces you to understand the material well enough to create plausible wrong answers.

Example:

Question:

A saved Terraform plan becomes stale. What should you do?

Answer:

Regenerate the plan, review it again, then apply the new saved plan.

That question came directly from something I experienced during the challenge.

That is the best kind of study material: real mistakes turned into exam memory.

My Biggest Exam Prep Takeaway

The Terraform Associate exam is not only about knowing how to write .tf files.

It tests whether you understand the Terraform workflow.

That means knowing:

what Terraform reads
what Terraform writes
when state changes
when real infrastructure changes
how providers are selected
how modules are sourced
how Terraform Cloud changes the workflow
what each CLI command actually does

That is why hands-on practice matters so much.

Reading alone is not enough.

Final Tips

If you are preparing for the Terraform Associate exam, my advice is:

Start with the official study guide.
Audit yourself honestly.
Do not skip state commands.
Practice provider aliases.
Review HCP Terraform even if you do not use it daily.
Learn what each CLI command changes.
Turn your own mistakes into practice questions.
Keep your study plan specific and time-boxed.

Official Resource

Terraform Associate 004 Study Guide:

https://developer.hashicorp.com/terraform/tutorials/certification-004/associate-study-004

Official Sample Questions:

https://developer.hashicorp.com/terraform/tutorials/certification-004/associate-questions-004

Full Notes

GitHub Day 23:

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

Follow My Journey

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

See you on Day 24.

Putting It All Together: Application and Infrastructure Workflows with Terraform

Mary Mutua — Fri, 17 Apr 2026 13:36:09 +0000

Day 22 of my Terraform journey felt like a checkpoint.

After three weeks of building infrastructure, testing modules, writing workflows, using GitHub Actions, working with Terraform plans, and learning about Terraform Cloud, this day brought everything together.

The focus came from Chapter 10 of Terraform: Up & Running by Yevgeniy Brikman: how application delivery and infrastructure delivery can follow the same disciplined workflow.

The big lesson was this:

Infrastructure should not be deployed casually.

It should move through the same kind of process we already expect from application code:

version control
pull request review
automated checks
immutable artifacts
policy enforcement
controlled deployment
verification
rollback planning

For Day 22, I built a standalone staging webserver cluster and wired it into an integrated Terraform workflow.

GitHub reference:

Day 22 Code

The Integrated Pipeline

The goal was to combine the application workflow and infrastructure workflow into one complete delivery process.

For application code, a team might produce a Docker image or binary as the build artifact.

For infrastructure code, the equivalent artifact is a saved Terraform plan file.

That was the main idea I practiced today.

My Day 22 workflow looked like this:

Write Terraform code in Git.
Open a pull request.
Run automated checks.
Generate a saved Terraform plan.
Upload the plan as a CI artifact.
Review the plan, blast radius, and rollback notes.
Merge the PR.
Apply the reviewed plan.
Verify the infrastructure.
Destroy the lab resources after testing.

The GitHub Actions workflow had two main jobs.

The first job handled validation:

- terraform fmt -check -recursive
- terraform init -backend=false
- terraform validate
- terraform test

The second job handled planning:

terraform plan -out=ci.tfplan

Then the workflow uploaded the plan file as an artifact.

That is important because the plan becomes the thing reviewers inspect before apply.

What I Deployed

For Day 22, I created a standalone staging stack under:

day_22/live/staging

The stack used reusable modules under:

day_22/modules

The plan showed:

Plan: 16 to add, 0 to change, 0 to destroy.

The resources included:

Application Load Balancer
ALB listener and listener rule
Target group
Auto Scaling Group
Launch template
Security groups and rules
SNS topic
CloudWatch CPU alarm
CloudWatch ASG capacity alarm

After applying the reviewed plan, the application returned:

Hello from Day 22 integrated workflow

That confirmed the workflow moved from PR review to real AWS infrastructure successfully.

Immutable Artifact Promotion

This was the most important concept for me today.

In application delivery, teams often build one artifact and promote it through environments.

For example:

Docker image v1.5.0 -> staging -> production

The artifact does not change between environments. That makes releases predictable.

Terraform has a similar idea:

terraform plan file -> review -> apply

The saved plan file represents the exact infrastructure changes Terraform intends to make.

Instead of running a fresh, unreviewed apply, we apply the saved plan:

terraform plan -out=day22-reviewed.tfplan
terraform apply day22-reviewed.tfplan

That means what was reviewed is what gets applied.

One important lesson: saved plans can become stale.

If Terraform says:

Saved plan is stale

that is not a failure. It is Terraform protecting you.

It means the state changed after the plan was created, so Terraform can no longer guarantee that the plan still matches reality. The right fix is to regenerate the plan, review it again, and apply the new saved plan.

That safety check is exactly why plan files matter.

Pull Request Review for Infrastructure

For application code, reviewers usually inspect a code diff.

For infrastructure code, the code diff is not enough.

A Terraform PR should also include:

plan summary
resources created, changed, and destroyed
blast radius
rollback plan
test results

For Day 22, the PR stated:

Created: 16
Modified: 0
Destroyed: 0

The blast radius was low because the stack was standalone and used Day 22-specific names, tags, and state.

The rollback plan was simple:

terraform -chdir=day_22/live/staging destroy

That may sound basic, but writing it down matters.

Infrastructure reviews should answer one question clearly:

“If this goes wrong, what is affected and how do we recover?”

Sentinel Policies

Sentinel is Terraform Cloud’s policy-as-code framework.

Terraform validation checks whether the code is syntactically and structurally valid.

Sentinel checks whether the plan is allowed according to organizational rules.

That distinction clicked for me today.

A Terraform configuration can be valid but still unsafe.

For Day 22, I added Sentinel policy examples for three controls.

1. Allowed instance types

This policy prevents teams from using instance types outside an approved list.

Example intent:

Allow: t2.micro, t2.small, t2.medium, t3.micro, t3.small
Block: larger or unapproved instance types

This helps control cost and standardize infrastructure.

2. Required tags

This policy enforces tagging, especially:

ManagedBy = terraform

That matters because tags help with:

ownership
cost tracking
cleanup
audits
identifying Terraform-managed resources

3. Cost estimation gate

I also added a cost policy example that blocks applies if the monthly increase is above a threshold.

Example threshold:

maximum_monthly_increase = 50.0

This turns cost awareness into a deployment control.

It is not just “we hope this does not cost too much.”

It becomes:

“This apply cannot proceed if it exceeds the approved cost increase.”

That is a powerful guardrail.

Where Application and Infrastructure Workflows Align

By Day 22, the similarities were clear.

Both workflows need:

Git as the source of truth
pull request review
automated testing
versioned releases
promotion through environments
deployment verification

This makes Terraform feel less like a separate special process and more like mature software delivery.

Where They Differ

The differences are where infrastructure gets serious.

Application code usually produces a running service or artifact.

Terraform changes real cloud resources.

That means:

state must be protected
plans must be reviewed
applies need controlled execution
destructive changes need extra approval
rollback may not be instant
tests may create real resources and cost money

A bad application deploy may return a 500 error.

A bad infrastructure deploy can delete a database, expose a service publicly, or break networking.

That is why infrastructure delivery needs more discipline, not less.

What Clicked for Me

The biggest mental shift was this:

Terraform is not just about creating infrastructure.

Terraform is about creating a safe system for changing infrastructure.

Before this challenge, it was easy to think of Terraform as a provisioning tool.

Now I see it more as a workflow tool.

The real value is not only in writing .tf files. It is in the process around them:

plan before apply
review the plan
document blast radius
test what can be tested
protect state
apply from trusted environments
verify cleanup

That is what makes infrastructure reliable.

What Broke

A few things broke along the way.

Provider setup sometimes failed because plugins had to initialize correctly.

Saved plans became stale when state changed after the plan was created.

GitHub PR formatting also reminded me that documentation matters. If plan output or commands are hard to read, reviewers cannot review properly.

Even code block formatting in a PR matters when the goal is making infrastructure changes understandable.

The fix was always the same pattern:

slow down
inspect the actual error
regenerate or re-run safely
document what happened

What Surprised Me

The biggest surprise was how much of Terraform maturity is not Terraform syntax.

It is engineering discipline.

The harder parts were:

deciding what belongs in a module
thinking about state boundaries
writing useful PR descriptions
knowing when a test should be manual, unit, integration, or end-to-end
cleaning up every test run properly
explaining blast radius clearly

Those are the skills that turn Terraform from “scripts that create AWS resources” into real Infrastructure as Code.

Reflection on the Journey So Far

In 22 days, I moved through a lot:

EC2
security groups
load balancers
Auto Scaling Groups
remote state
workspaces
reusable modules
provider aliases
multiple environments
secrets handling
production-readiness checks
manual testing
Terratest
GitHub Actions
deployment workflows
Sentinel policies
cost gates

But the real progress was not the number of resources created.

The real progress was learning how to think.

I now think more carefully about:

what changes
who reviews it
where state lives
what happens if apply fails
what gets destroyed
how cleanup is verified
whether a future engineer can understand the workflow

That is the point of Infrastructure as Code.

Not just automation.

Repeatable, reviewable, explainable infrastructure.

Final Takeaway

Day 22 tied the whole book together for me.

Application code and infrastructure code can follow the same delivery philosophy:

reviewed change -> tested artifact -> controlled deployment -> verified result

But infrastructure needs additional safeguards because the blast radius is bigger.

The winning pattern is not “move fast and apply.”

It is:

plan carefully
review clearly
enforce policy
apply intentionally
verify everything

That is the kind of Terraform workflow I want to keep building.

Full Code

GitHub reference:

Day 22 Code

Follow My Journey

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

See you on Day 23.

A Workflow for Deploying Infrastructure Code with Terraform

Mary Mutua — Thu, 16 Apr 2026 00:27:27 +0000

Day 21 of my Terraform journey focused on a workflow that looks familiar at first, but carries a much bigger blast radius than normal application code deployment.

In Chapter 10 of Terraform: Up & Running, Yevgeniy Brikman explains that infrastructure code can follow the same release shape as application code:

branch, review, test, merge, release, deploy.

But infrastructure code has extra risks.

A bad application deploy might return a 500 error.

A bad infrastructure deploy can break networking, remove a load balancer, corrupt state, or destroy critical resources.

That is why Terraform needs more than good code.

It needs a safe deployment workflow around the code.

For Day 21, I deployed a real infrastructure change end-to-end: adding a CloudWatch alarm to a webserver Auto Scaling Group.

GitHub reference:

👉 Day 21 Code

The Infrastructure Change

I created a standalone Day 21 environment and added a CloudWatch alarm that watches the number of healthy in-service instances in my Auto Scaling Group.

The alarm monitors:

AWS/AutoScaling
GroupInServiceInstances

It fires when the ASG has fewer in-service instances than expected.

This was a good infrastructure workflow change because it was useful, but controlled. It improved observability without changing routing, instance capacity, databases, or production resources.

Step 1: Version Control

I started with a feature branch:

git checkout -b add-cloudwatch-alarms-day21

This keeps infrastructure changes reviewable before they touch real cloud resources.

One key lesson from today: branches are good for review, but shared environments should be applied only after merge. Applying stale feature branches to real environments can accidentally undo someone else’s infrastructure change.

Step 2: Run Locally With Terraform Plan

For application code, “run locally” might mean starting the app.

For Terraform, the equivalent is running a plan.

You are not running the infrastructure locally. You are asking Terraform:

“What would you change in the real cloud environment?”

I ran:

terraform -chdir=day_21/live/dev plan -out=day21.tfplan

The plan showed:

Plan: 16 to add, 0 to change, 0 to destroy.

That summary matters.

It told me Terraform would only create new Day 21 dev resources. No existing resources would be changed or destroyed.

Step 3: Make the Infrastructure Change

The main change was this CloudWatch alarm:

resource "aws_cloudwatch_metric_alarm" "asg_capacity_low" {
  alarm_name          = "${var.cluster_name}-${random_id.suffix.hex}-asg-capacity-low"
  alarm_description   = "Alerts when the ASG has fewer in-service instances than expected."
  namespace           = "AWS/AutoScaling"
  metric_name         = "GroupInServiceInstances"
  statistic           = "Average"
  period              = 60
  evaluation_periods  = 1
  threshold           = var.desired_capacity
  comparison_operator = "LessThanThreshold"
  treat_missing_data  = "breaching"
  alarm_actions       = [module.webserver_cluster.alerts_topic_arn]

  dimensions = {
    AutoScalingGroupName = module.webserver_cluster.asg_name
  }

  tags = merge(local.common_tags, {
    Name = "${var.cluster_name}-asg-capacity-low"
  })
}

This detects when the ASG is not maintaining the expected number of healthy instances.

Step 4: Submit for Review

This is where infrastructure code differs from application code.

For app code, reviewers often focus on the code diff.

For Terraform, reviewers need the code diff and the plan output.

The plan is the real infrastructure preview. It shows what Terraform will actually create, change, or destroy.

In my PR, I included the plan summary:

Plan: 16 to add, 0 to change, 0 to destroy.

I also documented the two sections that are easy to skip but very important: blast radius and rollback plan.

Blast Radius

Blast radius explains what could be affected if the apply goes wrong.

For this change, the blast radius was low:

This creates a standalone Day 21 dev webserver stack and adds a CloudWatch alarm for ASG capacity. It does not modify older day folders, production resources, existing routing, existing security groups, existing databases, or existing capacity.

If the apply failed halfway, the likely impact would be partial Day 21 dev resources such as:

ALB
ASG
security groups
CloudWatch alarms

Existing infrastructure should not be affected because the lab used separate Day 21 names, tags, and Terraform workspace state.

This is one of the biggest Day 21 lessons for me: an infrastructure PR should not only say what changed. It should also say what could break.

Rollback Plan

The rollback plan was documented before deployment:

If the apply causes issues, revert the PR and apply the reviewed rollback plan.

Because this was a standalone dev lab, the fastest cleanup path was:

terraform -chdir=day_21/live/dev destroy

Rollback planning matters because infrastructure does not always roll back cleanly like application code. Sometimes rollback means reverting code. Sometimes it means restoring state. Sometimes it means manual cleanup.

The worst time to decide that is during an incident.

Step 5: Run Automated Tests

The PR ran GitHub Actions checks.

For Day 21, the workflow ran:

terraform fmt -check -recursive day_21
terraform validate
terraform test

The native Terraform tests passed:

4 passed, 0 failed

These tests were intentionally fast. Day 21 was not about re-running expensive end-to-end tests. It was about building a safe infrastructure deployment workflow.

The real AWS verification happened after the reviewed apply.

Step 6: Merge and Release

After the PR checks passed, I merged the PR and tagged the release:

git tag -a "v1.4.0" -m "Add ASG capacity alarm for Day 21 infrastructure workflow"
git push origin v1.4.0

For application code, the release artifact might be a Docker image.

For Terraform, the Git commit or module tag becomes the release artifact. That makes infrastructure changes traceable.

Step 7: Deploy

The safest approach is to apply a saved plan:

terraform apply day21.tfplan

But I hit an important real-world Terraform lesson:

Error: Saved plan is stale

This means the plan was created against an older state snapshot. Terraform could no longer guarantee that applying it would match the current state.

That is a safety feature, not a failure.

The fix was to create a new saved plan from the current state:

terraform -chdir=day_21/live/dev plan -out=day21-reviewed.tfplan

I confirmed the new plan still matched the reviewed intent:

Plan: 16 to add, 0 to change, 0 to destroy.

Then I applied the regenerated saved plan:

terraform -chdir=day_21/live/dev apply day21-reviewed.tfplan

That kept the workflow disciplined: even after the stale-plan issue, I still applied a reviewed saved plan instead of running a plain terraform apply.

Verification

After apply, I verified the application through the ALB:

curl -s http://$(terraform -chdir=day_21/live/dev output -raw alb_dns_name)

The response confirmed the app was live:

Hello from Day 21 infrastructure workflow

Then I verified the CloudWatch alarm existed:

aws cloudwatch describe-alarms \
  --alarm-names "$(terraform -chdir=day_21/live/dev output -raw asg_capacity_alarm_name)" \
  --query "MetricAlarms[*].[AlarmName,Namespace,MetricName,Threshold,ComparisonOperator,StateValue]" \
  --output table

The alarm was created against:

AWS/AutoScaling
GroupInServiceInstances
LessThanThreshold

Finally, I ran another plan:

terraform -chdir=day_21/live/dev plan

Terraform returned:

No changes. Your infrastructure matches the configuration.

That confirmed Terraform state and AWS matched after apply.

Cleanup

Because this deployed real AWS resources, cleanup was part of the workflow.

terraform -chdir=day_21/live/dev destroy

After destroy, I verified that no active Day 21 resources remained.

Cleanup is not an afterthought. It is part of testing infrastructure safely.

Infrastructure Safeguards That Application Code Usually Does Not Need

Day 21 made the infrastructure-specific safeguards very clear.

Saved plans

A saved plan helps ensure that what gets applied is what was reviewed.

terraform plan -out=reviewed.tfplan
terraform apply reviewed.tfplan

State protection

Terraform state represents real infrastructure. If state is wrong, Terraform’s view of the world is wrong.

That is why remote state, locking, and state backups matter.

Destructive-change approval

Any plan with destroys deserves extra attention.

Plan: 0 to add, 2 to change, 1 to destroy

That should trigger a deeper review before apply.

Blast radius documentation

Every infrastructure PR should explain what could be affected if the change fails.

This is especially important for shared resources like:

VPCs
security groups
IAM roles
databases
load balancers

Rollback plan

A rollback plan should exist before apply.

If something breaks, the team should already know whether the rollback is:

revert the PR
apply a previous plan
restore state
restore from backup
manually clean up partial resources

Sentinel as the Enforcement Layer

Sentinel is Terraform Cloud’s policy-as-code framework.

terraform validate checks whether Terraform code is valid.

Sentinel checks whether a valid plan is allowed by policy.

For Day 21, I added a Sentinel policy that only allows approved EC2 instance types:

import "tfplan/v2" as tfplan

allowed_instance_types = ["t2.micro", "t2.small", "t2.medium", "t3.micro", "t3.small"]

main = rule {
  all tfplan.resource_changes as _, rc {
    rc.type is not "aws_instance" or
    rc.change.after.instance_type in allowed_instance_types
  }
}

This means a plan could be syntactically correct, but still blocked because it violates infrastructure policy.

That is the difference between validation and governance.

My Main Takeaway

The infrastructure workflow looks similar to the application workflow:

branch
plan
review
test
merge
release
deploy

But infrastructure needs stronger safeguards because the consequences are different.

The biggest lesson from Day 21 was this:

the Terraform plan is not just a command output.

It is the review artifact, the safety checkpoint, and the bridge between code and real cloud changes.

Good infrastructure deployment is not just terraform apply.

It is plan, review, blast-radius thinking, rollback planning, policy checks, verification, and cleanup.

That is what turns Terraform code into safe infrastructure engineering.

GitHub reference:

👉 Day 21 Code

Follow My Journey

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

See you on Day 22.

A Workflow for Deploying Application Code with Terraform

Mary Mutua — Mon, 13 Apr 2026 21:10:05 +0000

Day 20 of my Terraform journey focused on one practical question from Chapter 10 of Terraform: Up & Running by Yevgeniy Brikman:

How do we apply the same trusted release workflow used for application code to infrastructure code?

I walked through the full 7-step workflow using my Day 20 webserver cluster update, from local change to PR to deploy and cleanup.

Why this matters

Most teams already trust an app-code workflow:

branch
review
tests
merge
release
deploy

Terraform should follow the same discipline.

The big difference is that infrastructure changes can create, modify, or destroy real cloud resources, so review and execution controls matter even more.

Step 1: Use version control

I kept all Terraform code in Git and worked through a feature branch instead of changing main directly.

Example branch:

git checkout -b update-app-version-day20

Goal: every infrastructure change is traceable, reviewable, and reversible.

Step 2: Run locally first

I made a small, intentional app change in Terraform by updating the user-facing response text from:

Hello from Day 20 v2 to
Hello from Day 20 v3

Then I generated a reviewed plan:

terraform -chdir=day_20/live/dev validate
terraform -chdir=day_20/live/dev plan -out=day20.tfplan

Result:

validate passed
plan file saved (day20.tfplan)
summary showed expected create actions only (15 to add, 0 to change, 0 to destroy)

Key habit: do not apply unreviewed changes.

Step 3: Make and commit the change

After confirming the local plan, I committed on the feature branch and pushed for review.

git add .
git commit -m "Day 20: update app response to v3 and simulate deployment workflow"
git push origin update-app-version-day20

Step 4: Submit for review (PR)

In the PR, I included the rendered plan output so reviewers could see exactly what Terraform would do before merge.

terraform -chdir=day_20/live/dev show -no-color day20.tfplan

This is the infrastructure equivalent of reviewing a code diff, but with cloud-impact context.

Step 5: Run automated tests

For this workflow, unit tests ran via GitHub Actions on PR, and passed.

I also ran local module unit tests:

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

Result:

4 passed, 0 failed

Important note: native terraform test can live next to the module in .tftest.hcl.

You do not need a separate test/ folder for this layer.

Step 6: Merge and release

After checks passed, the PR merged into main.

Release tagging is the same idea as app releases:

git tag -a "v1.3.0" -m "Update app response to v3"
git push origin v1.3.0

Tags make rollout points explicit and easier to audit.

Step 7: Deploy and verify

I applied the reviewed plan and verified the live result.

terraform -chdir=day_20/live/dev apply day20.tfplan
curl -s http://$(terraform -chdir=day_20/live/dev output -raw alb_dns_name)

Live response:
Hello from Day 20 v3

Then I destroyed resources and verified cleanup to avoid cost leaks.

Where app and infra workflows align

Both workflows use:

Git branches
PR review
automated checks
merge + release tags
controlled deployment

This alignment is what makes Terraform adoption easier in teams.

Where they diverge

Infrastructure adds constraints app workflows usually do not have:

State management

Terraform state is critical and must be protected (not committed to Git).
Plan-as-review artifact

Reviewing .tf alone is not enough. Reviewers need plan output.
Real cloud blast radius

Tests and applies can create paid resources and cause outages if unmanaged.
Trusted apply environment

terraform apply should run from controlled environments with locking and auditability.

Terraform Cloud variable management: the hidden win

One of the most useful lessons is variable security in Terraform Cloud.

Instead of credentials on laptops, store:

AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as sensitive environment variables
Terraform inputs (cluster_name, instance_type, environment) as workspace variables

This gives:

safer secret handling
consistent runs
better audit trails
less “works on my machine” behavior

Terraform Cloud private registry: another underrated feature

Many teams miss this.

By publishing internal modules (for example terraform-aws-webserver-cluster) to Terraform Cloud private registry, you get:

versioned internal modules
central documentation
consistent reuse across teams
cleaner source references

Example module source pattern:

source  = "app.terraform.io/<org>/webserver-cluster/aws"
version = "1.0.0"

This is a big step from one-off copy-paste module usage to real platform engineering.

Final takeaway

Terraform works best when it follows the same release discipline as application code.

The 7-step workflow is not just process overhead. It is what makes infrastructure safer, reviewable, and team-friendly at scale.

Day 20 made that practical for me: plan-first review, automated checks, controlled merge, verified deploy, and explicit cleanup.

Code Reference

GitHub (Day 20):
👉 Github Link

Follow My Journey

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

See you on Day 21 🚀

How to Convince Your Team to Adopt Infrastructure as Code

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

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

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

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

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

1. Start With the Business Case, Not the Tool

The biggest mistake is leading with Terraform features.

What leadership really cares about:

fewer incidents
less downtime
predictable releases
auditability

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

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

So the argument is not “Terraform is cool.”

The argument is:

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

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

2. Adopt Incrementally, Not All at Once

Big‑bang migrations almost always fail.

The safer strategy is incremental:

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

A simple first win would be:

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

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

3. Give the Team Time and Safety to Learn

IaC fails when only one person knows how it works.

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

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

To avoid that:

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

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

4. Common Failure Modes to Avoid

These are the patterns that keep showing up:

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

The fix is always the same:

smaller steps
clearer training
consistent team practices

A 4‑Phase Adoption Plan That Works

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

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

Low risk, clear win.

Phase 2 - Import existing infrastructure

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

Phase 3 - Establish team practices

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

Phase 4 - Automate deployments

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

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

Final Thought

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

Start with the biggest pain the team is already feeling.

Solve that one problem with IaC.

Then repeat.

That is how real adoption starts.

GitHub (Day 19):

👉 Github Link

Follow My Journey

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

See you on Day 20.