DEV Community: Stephanie Makori

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

Stephanie Makori — Tue, 21 Apr 2026 18:28:18 +0000

Today is Day 30 of the 30-Day Terraform Challenge. I started this journey as someone who understood the concept of Infrastructure as Code but had never written a production Terraform configuration. Today I am finishing as someone who has deployed servers, clusters, databases, static websites, and Kubernetes workloads. I have written automated tests, built CI/CD pipelines, managed state across multiple environments, and understood how infrastructure deployment works at a professional level.

This is my final exam preparation post and my reflection on 30 days of intense, focused learning.

My Final Practice Exam Results

I took five full simulated exams over the past three days. Here is my progression:

Exam	Score	Percentage
Exam 1	38/57	66.7%
Exam 2	43/57	75.4%
Exam 3	46/57	80.7%
Exam 4	49/57	85.9%
Exam 5	51/57	89.5%

The improvement from 66.7% to 89.5% tells me I did not just memorize answers. I actually learned the material. The stability between Exam 4 and Exam 5 shows consolidation, not cramming.

On the final simulated exam, my wrong answers were集中在 Terraform Cloud agent pools, module source version pinning, and the exact behavior of moved blocks. I noted these topics but did not deep dive into new documentation on the last day. That work is done. I trust what I know.

Fill in the Blank Self Test

I tested myself on ten fill in the blank questions. These are harder than multiple choice because you cannot recognize the answer. You have to retrieve it from memory.

Here were my answers before checking any documentation:

fmt
prevent_destroy
workspace
encrypt
set
rm
3.0
existing, managed
.terraform.lock.hcl
myplan.tfplan

All ten were correct.

The ones I hesitated on: number 4 (S3 backend encryption uses encrypt = true, not sse_algorithm) and number 9 (the lock file is .terraform.lock.hcl with the dot at the start). Precision matters on the certification exam. Getting these right from memory tells me my recall is exam ready.

Final Readiness Check

I answered these ten questions cold. No notes. No documentation. No searching.

1. What does terraform init do to your .terraform directory?
It creates or updates the directory, downloading provider plugins and modules specified in the configuration into .terraform/providers and .terraform/modules.

2. What is the difference between terraform.tfstate and terraform.tfstate.backup?
The main state file contains the current mapping of configuration to real infrastructure. The backup file is created automatically before state changing operations and contains the previous state version.

3. Why should you never commit terraform.tfstate to version control?
Because it contains sensitive data in plain text including resource IDs, IP addresses, and potential secrets. Also because team conflicts on state files are unmanageable. Use remote state backends.

4. What does depends_on do and when should you use it?
It creates explicit dependencies when Terraform cannot infer them automatically. Use it only when implicit references are impossible, such as when a resource must exist before another but you do not reference any of its attributes.

5. What is the difference between a variable block and a locals block?
Variables are input parameters set from outside the module. Locals are internal named expressions that cannot be overridden.

6. What happens if you run terraform apply and the state file was modified by another team member since your last terraform plan?
Terraform refreshes the state before applying and detects drift. If conflicts exist, Terraform will error or prompt you to run a new plan.

7. What does the terraform graph command output and what is it used for?
It outputs a Graphviz formatted visualization of the dependency graph. Use it to debug complex dependencies and understand why Terraform plans to destroy and recreate resources.

8. What is the Terraform Registry and what are the three types of things published there?
The Registry is HashiCorp's platform for sharing Terraform components. The three types are providers, modules, and policy libraries (Sentinel).

9. What is the difference between Terraform Cloud and Terraform Enterprise?
Terraform Cloud is HashiCorp's SaaS offering. Terraform Enterprise is the self hosted version that runs in your own infrastructure for air gapped or compliance heavy environments.

10. When a module uses configuration_aliases, what problem does it solve?
It solves the problem of a module needing to use multiple configurations of the same provider, such as creating resources in both us-east-1 and us-west-1 using different aliases of the AWS provider.

I answered all ten correctly without hesitation. I am ready for the exam.

Exam Logistics

My exam is booked for Saturday, 27th May 2024 at 10:00 AM local time. It will be online proctored through the HashiCorp portal.

I have completed the following:

Registered at hashicorp.com/certification
Tested my webcam and microphone
Cleared my desk
Prepared my government ID
Read all exam policies

My score will appear in my Credly account within 24 hours of completion.

30 Day Reflection

The challenge asked me to answer three questions honestly. Here is what I wrote.

What changed?

Not what I learned. What actually changed.

I used to think infrastructure was just servers and networks and maybe some load balancers. Now I know infrastructure is code that demands the same discipline as application code. Version control. Automated testing. Code review. CI/CD pipelines. These are not optional extras for infrastructure. They are the bare minimum.

What changed is my instinct. When I see a manual server setup now, I do not think "that is fine for now." I think "that should be a module." I have internalized that automation is not about saving time today. It is about eliminating entire categories of human error forever. I no longer trust manual processes. I trust code that has been planned, applied, and tested.

What am I most proud of?

Day 19.

I built a complete three tier application deployment using modules I wrote myself. A VPC module. A compute module. A database module. A load balancer module. I wired them all together and ran terraform apply.

I watched 47 resources create in the correct order. No errors. First try.

That was not luck. That was understanding dependency graphs, module composition, and Terraform's execution model well enough to predict exactly what would happen before it happened. That is the moment I stopped being someone learning Terraform and became someone who knows Terraform.

What comes next?

I am joining a small team building a data pipeline platform on AWS. They currently manage infrastructure with bash scripts and manual CloudFormation.

My first project is to migrate their development environment to Terraform. I will implement remote state with DynamoDB locking. I will set up a CI pipeline that runs terraform validate and terraform plan on every pull request. Then I will train the team on the workflow.

The certification is proof of knowledge. The migration is proof of value.

A Message to Future Participants

If you are reading this and considering starting the 30-Day Terraform Challenge, here is what I wish someone had told me on Day 1:

Do not skip the labs.

Watching videos and reading documentation feels productive. It is not the same as running terraform destroy on accident and learning why state management matters. Make your own mistakes. Break things in a development environment. Fix them. Break them again.

The exam tests your knowledge. The challenge builds your capability. They are not the same thing.

Also, the terraform plan output is your best teacher. Read every line. Understand why every plus and minus is there. If you cannot explain a planned change, do not apply it. That discipline will serve you longer than any certification.

Acknowledgments

This challenge was brought to you by AWS AI/ML UserGroup Kenya, Meru HashiCorp User Group, and EveOps. Thank you for making this happen.

What Comes Next For Me

I will take the Terraform Associate certification exam on Saturday. Then I will start that migration project. And then I will keep building.

Terraform is not the end of my learning journey. It is the foundation.

Day 30 complete. Five practice exams. 30 days of builds. Modules, state management, testing, CI/CD, and a full certification prep program.

Now I go pass that exam.

Fine-tuning My Terraform Exam Prep with Practice Exams

Stephanie Makori — Tue, 21 Apr 2026 17:27:57 +0000

Day 29 of My 30-Day Terraform Challenge

Day 29 of my 30-Day Terraform Challenge was focused on measuring how ready I am for the Terraform Associate certification exam. I completed two more full practice exams under timed conditions and compared the results with yesterday's scores to identify my remaining weak areas.

Practice Exam Progress

Here is the score trend across all four exams:

Exam	Score	Percentage
Exam 1	41/57	72%
Exam 2	46/57	81%
Exam 3	47/57	82%
Exam 4	49/57	86%

The results showed steady improvement in both speed and accuracy. Scoring above the passing mark in all four exams gave me confidence that my understanding is improving, but it also highlighted a few areas where I still need review.

Persistent Weak Areas

After reviewing the wrong answers across all four exams, I found that the same topics kept appearing:

Terraform state management
Terraform import
Workspace behavior
Provider version constraints

One of the most common mistakes was confusing terraform state rm with terraform destroy. I now understand that terraform state rm only removes the resource from Terraform state tracking, while terraform destroy removes the actual infrastructure resource.

I also clarified that terraform import adds resources to the state file but does not create the Terraform configuration, which means terraform plan may still show changes after importing.

Hands-On Revision

To strengthen those weak areas, I practiced the commands directly:


bash
terraform state list
terraform state show random_id.test
terraform state rm random_id.test
terraform workspace new dev
terraform workspace list
terraform workspace show

How I Prepared for the Terraform Associate Exam with Practice Questions

Stephanie Makori — Tue, 21 Apr 2026 16:12:19 +0000

As part of my 30-Day Terraform Challenge, Day 28 was all about simulating the real exam environment using timed practice exams and using the results to strengthen weak areas before exam day.

I completed two full 57-question Terraform Associate practice exams, each under a 60-minute time limit, with no reference materials allowed during the session.

Practice Exam Results

Practice Exam 1: 41/57 (72%)
Practice Exam 2: 46/57 (81%)

The second exam score was better than the first, which showed that once I settled into the pace and question style, my performance improved. It also highlighted how important warm-up and time management are before the actual certification exam.

Weak Areas Identified

After reviewing both exams, I found that my weakest domains were:

Terraform Modules
State Management
Terraform Cloud

These sections had the lowest accuracy because the questions were scenario-based and required understanding Terraform behavior rather than memorizing commands.

For example, I missed questions on:

the behavior of terraform state rm
how child modules receive variables
what Terraform Cloud workspaces manage

Reviewing Wrong Answers

Instead of just checking the correct answer, I reviewed why I got each question wrong. This helped me identify reasoning mistakes.

One example was misunderstanding terraform state rm. I initially thought it destroyed the resource, but it only removes the resource from the Terraform state file while leaving the infrastructure intact.

This kind of review made the concepts much clearer than simply rereading notes.

Hands-On Reinforcement

To close the gaps, I practiced the commands I struggled with:


bash
terraform state list
terraform state show aws_instance.web
terraform state mv aws_instance.web aws_instance.app
terraform state rm aws_instance.app

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.