DEV Community: Atul Vishwakarma

From Zero to Infrastructure-as-Code Hero: My 30-Day Terraform Journey

Atul Vishwakarma — Wed, 29 Apr 2026 07:18:55 +0000

After 30 days of consistent learning, building, breaking, and debugging… I’ve officially completed the 30 Days of AWS Terraform Challenge.

What started as a curiosity about Infrastructure as Code (IaC) has evolved into a deep, hands-on understanding of how modern cloud systems are designed, automated, and maintained.

This isn’t just a completion post—it’s a reflection on what it really takes to go from beginner to confident practitioner in Terraform and DevOps.

🌍 Why Terraform?

In today’s cloud-first world, managing infrastructure manually is:

❌ Error-prone
❌ Hard to scale
❌ Nearly impossible to audit

Terraform changes that by enabling:

✅ Declarative infrastructure
✅ Version-controlled environments
✅ Repeatable deployments

But more importantly, it introduces a mindset shift:

Treat infrastructure like application code.

📈 The Journey: From Basics to Production-Grade Systems

🔹 Phase 1: Foundations (Days 1–10)

I started with:

Providers & resources
State files
Basic AWS services (EC2, S3, IAM)

💡 Key realization:
Terraform isn’t just about creating resources—it’s about managing their lifecycle.

🔹 Phase 2: Scaling & Logic (Days 11–20)

This is where things got interesting:

Expressions & Functions → dynamic configurations
Meta-arguments (count, for_each) → scalable infrastructure
Modules → reusable and clean architecture
Provisioners → bootstrapping resources

💡 Key realization:
Clean, modular code is the difference between a demo and production-ready infrastructure.

🔹 Phase 3: Real-World Architectures (Days 21–28)

Here’s where theory met reality:

🏗️ 2-tier & 3-tier architectures
🌐 VPC design with public/private subnets
⚖️ Load Balancers + Auto Scaling
🔐 IAM policies & governance
📊 Observability with CloudWatch

💡 Key realization:
Infrastructure is not about individual services—it’s about how they work together.

🔹 Phase 4: DevOps Maturity (Days 29–30)

The final stretch focused on automation and reliability:

🔁 GitOps with ArgoCD

Self-healing Kubernetes deployments
Git as single source of truth

🔍 Drift Detection (Final Milestone)

Using:

terraform plan -detailed-exitcode

I built a pipeline that:

Detects infrastructure drift
Automatically remediates it
Notifies the team

💡 This was the biggest “aha” moment:

Infrastructure that fixes itself is the end goal.

🧠 Key Skills I Gained

✅ Infrastructure Design

High availability architectures
Secure networking (NAT, private subnets)
Scalable systems (ASG + ALB)

✅ Terraform Mastery

Modules & reusability
Remote state management (S3 + DynamoDB)
Data sources & dynamic blocks

✅ DevOps Automation

CI/CD with GitHub Actions
GitOps workflows
Drift detection pipelines

✅ Security & Governance

IAM best practices
Policy enforcement
Secrets management awareness

⚠️ Challenges Along the Way

This journey wasn’t smooth—and that’s the point.

Some real struggles:

Debugging Terraform state issues
Handling provider deprecations
Fixing networking misconfigurations
Understanding IAM policy conflicts

💡 Lesson learned:

Debugging is where real learning happens.

🔄 What Changed for Me

Before this challenge:

I knew how to create resources

Now:

I understand how to design systems

Before:

I deployed manually

Now:

I automate everything

Before:

I fixed issues manually

Now:

I build systems that prevent them

🚀 What’s Next?

This is just the beginning.

Next steps:

🔹 Advanced Kubernetes (EKS deep dive)
🔹 Multi-cloud Terraform deployments
🔹 Policy-as-Code (OPA, Sentinel)
🔹 Production-grade CI/CD pipelines

💭 Final Thoughts

This challenge taught me something beyond Terraform:

Consistency beats intensity.

Showing up every day—even when debugging for hours—made all the difference.

If you’re starting your DevOps journey:
👉 Don’t just watch tutorials
👉 Build projects
👉 Break things
👉 Fix them with code

That’s how you grow.

Mastering GitOps: Bridging Infrastructure and Application Delivery with Terraform & ArgoCD

Atul Vishwakarma — Tue, 28 Apr 2026 06:07:55 +0000

After an intense journey through the #30DaysOfAWSTerraform challenge, Day 29 stands out as one of the most transformative milestones so far.

This wasn’t just about provisioning infrastructure anymore—it was about building a self-healing, automated, and production-grade GitOps workflow.

If Infrastructure as Code (IaC) is the foundation, GitOps is the operating system that keeps everything running smoothly.

🔄 From IaC to GitOps: What Changed?

Until now, Terraform allowed me to:

Define infrastructure declaratively
Provision resources consistently
Avoid manual “ClickOps”

But GitOps takes it a step further:

Git becomes the single source of truth
Systems automatically reconcile drift
Deployments become continuous and auditable

👉 In short:
IaC provisions infrastructure. GitOps keeps it correct.

🏗️ Architecture Overview

This project bridges infrastructure provisioning and application deployment into one cohesive system.

1. Infrastructure Repository (Terraform)

Responsible for:

Provisioning an Amazon EKS cluster
Setting up networking (VPC, subnets)
Installing ArgoCD via Helm
Configuring storage (EBS CSI driver)

2. Application Repository (Kubernetes Manifests)

Contains:

Frontend (UI layer)
Backend (API layer)
PostgreSQL database

⚙️ How the Workflow Operates

Terraform provisions the infrastructure (EKS + ArgoCD)
ArgoCD connects to the application Git repository
Kubernetes manifests define the desired application state
ArgoCD continuously monitors and syncs changes

💡 The Magic:

If anything changes outside Git (manual kubectl edits, scaling, etc.),
ArgoCD automatically reverts it back to the desired state.

🔍 Key Concepts I Mastered

🔹 1. Terraform Helm Provider

Instead of manually installing ArgoCD:

resource "helm_release" "argocd" {
  name       = "argocd"
  repository = "https://argoproj.github.io/argo-helm"
  chart      = "argo-cd"
}

👉 This ensures ArgoCD itself is version-controlled and reproducible.

🔹 2. The “App of Apps” Pattern

Rather than deploying each service manually:

A parent ArgoCD application manages multiple child apps
Each microservice is defined independently

✅ Result:

Scalable architecture
Clean separation of concerns
Easier multi-service management

🔹 3. Drift Detection & Self-Healing

This was the biggest “aha!” moment.

I tested:

Manually modifying a deployment
Changing image versions outside Git

📌 Result:
ArgoCD instantly detected the drift and reconciled it automatically.

👉 No manual rollback. No panic fixes. Just automation.

🧠 What This Means in Real-World DevOps

This project reflects how modern teams operate:

Traditional Approach	GitOps Approach
Manual deployments	Automated sync
Human error risk	Self-healing systems
Drift goes unnoticed	Drift auto-corrected
Config scattered	Git as single truth

🔐 Challenges & Lessons Learned

⚠️ Secrets Management

Kubernetes secrets are base64 encoded—not secure enough
Next step: integrate AWS Secrets Manager

⚠️ State Management

Local Terraform state is risky
Plan: move to:
- S3 backend
- DynamoDB locking

⚠️ Complexity Growth

GitOps introduces more moving parts
But the trade-off is worth it for automation + reliability

🚀 What’s Next? (Final Stretch)

Before wrapping up the challenge, I plan to:

✅ Implement remote state management
✅ Secure secrets with AWS Secrets Manager
✅ Enhance CI/CD integration
✅ Explore advanced GitOps patterns

💭 Final Thoughts

Day 29 changed how I think about infrastructure.

This isn’t just about provisioning resources anymore—it’s about:

Building autonomous systems
Reducing human intervention
Creating resilient platforms

👉 The goal is no longer just “infrastructure that works”
👉 It’s “infrastructure that fixes itself.”

Scaling Cloud Proficiency: Building a Production-Ready 3-Tier Architecture with Terraform

Atul Vishwakarma — Mon, 27 Apr 2026 07:19:35 +0000

As part of my 30 Days of AWS Terraform Challenge, Day 28 marked a significant milestone in my cloud engineering journey—designing and deploying a fully automated, production-grade 3-tier architecture on AWS using Terraform.

This project wasn’t just about provisioning resources. It was about thinking like a systems designer—balancing scalability, security, and reliability.

🌍 Why 3-Tier Architecture Matters

The 3-tier architecture is a foundational pattern in modern cloud systems because it separates concerns into:

Presentation Layer (Web Tier) → Handles user requests
Application Layer (App Tier) → Processes business logic
Data Layer (DB Tier) → Stores and manages data

✅ Benefits:

Improved security through isolation
Better scalability per tier
Increased fault tolerance
Easier maintenance & updates

🏗️ Architecture Overview

Here’s how I implemented the architecture on AWS:

🔹 1. Custom VPC & Networking

I created a custom Virtual Private Cloud (VPC) with:

Public subnets → For Load Balancer
Private subnets → For App + DB tiers
Internet Gateway → Public access
NAT Gateway → Secure outbound access

👉 This ensures:
✔ Public entry is controlled
✔ Backend remains private

🔹 2. High Availability Across AZs

To eliminate single points of failure:

Deployed resources across 2 Availability Zones
Distributed compute and networking components

👉 Result:
✔ Application remains available even during AZ failures

🔹 3. Web Tier (Presentation Layer)

Application Load Balancer (ALB)
Handles incoming traffic
Routes requests to application servers

👉 Acts as the only public entry point

🔹 4. Application Tier (Logic Layer)

EC2 instances inside private subnets
Managed using Auto Scaling Groups (ASG)

Features:

Horizontal scaling based on demand
High availability
Fault tolerance

🔹 5. Database Tier (Data Layer)

Amazon RDS (MySQL/PostgreSQL)
Placed in private subnet group
Accessible only from application tier

👉 Ensures:
✔ No public exposure
✔ Strong data security

⚙️ Terraform Implementation

Everything was provisioned using Terraform, following a modular approach.

📦 Modules Created:

VPC Module
Security Groups Module
Compute (EC2 + ASG) Module
RDS Module
Load Balancer Module

💡 Why Modular Terraform?

✔ Reusable across environments
✔ Cleaner codebase
✔ Easier debugging
✔ Faster deployments

👉 Write once → reuse everywhere

🔐 Security Best Practices Implemented

Private subnets for app & DB
Security group restrictions (least privilege)
No direct DB exposure
NAT for controlled outbound traffic
Secrets managed via AWS Secrets Manager

🚧 Challenges & Troubleshooting

This project wasn’t without hurdles:

RDS parameter group configuration issues
Terraform provider inconsistencies
Networking misconfigurations
Security group debugging

👉 These challenges were the real learning moments.

💡 Key Learnings

🔹 1. Design > Deployment

Provisioning is easy. Designing a resilient system is the real skill.

🔹 2. Security by Default 🔐

Never expose databases publicly
Always isolate layers

🔹 3. Modularity is Power

Terraform modules turn complex systems into manageable components.

🔹 4. Hands-On > Theory

Breaking things and fixing them teaches more than tutorials ever can.

🎯 Final Thoughts

Day 28 felt like a turning point in my journey.

I moved from:
➡️ Writing Terraform code
➡️ To designing real-world cloud architectures

This project reflects how modern systems are built:
✔ Scalable
✔ Secure
✔ Fault-tolerant
✔ Automated

🔮 What’s Next?

Only 2 days left in this challenge! Up next:

Final optimizations
Advanced patterns
Wrapping up the journey

Building a Highly Available Web Architecture with Terraform

Atul Vishwakarma — Mon, 20 Apr 2026 09:01:59 +0000

As part of my 30 Days of AWS Terraform Challenge, Day 24 marked a major milestone in my journey—from provisioning basic infrastructure to designing a highly available, fault-tolerant, and scalable web architecture using Terraform.

This project pushed me to think like a Cloud Engineer, not just a Terraform user.

🌍 Why High Availability Matters

In real-world production systems, downtime is not an option.

A resilient architecture must:

Handle failures gracefully
Scale automatically with demand
Maintain security best practices
Ensure consistent performance

This project brought all of these principles together.

🏗️ Architecture Overview

The infrastructure I built follows a multi-tier, production-grade design on AWS:

🔹 1. Application Load Balancer (ALB)

The ALB acts as the entry point for all incoming traffic.

Distributes traffic across multiple EC2 instances
Spans multiple Availability Zones
Ensures fault tolerance if one AZ fails

👉 Result: Improved uptime and reliability

🔹 2. Auto Scaling Group (ASG)

To make the system elastic, I configured an Auto Scaling Group:

Defined min, max, and desired capacity
Integrated CloudWatch metrics (CPU utilization)
Automatically:
- Scales out during high traffic
- Scales in during low usage

👉 Result: Performance + cost optimization

🔹 3. Private Subnet Architecture 🔐

Instead of exposing servers directly to the internet:

EC2 instances are deployed in private subnets
Only the ALB resides in public subnets

👉 Result: Strong security posture (Zero direct public access)

🔹 4. NAT Gateway for Outbound Access

Since private instances need internet access:

NAT Gateways were deployed in each AZ
Enables:
- OS updates
- Pulling Docker images
- External API calls

👉 Result: Secure outbound connectivity without compromising isolation

⚙️ Terraform Implementation

The entire infrastructure was built using Infrastructure as Code (IaC) with Terraform.

📦 Key Components:

🔸 Launch Templates

Defined EC2 configuration
Automated:
- Docker installation
- Application deployment (Django app)

🔸 Auto Scaling Policies

Connected with CloudWatch alarms
Triggered scaling actions automatically

🔸 Modular Design

Separated:
- Networking
- Compute
- Security
Improved readability and reusability

👉 Result: Clean, scalable, production-ready codebase

📊 Key Learnings

💡 1. Fault Tolerance is Essential

Deploying across multiple Availability Zones ensures:

No single point of failure
Continuous availability

💡 2. Automation Eliminates Drift

Manually building this setup would:

Be error-prone
Lead to inconsistencies

With Terraform:

terraform apply
terraform destroy

Everything becomes:
✔ Repeatable
✔ Version-controlled
✔ Reliable

💡 3. Security First Mindset 🔐

Private subnets for compute
ALB as the only public entry
NAT for controlled outbound access

👉 This is how real-world systems are designed

💡 4. Scalability is a Design Principle

Instead of guessing capacity:

Let metrics drive scaling decisions
Build systems that adapt automatically

🚧 Challenges Faced

Understanding ASG + ALB integration
Debugging health checks
Configuring correct security group rules
Ensuring proper routing between subnets

👉 Each issue improved my troubleshooting skills significantly

🎯 Final Thoughts

This project was a turning point in my Terraform journey.

I moved from:
➡️ Creating resources
➡️ To designing resilient cloud systems

This is what real DevOps engineering looks like.

🔮 What’s Next?

As I approach the final stretch of this challenge, I’m excited to explore:

Advanced deployment strategies
CI/CD integrations
Multi-account architectures

Building Production-Grade Observability with Terraform

Atul Vishwakarma — Mon, 20 Apr 2026 06:23:24 +0000

From Deployment to Visibility: Observability in Action 🚀

As part of my 30 Days of AWS Terraform challenge, Day 23 marked a crucial milestone — shifting focus from simply deploying infrastructure to monitoring, analyzing, and ensuring its reliability.

Today’s project was all about End-to-End Observability, a critical pillar of any production-grade system.

Because in real-world systems, success is not just about launching applications — it’s about understanding:

How they behave 📊
When they fail ⚠️
Why they fail 🔍

🔎 Why Observability Matters

In modern cloud environments:

❌ Failures are inevitable
❌ Traffic patterns are unpredictable
❌ Systems are distributed

Without observability, debugging becomes guesswork.

👉 Observability enables teams to detect, diagnose, and resolve issues proactively.

By using Terraform, we can:

✔️ Automate monitoring setup
✔️ Ensure consistency across environments
✔️ Treat observability as code

🏗️ Project Architecture Overview

For this project, I built an observability layer around a serverless image-processing pipeline.

Core Architecture:

Amazon S3 → Image upload trigger
AWS Lambda → Image processing function
CloudWatch → Logs, metrics, dashboards, alarms
SNS → Alert notifications

This architecture demonstrates a real-world event-driven system.

📊 Deep Dive into Observability Components

1. CloudWatch Log Groups 🪵

Every Lambda execution generates logs.

I provisioned log groups using Terraform to:

Centralize logs
Retain execution history
Enable debugging

2. Metric Filters 📈

Logs alone aren’t enough — we need structured metrics.

Using CloudWatch Metric Filters, I extracted:

Processing success rates
Error counts
Latency metrics (P99)
Image size distributions

Why This Matters:

✔️ Converts raw logs into actionable insights
✔️ Enables performance tracking
✔️ Supports alerting systems

3. Custom Dashboards 📊

I created a CloudWatch Dashboard using Terraform to visualize system health.

Included Widgets:

Request count
Error rates
Latency trends
Throughput metrics

Benefit:

👉 Real-time visibility into application performance

4. Automated Alerts with SNS 🚨

Monitoring without alerting is incomplete.

I configured 12 CloudWatch alarms to detect anomalies such as:

High error rates
Increased latency
High concurrency spikes

Alert Workflow:

CloudWatch Alarm → SNS Topic → Email Notification

Result:

✔️ Proactive incident response
✔️ Reduced downtime
✔️ Faster debugging

⚙️ Terraform Implementation Highlights

Using Terraform, I automated:

Log group creation
Metric filters
Dashboard definitions
Alarm configurations
SNS topic setup

Why This is Powerful:

👉 Observability is deployed alongside infrastructure — not as an afterthought.

🧪 Testing & Troubleshooting

One of the most valuable parts of this project was testing the system.

Scenarios I Simulated:

Uploading invalid files → Trigger errors
Increasing load → Test concurrency alarms
Delayed processing → Validate latency thresholds

Key Learnings:

Metric filters must match log patterns precisely
Alarm thresholds require fine-tuning
Evaluation periods impact alert accuracy

This hands-on debugging made the learning much more practical.

💡 Key Takeaways from Day 23

✔️ Observability is essential for production systems
✔️ Terraform can fully automate monitoring stacks
✔️ Metrics + logs = complete visibility
✔️ Alerts enable proactive operations
✔️ Testing monitoring systems is as important as building them

🧠 Why This Matters in Real-World DevOps

In production environments:

You won’t always see failures immediately
Users will experience issues before you do (if no monitoring exists)

Observability ensures:

✔️ Faster incident detection
✔️ Better system reliability
✔️ Improved user experience

🚀 What’s Next?

With just a few days left in this challenge, I’m excited to explore:

Advanced monitoring tools
Distributed tracing
CI/CD observability integration

🎯 Final Thoughts

Day 23 was a turning point in my Terraform journey.

It reinforced that:

👉 Deploying infrastructure is only half the job — monitoring it is the other half.

If you're learning DevOps or Terraform, don’t skip observability — it’s what makes systems truly production-ready.

Building a Production-Ready 2-Tier Architecture on AWS with Terraform

Atul Vishwakarma — Fri, 17 Apr 2026 09:16:42 +0000

From Theory to Real-World Infrastructure 🚀

As part of my 30 Days of AWS Terraform challenge, Day 22 was a major milestone where I moved beyond individual resources and built a production-style 2-tier architecture using Terraform.

This project was all about combining networking, security, compute, and database layers into a cohesive and secure system — just like real-world applications.

🏗️ The Goal: Build a Secure 2-Tier Architecture

The objective of this project was to design and deploy:

Web Tier (Public Layer) → EC2 instances running a Flask application
Database Tier (Private Layer) → MySQL RDS instance

These two layers communicate securely while maintaining strict isolation from public access.

🔐 Architecture Overview

Web Tier (Public Subnet)

EC2 instance running Flask app
Accessible via Internet Gateway
Uses User Data for automated setup

Database Tier (Private Subnet)

Amazon RDS (MySQL)
No public access
Only accessible from Web Tier via Security Groups

⚙️ Core Infrastructure Components

To support this architecture, I provisioned:

🌐 Networking

Custom VPC
Public & Private subnets
Internet Gateway (for web tier)
NAT Gateway (for private subnet outbound access)

🔒 Security

Security Groups with strict rules
Principle of Least Privilege enforced

🔑 Secrets Management

AWS Secrets Manager for DB credentials
No hardcoded sensitive data

🖥️ Compute

EC2 instance with Flask app
Automated setup via User Data

🗄️ Database

RDS MySQL instance in private subnet

🧩 Modular Terraform Architecture

One of the biggest highlights of Day 22 was applying Terraform Modules in a real project.

Instead of one large configuration file, I structured my code into reusable modules:

Module Structure:

VPC Module → Networking setup
Security Group Module → Access control
RDS Module → Database provisioning
Secrets Module → Credential management
EC2 Module → Web server deployment

🔄 Data Flow Between Modules

Terraform modules don’t communicate directly — so I used:

outputs.tf → to expose values
variables.tf → to pass inputs

Example:

VPC module outputs subnet IDs
Root module passes them to EC2 & RDS modules
Secrets module outputs credentials used by EC2

This pattern ensures:

✔️ Loose coupling
✔️ High reusability
✔️ Clean architecture

🧪 Testing the Application

After deployment, I validated the setup by hitting:

/health → Application health check
/db/info → Database connectivity

Seeing the Flask app successfully connect to the RDS instance was a huge win! 🎉

🔐 Security Best Practices Implemented

This project reinforced critical security principles:

✔️ Private Database

RDS placed in private subnet
No direct internet exposure

✔️ Controlled Access

Only EC2 security group can access DB

✔️ Secrets Management

Credentials stored in AWS Secrets Manager

✔️ Least Privilege

Minimal permissions across components

💡 Key Learnings from Day 22

Modules are essential for scalable Terraform projects
Networking design is critical for security
Secrets should never be hardcoded
Private subnets protect sensitive resources
Testing validates real-world readiness

🧠 Why This Project Matters

This was not just another Terraform lab — it was a real-world architecture simulation.

It taught me how to:

Design secure systems
Structure modular IaC
Connect application & database layers
Apply DevOps best practices

This is the kind of project that bridges the gap between learning and real engineering.

🚀 What’s Next?

With only 8 days remaining, I’m excited to explore:

CI/CD integration
Advanced security practices
Multi-environment deployments

🎯 Final Thoughts

Day 22 was one of the most practical and rewarding days of this challenge.

It reinforced that:

👉 Good infrastructure is not just functional — it’s secure, modular, and scalable.

If you're learning Terraform, I highly recommend building projects like this to truly understand how cloud systems work.

Mastering Cloud Policy & Governance with Terraform

Atul Vishwakarma — Fri, 17 Apr 2026 05:56:46 +0000

Building Secure & Compliant Cloud Infrastructure with IaC 🚀

As part of my 30 Days of AWS Terraform challenge, Day 21 marked a major shift in perspective — from simply provisioning infrastructure to governing and securing it at scale.

Today’s focus was on AWS Policy and Governance using Terraform, and it was one of the most practical and impactful lessons so far.

Because in real-world cloud environments, success isn’t just about deploying resources — it’s about ensuring they are:

Secure 🔐
Compliant 📋
Auditable 🔍
Consistent ⚙️

Why Policy & Governance Matter

When infrastructure grows across teams, regions, and environments, manual management becomes:

❌ Error-prone
❌ Inconsistent
❌ Difficult to audit
❌ A major security risk

This is where Infrastructure as Code (IaC) combined with governance tools becomes critical.

👉 Terraform allows us to codify guardrails, ensuring that every deployment automatically follows best practices.

Core Concepts I Explored

Today’s lab focused on three essential pillars of cloud governance:

1. Preventive Controls with IAM Policies 🔐

IAM acts as the first line of defense.

Instead of reacting to issues, we can prevent them entirely by defining strict policies.

What I Implemented:

Denied S3 bucket deletion without MFA
Enforced encrypted uploads (HTTPS only)
Restricted unsafe operations based on conditions

Why It Matters:

✔️ Stops misconfigurations before they happen
✔️ Enforces least privilege
✔️ Protects critical infrastructure

2. Continuous Monitoring with AWS Config 📊

IAM prevents bad actions — but what about changes over time?

That’s where AWS Config comes in.

What I Built:

Enabled AWS Config recorder
Configured managed rules
Monitored compliance continuously

Example Checks:

Unencrypted EBS volumes
Missing resource tags
Non-compliant S3 buckets

Why It Matters:

✔️ Detects drift in infrastructure
✔️ Ensures continuous compliance
✔️ Provides audit visibility

3. Secure Logging & Audit Trails 🪵

Governance is incomplete without proper logging.

What I Implemented:

Centralized S3 bucket for logs
Enabled versioning
Enforced encryption
Restricted public access

Why It Matters:

✔️ Enables audits & investigations
✔️ Preserves historical data
✔️ Strengthens security posture

Hands-On Implementation Highlights ⚙️

Today’s project involved building governance controls using Terraform:

✔️ AWS Config Setup

Config recorder automation
Managed rule definitions

✔️ Tagging Enforcement

Standardized tags across all resources
Improved cost tracking & ownership

✔️ IAM Guardrails

Attached policies to roles
Controlled access behavior

This made the entire infrastructure:

👉 Self-governing
👉 Consistent
👉 Production-ready

The Real Challenge: IAM Policy Evaluation 🧠

One of the most valuable learnings today was understanding how IAM policies are evaluated.

It’s not just about writing policies — it’s about understanding:

Explicit Deny vs Allow
Policy precedence
Conditional logic behavior

Key Insight:

👉 An explicit deny always overrides an allow.

This concept is critical when designing secure systems.

Why This Matters in Real Organizations 🏢

In enterprise environments, governance ensures:

✔️ Compliance with regulations
✔️ Security at scale
✔️ Standardized deployments
✔️ Reduced human error

Without governance, cloud infrastructure quickly becomes chaotic.

With Terraform + AWS Config + IAM → you get automated compliance.

Key Takeaways from Day 21 💡

Terraform can enforce governance, not just provisioning
IAM policies act as preventive controls
AWS Config enables continuous monitoring
Logging is critical for auditing
Understanding policy evaluation is essential

What’s Next? 🔥

As I move forward in this journey, I’m excited to explore:

Policy as Code (OPA, Sentinel)
Advanced compliance automation
Security frameworks integration

Final Thoughts

Day 21 was a turning point.

It changed my mindset from:

➡️ “How do I deploy infrastructure?”
➡️ To “How do I secure and govern infrastructure at scale?”

That’s the real difference between writing Terraform and engineering cloud systems.

If you’re learning Terraform, don’t skip governance — it’s what makes your infrastructure production-ready.

Mastering Custom Terraform Modules for Scalable AWS Infrastructure

Atul Vishwakarma — Thu, 16 Apr 2026 10:48:58 +0000

Building Production-Ready Infrastructure with Reusable Terraform Modules 🚀

As part of my 30 Days of AWS Terraform challenge, Day 20 was a major milestone in my Infrastructure as Code journey.

Today’s focus was on one of the most important Terraform concepts for real-world DevOps: Custom Terraform Modules.

Until now, most of my learning revolved around creating and managing AWS resources directly. But Day 20 introduced the concept that truly separates beginner Terraform projects from production-grade cloud systems:

👉 Modularity and reusability.

This project gave me hands-on experience building an Amazon EKS cluster using a modular Terraform architecture — and it completely changed how I think about writing infrastructure code.

Why Terraform Modules Matter

When starting with Terraform, it’s common to place everything in a single main.tf file:

VPC
Subnets
Security groups
IAM roles
EKS cluster

This works for simple labs.

But in real-world environments, this quickly becomes:

❌ Hard to manage
❌ Difficult to debug
❌ Impossible to scale
❌ Error-prone for teams

Terraform modules solve this problem.

Benefits of Modules:

✅ Code reusability
✅ Better readability
✅ Easier collaboration
✅ Standardized deployments
✅ Simplified maintenance

Modules help transform Terraform from a scripting tool into a proper infrastructure framework.

Types of Terraform Modules I Explored

Today, I explored the three main types of modules:

1. Public Modules

Modules published in the Terraform Registry by providers like HashiCorp.

Example:

AWS VPC module

2. Partner Modules

Modules maintained jointly by HashiCorp and cloud vendors / partners.

Useful for:

Enterprise integrations
Verified architectures

3. Custom Modules (Main Focus Today)

Custom modules are built by your own team to:

Match internal standards
Enforce security controls
Improve reusability

This was the core focus of Day 20.

Project Goal: Build an EKS Cluster with Custom Modules 🎯

For today’s hands-on project, I built an Amazon EKS (Elastic Kubernetes Service) cluster using modular Terraform code.

Instead of writing one large configuration file, I split the infrastructure into reusable child modules:

Module Breakdown:

VPC Module → Networking, subnets, routing
IAM Module → Roles, policies, permissions
EKS Module → Cluster and worker node setup

This approach felt much closer to how real production systems are designed.

Understanding Root Module vs Child Modules 🧠

One of the biggest learnings today was understanding how Terraform structures module relationships.

Root Module

The root module acts as the main entry point.

Responsibilities:

Calling child modules
Passing variables
Managing overall orchestration

Child Modules

Child modules are reusable building blocks.

Each child module:

Handles one responsibility
Has its own variables
Exposes outputs

Why This Matters

This separation improves:

Team ownership
Maintainability
Debugging

This was a huge mindset shift for me.

Passing Data Between Modules 🔄

Today’s most important concept was learning how to pass information between modules.

Key Challenge:

Terraform child modules cannot directly communicate with each other.

So if:

VPC module creates subnets
IAM module creates roles

The EKS module still needs:

Subnet IDs
IAM Role ARN

Solution:

Using:

variables.tf
outputs.tf

Example Flow:

VPC module outputs subnet IDs
Root module receives outputs
Root passes them into EKS module

Why This Matters

This teaches clean architecture principles:

👉 Modules should stay independent, but data should flow intentionally.

This was the biggest technical takeaway from Day 20.

Encapsulation = Cleaner Infrastructure 🧩

Another major lesson was the power of encapsulation.

Instead of exposing all resource complexity in the root module:

I wrapped:

IAM roles
Node groups
Networking logic

Inside modules.

Result:

My root configuration became:

✔️ Cleaner
✔️ Easier to understand
✔️ Faster to extend

This makes future projects much easier to maintain.

Why This Matters in Real Organizations 🏢

Custom modules are essential for enterprise DevOps because they help enforce standards.

Examples:

Secure default VPC rules
Required resource tags
Approved IAM policies
Logging standards

Benefits for Teams:

✔️ Consistency across environments
✔️ Better compliance
✔️ Faster deployments
✔️ Reduced human error

Today made me realize that writing reusable Terraform is as important as writing correct Terraform.

Key Learnings from Day 20 💡

Today’s biggest takeaways:

✔️ Terraform modules improve scalability
✔️ Root / child architecture is powerful
✔️ Variables & outputs are the backbone of modularity
✔️ Encapsulation makes code production-ready
✔️ Reusability saves time and reduces errors

This felt like a major step toward thinking like a professional cloud engineer.

Advice for Beginners

If you’re learning Terraform:

Start small.

Try creating modules for:

VPC
EC2 instance
Security groups

Before moving to advanced services like EKS.

The sooner you understand modules, the easier Terraform becomes.

What’s Next? 🔥

Looking ahead, I’m excited to explore:

Module versioning
Remote module sources
CI/CD integration
Multi-environment deployments

Still 10 days to go — excited to keep building.

Final Thoughts

Day 20 was one of the most impactful milestones in this Terraform challenge.

It taught me that great Infrastructure as Code is not just about provisioning resources — it’s about building systems that are:

Reusable
Scalable
Maintainable

Custom Terraform modules are a game-changer for anyone serious about cloud engineering.

If you’re on your own Terraform journey, I highly recommend spending time mastering modules — they unlock the real power of IaC.

How are you using Terraform modules in your projects? I’d love to hear your best practices.

Building a Serverless Image Processing Pipeline with Terraform

Atul Vishwakarma — Wed, 15 Apr 2026 10:02:43 +0000

Automating Image Workflows with AWS Lambda, S3, and Terraform 🚀

As part of my 30 Days of AWS Terraform challenge, Day 18 was one of the most exciting and practical projects so far.

Today, I moved beyond basic infrastructure provisioning and built a fully automated serverless image processing pipeline using:

AWS S3
AWS Lambda
IAM Roles & Policies
Terraform

This project was a major step toward understanding how real-world event-driven cloud systems are designed and automated.

The Project Goal 🎯

The goal was simple but powerful:

👉 Whenever an image is uploaded to a source S3 bucket, AWS should automatically process it and store multiple optimized versions in a destination bucket.

Output Variants Included:

Compressed versions
Different file formats
Thumbnail image

This type of architecture is highly relevant for:

Media platforms
E-commerce websites
User profile image optimization
Content delivery systems

Why Serverless Architecture Matters

Traditional image processing systems often require:

Dedicated servers
Manual scaling
Ongoing maintenance

That creates:

Higher cost
Operational complexity
Slower deployments

Serverless changes everything.

Benefits of Serverless:

✅ Event-driven execution
✅ No server management
✅ Auto scaling
✅ Pay only for usage
✅ Faster deployment cycles

This project showed me exactly why serverless is such a powerful cloud pattern.

Architecture Overview 🏗️

The architecture for today’s project looked like this:

Step-by-Step Flow:

User uploads image to Source S3 bucket
S3 event notification triggers Lambda
Lambda processes image using Pillow library
Lambda generates multiple variants
Processed images are uploaded to Destination bucket

This entire workflow runs automatically without any manual intervention.

Terraform Resources Used ⚙️

This project was a great demonstration of how Terraform can automate complex serverless stacks.

Key Resources Provisioned:

1. S3 Buckets 📦

Terraform created:

Source bucket (incoming uploads)
Destination bucket (processed images)

Bucket setup included:

Event notification configuration
Permissions for Lambda access

2. AWS Lambda Function 🧠

The core logic was implemented inside a Lambda function.

Responsibilities:

Read uploaded image
Process and compress variants
Generate thumbnail
Upload outputs

Why Lambda?

Lambda is ideal because:

No server maintenance
Automatic scaling
Fast event response

3. IAM Roles & Least Privilege Security 🔐

A key learning today was implementing secure IAM access.

Terraform provisioned:

Lambda execution role
Scoped IAM policies

Permissions included:

s3:GetObject from source bucket
s3:PutObject to destination bucket
CloudWatch logs access

Why This Matters

Security in automation is critical.

This reinforced:

👉 Always grant only the permissions required.

4. CloudWatch Logging 📊

Terraform also provisioned:

Log groups
Monitoring support

This helped with:

Debugging failures
Monitoring execution
Troubleshooting events

CloudWatch visibility was extremely useful during testing.

Biggest Challenge: Dependency Management 🐳

One of the most valuable lessons today came from troubleshooting Python dependencies.

The Problem:

Libraries like:

Pillow

Often fail when packaged locally because:

Local machine OS differs from AWS Lambda runtime
Binary dependencies break

The Solution:

I used Docker to build Lambda Layers.

Why Docker Helped:

Matched AWS Linux environment
Prevented runtime compatibility issues
Ensured consistent builds

Key Lesson:

👉 “It works on my machine” is not enough in cloud engineering.

Environment consistency matters.

This was one of the most important practical takeaways so far.

Key Learnings from Day 18 💡

Today’s project taught me:

✔️ How event-driven serverless systems work
✔️ How S3 triggers Lambda in real workflows
✔️ Why least privilege IAM matters
✔️ How Terraform simplifies complex deployments
✔️ Why dependency packaging is critical

This was one of the clearest examples yet of Terraform enabling repeatable, scalable cloud systems.

Why Terraform Made This Easier

Without Terraform, setting this up manually would involve:

Creating buckets
Uploading Lambda code
Configuring IAM roles
Setting triggers
Setting logs

This would be:

❌ Time-consuming
❌ Error-prone
❌ Hard to reproduce

Terraform made the entire setup:

✅ Repeatable
✅ Version-controlled
✅ Easy to destroy / recreate

This is exactly why IaC is such a game changer.

What’s Next? 🔥

Future improvements I’d like to explore:

Adding image watermarking
Using Step Functions for complex workflows
Integrating API Gateway for direct uploads
Setting lifecycle rules on processed images
Adding alerts for failed Lambda runs

Excited to keep building.

Final Thoughts

Day 18 was one of the most practical and rewarding milestones in this challenge so far.

This project showed me how Terraform can be used not just to provision resources, but to automate intelligent business workflows.

Serverless architectures are efficient, scalable, and increasingly relevant in modern cloud systems — and building one from scratch was a huge confidence boost.

If you’re learning Terraform, I highly recommend exploring serverless projects like this. They teach infrastructure, automation, debugging, and cloud design all at once.

Have you built event-driven serverless workflows with Terraform? I’d love to hear your experiences.

Mastering Blue-Green Deployments with Terraform & AWS Elastic Beanstalk

Atul Vishwakarma — Tue, 14 Apr 2026 10:33:51 +0000

Achieving Zero-Downtime Deployments with Infrastructure as Code 🚀

As part of my 30 Days of AWS Terraform challenge, Day 17 was one of the most exciting milestones so far: implementing a Blue-Green Deployment strategy using Terraform and AWS Elastic Beanstalk.

This project took my Terraform journey beyond provisioning infrastructure into the world of release engineering, deployment safety, and production reliability.

Until now, I had focused on building resources and automating cloud workflows. But today’s challenge taught me something even more valuable:

👉 How to deploy application updates without downtime and with instant rollback capability.

Why Blue-Green Deployment Matters

In production systems, every deployment introduces risk.

Common challenges with traditional deployments:

Temporary downtime during updates
Risk of failed releases affecting users
Difficult rollbacks
Limited testing in production-like conditions

This is where Blue-Green Deployment becomes a game-changer.

What is Blue-Green Deployment?

Blue-Green is a deployment strategy where you maintain two identical production environments:

🔵 Blue Environment

Current live production version
Serving real users

🟢 Green Environment

New version deployment
Used for testing and validation

Once Green is validated:

👉 Traffic is switched from Blue to Green instantly.

If something breaks:

👉 Rollback is as simple as switching traffic back.

Project Goal 🎯

The goal for today’s project was to:

Deploy two versions of an application (v1 and v2)
Host them in separate Elastic Beanstalk environments
Manage infrastructure using Terraform
Perform a zero-downtime DNS cutover

This project was a perfect mix of:

Terraform provisioning
AWS application hosting
Deployment strategy
Risk mitigation

Architecture Overview 🏗️

Key AWS Components Used

1. Amazon S3 for Application Packaging 📦

I first packaged:

Application version v1.0
Application version v2.0

As ZIP archives.

These were uploaded to an S3 bucket, which served as the source for Elastic Beanstalk deployments.

Why This Matters

S3 acts as:

Central artifact storage
Version-controlled release source
Secure deployment package repository

2. AWS Elastic Beanstalk Environments 🌱

Terraform was used to provision:

Elastic Beanstalk Application
Blue environment (live)
Green environment (candidate release)

Elastic Beanstalk simplified:

EC2 provisioning
Load balancing
Auto scaling
Health monitoring

This allowed me to focus more on deployment logic than server management.

3. IAM Roles & Instance Profiles 🔐

To make the environments work securely, Terraform also provisioned:

EC2 IAM roles
Instance profiles
Required permissions

This ensured:

S3 access for artifacts
Elastic Beanstalk environment operations

A good reminder that security is always part of automation.

Terraform in Action ⚙️

This project helped me apply Terraform in a real deployment workflow.

Key Terraform Concepts Used:

✔️ Resource provisioning for Elastic Beanstalk
✔️ S3 object uploads for artifacts
✔️ IAM role automation
✔️ Environment lifecycle management
✔️ Infrastructure consistency between Blue & Green

Biggest Benefit

Because both environments were managed as code:

Configuration stayed consistent
Drift was minimized
Deployment became repeatable

This is exactly why IaC matters.

The Best Part: Zero-Downtime DNS Swap 🔄

The highlight of today’s project was performing the actual traffic cutover.

Once Green was deployed and tested:

I validated the new version
Confirmed health checks
Swapped the CNAME / DNS routing

Result:

✅ Users experienced zero downtime
✅ Traffic shifted instantly
✅ No service interruption

This was one of the most satisfying hands-on moments in this challenge so far.

Key Learnings from Day 17 💡

1. Downtime Can Be Avoided

Production deployments don’t have to impact users.

Blue-Green strategies provide:

Safer releases
Better customer experience
Lower operational risk

2. Rollbacks Should Be Simple

One of the strongest lessons:

👉 Good systems are not just deployable — they are recoverable.

If Green fails:

Switch traffic back to Blue
Restore production quickly

This kind of safety net is essential in real systems.

3. Testing Matters

Green environments allow:

Smoke tests
Health checks
Validation before release

This reduces bad deployments significantly.

Real-World Extensions 🔥

To make this production-grade, future improvements could include:

Route 53 weighted routing
Automated DNS cutover via Terraform / CLI
CI/CD integration with GitHub Actions / Jenkins
Canary deployments
Monitoring with CloudWatch

These are areas I’m excited to explore next.

Final Thoughts

Day 17 was a major mindset shift.

This project showed me that DevOps is not just about creating infrastructure — it’s about designing systems that are:

Reliable
Recoverable
Safe to change

Blue-Green deployment is one of the clearest examples of how cloud engineering directly improves user experience.

If you’re learning Terraform or AWS, I highly recommend trying a project like this. It teaches both technical depth and deployment discipline.

Scaling IAM User Management with Terraform

Atul Vishwakarma — Tue, 14 Apr 2026 09:16:23 +0000

Automating User Onboarding and Access Control at Scale 🚀

As part of my 30 Days of AWS Terraform challenge, Day 16 shifted from infrastructure provisioning into something just as critical in real-world DevOps: identity and access management (IAM) at scale.

Today’s hands-on project focused on automating AWS IAM user creation, login setup, tagging, and group assignment using Terraform.

This was a powerful reminder that Infrastructure as Code is not only about deploying servers and networks — it’s also about standardizing how people securely interact with cloud systems.

The Real Problem: Manual IAM Doesn't Scale

In many organizations, onboarding users manually through the AWS Console leads to:

Human errors
Inconsistent naming
Delayed access provisioning
Poor auditability

As teams grow, this process becomes inefficient and risky.

Terraform solves this by making IAM onboarding:

✅ Repeatable
✅ Scalable
✅ Auditable
✅ Secure-by-design

Project Goal 🎯

The goal for today’s project was simple:

👉 Automatically provision multiple IAM users from a CSV file and manage access dynamically.

This included:

Bulk user creation
Naming standardization
Metadata tagging
Login profile setup
Group assignment based on role/department

Architecture & Workflow ⚙️

1. CSV Data Parsing with `csvdecode()` 📄

The first step was handling structured user input.

I created a CSV file containing:

First name
Last name
Department
Role

Using Terraform’s built-in csvdecode() function, I converted the CSV into a list of maps that Terraform could iterate over.

Why This Matters

This approach makes onboarding easy:

Just update the CSV
Terraform handles the rest

Perfect for HR / DevOps collaboration.

2. Bulk User Provisioning with `for_each` 🔁

Instead of manually creating IAM users one by one, I used:

for_each
Dynamic resource blocks

This allowed Terraform to create multiple users in a single apply.

Benefits:

✔️ No duplicate code
✔️ Faster onboarding
✔️ Easier scaling

This is exactly where Terraform shines.

3. Dynamic Naming & Standardized Tags 🏷️

To enforce consistency, I used Terraform functions like:

lower()
substr()

Example:

Michael Scott → mscott

I also added tags such as:

Department
Role
Owner

Why Tags Matter

Tags improve:

Cost visibility
Auditing
Access control

This was a great exercise in combining automation with governance.

4. Secure Login Profiles 🔐

To make the users immediately usable, I provisioned:

aws_iam_user_login_profile

With:

password_reset_required = true

This ensures users must reset passwords on first login.

Security Lesson

While outputs were used for learning/demo purposes, this reinforced an important point:

👉 Sensitive credentials should never be exposed carelessly.

In production, this should be paired with:

AWS Secrets Manager
HashiCorp Vault
Secure password delivery workflows

5. Dynamic Group Assignment Based on Role 🧠

One of the most exciting parts of today’s project was automating IAM group membership.

Instead of manually assigning users to groups:

I used:

for_each
Conditional expressions
Tag-based logic

Example:

Users tagged as manager → Manager group
Finance users → Finance access group

Why This Matters

This makes onboarding smarter by:

✔️ Reducing manual work
✔️ Enforcing policy automatically
✔️ Improving consistency

This felt like true Infrastructure as Code in action.

Key Takeaways 💡

Day 16 taught me that DevOps is not just about infrastructure resources — it’s also about people, permissions, and secure workflows.

Today’s biggest lessons:

✔️ IAM automation improves speed and consistency
✔️ Terraform can simplify complex onboarding workflows
✔️ Security must always be part of automation design
✔️ Dynamic logic makes systems scalable

What’s Next? 🔥

To make this production-ready, my next steps would include:

Applying least-privilege IAM policies
Enabling MFA for all users
Integrating with AWS SSO / IAM Identity Center
Adding secure secret distribution

Excited to keep building and improving.

Final Thoughts

Day 16 was one of the most practical projects so far because it connected Terraform directly to real-world operational workflows.

Automating IAM user management showed me how Infrastructure as Code can improve not just systems, but also team productivity and security posture.

If you’re learning Terraform, don’t stop at servers and networks — explore IAM automation too. It’s one of the most valuable skills in cloud engineering.

Mastering AWS VPC Peering with Terraform

Atul Vishwakarma — Tue, 14 Apr 2026 07:17:23 +0000

Connecting Networks Across Regions with Infrastructure as Code 🚀

As part of my 30 Days of AWS Terraform challenge, Day 15 marked a major milestone: reaching the halfway point and stepping into one of the most practical areas of cloud engineering — AWS networking with VPC Peering.

Until now, much of my Terraform journey focused on provisioning resources and learning Terraform concepts. But today’s project shifted from deploying isolated services to solving a real-world networking challenge: securely connecting two private AWS VPCs across different regions using Terraform.

This project was a strong reminder that Infrastructure as Code is not just about automation — it’s about understanding architecture, networking principles, and system design.

Why VPC Peering Matters

In real-world cloud environments, applications and services often live in different VPCs:

Separate environments (Dev / Staging / Prod)
Multi-account setups
Regional redundancy architectures
Shared services and private APIs

To allow these isolated networks to communicate securely over private IP addresses, AWS provides VPC Peering.

What VPC Peering Does

VPC Peering creates a private connection between two VPCs, enabling resources in each network to talk to each other as if they were on the same local network.

Benefits include:

✅ Private communication (no internet exposure)
✅ Low latency
✅ Better security
✅ Simplified architecture

Project Overview 🏗️

For this mini-project, I provisioned:

VPC 1 in US East (N. Virginia)
VPC 2 in US West (Oregon)
EC2 instances in both VPCs
VPC Peering connection between them
Route table updates for bidirectional traffic

The goal was simple:

👉 Allow private communication between instances in both regions.

And yes — successfully testing cross-region private connectivity felt amazing. 🎯

Key Learnings from Day 15

1. Multi-Region Terraform with Provider Aliases 🌍

One of the biggest learnings today was managing resources across multiple AWS regions in a single Terraform project.

Using provider aliases, I configured:

aws.primary → US East 1
aws.secondary → US West 2

This made it possible to:

Deploy resources cleanly in separate regions
Keep code structured and maintainable
Avoid duplicated configurations

Why This Matters

In enterprise cloud environments, multi-region deployments are common for:

Disaster recovery
High availability
Geo-distributed applications

Understanding provider aliases is essential for scalable Terraform projects.

2. CIDR Planning is Critical 🧠

One of the first rules of VPC Peering:

❌ CIDR ranges must NOT overlap

If both VPCs share the same IP range:

Route tables conflict
Traffic breaks
Connectivity fails

This reinforced an important lesson:

👉 Good networking starts with good IP planning.

Even with Terraform, automation cannot fix poor architecture.

3. VPC Peering is NOT Transitive ⚠️

A major cloud networking concept I learned:

If:

VPC A ↔ VPC B
VPC B ↔ VPC C

That does NOT mean:

VPC A can talk to VPC C

This is called non-transitive peering.

Why This Matters

For larger enterprise setups:

VPC Peering can become hard to manage
Mesh architectures get complex quickly

This is where services like:

AWS Transit Gateway
Hub-and-spoke networking

Become important.

Understanding this limitation was one of today’s biggest takeaways.

4. Route Tables Make the Magic Happen 🛣️

Creating the peering connection is only half the setup.

The real work is in routing.

For both VPCs, I had to:

Update route tables
Add peer VPC CIDR blocks
Point traffic to the peering connection ID

Without correct routes:

Terraform may succeed… but traffic will still fail.

This taught me a practical lesson:

👉 Cloud networking is as much about traffic flow as it is about resource creation.

Hands-On Testing & Validation 🔍

The most satisfying part of today’s project was testing connectivity.

After setup, I verified:

Ping between instances
Curl requests to private IPs
Cross-region communication over private network

Seeing an EC2 instance in Oregon reach a web server in Virginia privately was an exciting milestone.

This was one of the clearest demonstrations so far of how powerful Terraform + AWS can be together.

Key Takeaways 💡

Day 15 taught me more than just Terraform syntax.

It reinforced:

✔️ Cloud networking fundamentals matter
✔️ Architecture decisions impact scalability
✔️ Debugging builds confidence
✔️ Terraform is powerful when paired with strong design principles

What’s Next? 🔥

Reaching the halfway point feels great, but there’s still a lot ahead:

Security hardening
Modules & reusable architecture
Advanced state management
Production deployment workflows

Excited for the second half of this challenge.

Final Thoughts

Day 15 was one of the most practical and rewarding days of my Terraform journey so far.

If you’re learning Terraform, don’t stop at basic resource creation. Start exploring networking, debugging routes, and understanding how systems communicate.

That’s where real cloud engineering begins.