DEV Community: Jeeva

Day 30 – Terraform Drift Detection & Auto-Remediation with GitHub Actions 🚀

Jeeva — Mon, 16 Feb 2026 17:23:42 +0000

🎯 Objective

Build a fully automated system that:
Provisions infrastructure using Terraform
Detects unauthorized/manual infrastructure changes (drift)
Automatically remediates drift
Sends Slack notifications
Manages GitHub issues for audit tracking
Supports dev and prod environments All using GitHub Actions as the automation engine

🏗 Project Architecture
The infrastructure includes:

VPC with public & private subnets
NAT Gateway for outbound internet
Autoscaling group across availability zones
Separate backend state for dev & prod (S3 + DynamoDB locking)
GitHub repository as the single source of truth

Terraform code is stored in GitHub, and GitHub Actions workflows automate:

Provisioning
Drift detection
Destruction

🔄 How Drift Detection Works
Terraform’s plan command supports detailed exit codes:
0 → No changes
2 → Drift detected
1 → Error

The drift detection workflow runs:
terraform plan -detailed-exitcode

If exit code 2 is returned:

Drift is confirmed
terraform apply -auto-approve runs automatically
Infrastructure is restored to the desired state
Slack notification is sent
GitHub issue is updated/closed

This enforces:
Terraform code = Single Source of Truth

🧪 Live Drift Testing
A manual change was made directly in AWS (modifying resource tags).

Result:
GitHub Actions detected drift
Terraform re-applied correct configuration
Tags reverted automatically
Slack notification confirmed remediation
GitHub issue lifecycle updated

This demonstrated real production-level drift governance.

🔐 Security & Best Practices Implemented

AWS credentials stored in GitHub Secrets
Slack webhook stored securely
Separate backend state for dev & prod
DynamoDB locking to prevent concurrent state corruption
Scheduled Cron-based drift monitoring
Manual approvals for production workflows

📌 Key Takeaways
✔ Drift detection prevents configuration inconsistencies
✔ GitHub Actions can fully automate infrastructure lifecycle
✔ Terraform exit codes enable intelligent CI/CD logic
✔ Slack integration improves operational visibility
✔ GitHub Issues provide audit traceability
✔ IaC must always be treated as the single source of truth

Day 29 – End-to-End GitOps with Terraform and ArgoCD on EKS 🚀

Jeeva — Mon, 16 Feb 2026 17:14:35 +0000

🎯 Objective
Deploy a full 3-tier application (frontend, backend, database) on an Amazon EKS cluster using:
Terraform (for infrastructure provisioning)
Public Terraform modules (for EKS & networking)
ArgoCD (for GitOps-based application delivery)
GitHub repository as the single source of truth

🏗 Architecture Overview
The project architecture includes:
✅ VPC & networking components
✅ Amazon EKS cluster & worker nodes
✅ Kubernetes namespace for the application
✅ Frontend, backend & database deployments
✅ Persistent storage using Amazon EBS
✅ ArgoCD for continuous reconciliation
✅ LoadBalancer service for external access
All Kubernetes manifests are stored in GitHub. ArgoCD continuously monitors the repository and ensures the cluster state matches the desired state defined in Git.

🔄 GitOps & Drift Detection in Action
One of the most powerful demonstrations in this session was drift detection.
Example scenario:
Manually change the number of replicas in Kubernetes.
ArgoCD immediately detects the deviation.
It automatically reverts the cluster back to the defined state in Git.

This proves a critical GitOps principle:
The Git repository is the source of truth.
Any unauthorized change is automatically corrected.
This eliminates configuration drift and improves production reliability.

🛠 Terraform Providers Used
Multiple Terraform providers were leveraged:
AWS provider – For VPC, EKS, nodes, IAM roles, EBS
Kubernetes provider – For deploying K8s resources
kubectl provider – For applying manifests like ArgoCD
Using public Terraform modules accelerated infrastructure setup while demonstrating how reusable modules simplify production deployments.

🚀 Deployment Workflow
terraform init
terraform plan
terraform apply
EKS cluster provisioning
ArgoCD installation via kubectl
Application deployment via GitHub repo
Automatic synchronization & monitoring

Persistent storage was configured using Amazon EBS volumes, ensuring stateful components like the database retain data across pod restarts.

🔐 Best Practice Discussion
Although public Terraform modules were used for speed, an important discussion highlighted:
Public modules are convenient.
Enterprises should carefully review them.
Security, compliance, and internal standards often require custom modules.

This balance between speed and control is critical in real-world environments.

📌 Key Takeaways
✔ Infrastructure and applications can be fully automated end-to-end
✔ GitOps eliminates manual deployment risks
✔ ArgoCD provides automatic drift correction
✔ EKS + Terraform enables scalable Kubernetes infrastructure
✔ Persistent storage is essential for stateful applications
✔ Public modules accelerate setup but must be reviewed in enterprise setups

🚀 Day 28 – Three-Tier Highly Available AWS Architecture with Terraform

Jeeva — Mon, 16 Feb 2026 15:25:27 +0000

🏗 Architecture Overview
The project implements a classic three-tier architecture:

Presentation Layer (Frontend)
EC2 instances in private subnets
Behind an Internet-facing Application Load Balancer
Dockerized frontend container

Logic Layer (Backend)
EC2 instances in private subnets
Behind an Internal Load Balancer
Dockerized backend container

Data Layer (Database)
Amazon RDS (Multi-AZ enabled)
Private subnet deployment
Credentials stored securely in AWS Secrets Manager

Additional components:
Bastion Host for secure SSH access
NAT Gateway for outbound internet from private subnets
Auto Scaling Groups across multiple Availability Zones
Strict Security Groups & IAM Roles

🌐 High-Level Traffic Flow

Internet
↓
Internet Gateway
↓
External ALB (Port 80)
↓
Frontend EC2 (Docker container - Port 3000)
↓
Internal ALB
↓
Backend EC2 (Docker container - Port 8080)
↓
RDS (Multi-AZ)

This ensures:
High availability
Fault tolerance
Secure network segmentation
Scalability under load

🔐 Security Architecture
Security was a major focus in this implementation.

🔹 Private Subnets
Frontend, Backend, and RDS are not publicly accessible.

🔹 Bastion Host
Used as a secure jump server to SSH into private instances.

🔹 NAT Gateway
Allows private instances to:
Pull Docker images
Install updates
Access AWS services
Without exposing them to inbound traffic.

🔹 Security Groups
ALB allows HTTP from internet
Frontend allows traffic only from ALB
Backend allows traffic only from internal ALB
Database allows traffic only from backend SG

🔹 IAM Roles
EC2 instances have least-privilege access for:
CloudWatch
Session Manager
Secrets Manager

📦 Docker Deployment on EC2
Frontend and Backend applications are:
Built as Docker images
Pushed to Docker Hub
Pulled automatically in EC2 via user-data scripts
Started during instance launch

This ensures:
Consistent deployments
Easy scaling via ASG
Reproducible environments

📈 Auto Scaling & Load Balancing

External ALB
Internet-facing
Health checks on frontend instances
Routes traffic dynamically

Internal ALB
Handles communication between frontend and backend

Auto Scaling Groups
Multi-AZ deployment
Configured min, max, desired capacity
Scales based on CPU utilization

🗄 Database Configuration
RDS setup includes:
Multi-AZ deployment
Custom DB subnet group
Parameter group configuration
Engine version specification
Secrets stored in AWS Secrets Manager

During provisioning, an issue occurred due to PostgreSQL parameter incompatibility, which was resolved by adjusting the engine version — a real-world debugging scenario.

🚀 Terraform Day 27: Automating Infrastructure with GitHub Actions (CI/CD)

Jeeva — Wed, 31 Dec 2025 14:36:54 +0000

🧱 Infrastructure Context
The pipeline manages a production-style AWS architecture:
VPC with public and private subnets
Application Load Balancer
Auto Scaling Groups
NAT Gateways
Multi-AZ deployment

The focus is not on building the infrastructure itself —
the focus is on automating its lifecycle.

🔄 CI/CD Pipeline Architecture
Pipeline Philosophy
Terraform execution is split into clear stages:
Plan
Apply
Destroy
Each stage is automated, controlled, and auditable.

🧪 Stage 1: Terraform Plan (Pull Request)
Triggered when a pull request is created.
What Happens
Terraform initializes with remote backend
terraform validate run
TFLint checks Terraform best practices
Trivy scans Terraform code for security risks
terraform plan executes
Plan output is stored as a pipeline artifact

Key Rule
❌ No infrastructure changes happen here

This stage exists purely for:
Review
Validation
Security feedback

🚀 Stage 2: Terraform Apply (Merge)
Triggered when code is merged.

Workspace Selection
Terraform workspace is selected automatically based on branch:
Branch Workspace
dev dev
test test
main prod

This ensures:
State isolation
Environment separation
Zero cross-environment interference
Apply Behavior
Terraform apply uses the saved plan
Dev/Test can auto-apply
Production requires manual approval
This enforces change control.

🔐 Production Safety Controls
Production deployments include:
Environment-level protection rules
Manual approval gates
Explicit confirmation before apply
Audit trail of who approved what
This mirrors real enterprise governance.

🔍 Security Scanning with Trivy
Security scanning is built directly into CI.
Trivy detects issues such as:
Open SSH access (0.0.0.0/0)
Public IP exposure
Missing HTTPS
Weak networking rules

Important Outcome
Security issues fail the pipeline early, before deployment.
Security is shifted left, not added later

🧨 Terraform Destroy Pipeline
Infrastructure lifecycle is incomplete without destruction.
Day 27 includes a dedicated destroy workflow:
Manually triggered
Environment selection required
Approval enforced
Fully automated teardown

Used for:
Cost control
Testing lifecycle maturity
Safe cleanup

🔑 Secrets & State Management
Secrets
AWS credentials stored in GitHub Secrets
Injected securely at runtime
Never committed to code

State
Terraform state stored in S3
DynamoDB used for state locking
No local state files
This enables team collaboration without conflicts.

🛠 Tools Used
Terraform
GitHub Actions
AWS S3 (remote state)
DynamoDB (state locking)
TFLint
Trivy

🏁 Conclusion
Day 27 demonstrates end-to-end Terraform automation using GitHub Actions.
This is not a demo pipeline.
This is a real, production-ready infrastructure workflow.

Terraform becomes:
Predictable
Secure
Auditable
Scalable
This is how modern DevOps teams manage cloud infrastructure.

🚀 Terraform Day 26: HashiCorp Cloud Platform (Terraform Cloud)

Jeeva — Wed, 31 Dec 2025 02:53:06 +0000

Day 26 focuses on HashiCorp Cloud Platform (HCP) / Terraform Cloud and why it is essential for managing Terraform at scale in real-world environments.

Running Terraform only from the CLI creates challenges around state management, secrets, automation, governance, and collaboration.
This session demonstrates how Terraform Cloud solves those problems with a managed, secure, and automated workflow.

This is how Terraform is used in production teams, not just locally.

🧠 Why Terraform Cloud Is Needed
Problems with CLI-only Terraform:
❌ Secrets stored locally or in environment variables
❌ Manual terraform plan / apply
❌ No built-in CI/CD
❌ No shared state or team visibility
❌ Hard to manage multiple environments
❌ No approval workflows for production

Terraform Cloud fixes this by providing:
✅ Encrypted remote state
✅ Secure variable & secret storage
✅ GitHub/GitLab integration
✅ Automated runs on code changes
✅ Manual approval gates
✅ Centralized logs & auditability

🏗 Terraform Cloud Architecture
Hierarchy used in Terraform Cloud:

Organization
└── Projects
└── Workspaces
└── Terraform Code

Organization → Company or personal account
Project → Logical grouping (App, Team, Cloud, Business Unit)
Workspace → Actual Terraform execution unit

🔁 Supported Workflows
1️⃣ Version Control Workflow (Recommended)
Terraform runs automatically when code is pushed
Plan and apply executed in Terraform Cloud
Full GitOps-style workflow

Best for:
Teams
Production environments
Audited infrastructure

2️⃣ CLI-Driven Workflow
Run Terraform locally
State and execution happen in Terraform Cloud
Logs visible in UI

Best for:
Local development
Migration from CLI to cloud workflows

3️⃣ API-Driven Workflow
Trigger Terraform runs via APIs
Used in advanced automation pipelines

🔐 Secure Credential Management
AWS keys stored as encrypted workspace variables
No credentials inside .tf files
No secrets in GitHub repositories
Environment variables handled securely by Terraform Cloud

⚙️ Manual Approval vs Auto Apply
Auto Apply
Useful for dev/test
Faster feedback loops
Manual Approval
Mandatory for production
Prevents accidental destruction
Strong governance control

🧪 Hands-On Demonstrations
✔ Creating Organization, Projects, and Workspaces
✔ Running Terraform via GitHub commits
✔ Handling missing AWS credentials in Terraform Cloud
✔ Switching between auto-apply and manual approval
✔ CLI integration using terraform login
✔ Resolving Terraform version mismatches

🏁 Conclusion
Day 26 marks the transition from individual Terraform usage to enterprise-grade Terraform workflows.

Terraform Cloud is not optional at scale — it is a requirement for:
Security
Automation
Collaboration
Governance
Reliability

This is how Terraform is actually used in real production environments.

🚀 Terraform Day 25: Importing Existing AWS Resources into Terraform State

Jeeva — Tue, 30 Dec 2025 17:58:02 +0000

🧠 The Core Problem Terraform Import Solves
In many environments:
AWS resources already exist
They were created manually (console / CLI)
Terraform has no knowledge of them
Terraform tries to recreate them → ❌ conflict

Example error:
Error: resource already exists

Why this happens:
Terraform only tracks what exists inside its state file
If a resource is not in state, Terraform assumes it does not exist
Terraform import fixes this by syncing reality into state.

🧱 Understanding Terraform State
terraform.tfstate is Terraform’s source of truth

It stores:
Resource IDs
Attributes
Metadata

Terraform uses state instead of calling AWS APIs repeatedly

If state is lost:
Terraform forgets everything
Import can rebuild state safely

🔄 Terraform Import Workflow
Resource already exists in AWS
Write a minimal Terraform resource block
Run terraform import
Terraform maps the live resource → state file
Terraform now manages the resource
Import updates state only, not the live resource.

📌 Terraform Import Commands Used
Import Security Group
terraform import aws_security_group.web_sg sg-xxxxxxxx

Import EC2 Instance
terraform import aws_instance.web ec2-xxxxxxxx

Verify Imported State
terraform state list
terraform state show aws_security_group.web_sg

🔍 Terraform Import vs Other Tools
Terraform Import (Recommended)
✅ Officially supported
✅ Covers all AWS resources
✅ Safe and predictable
❌ Requires manual config writing

Terraformer / AWS2TF
✅ Auto-generate config
❌ Limited resource coverage
❌ Community-maintained
❌ Often outdated or buggy

Production best practice:
Use Terraform import for accuracy and control.

🏁 Conclusion
Day 25 highlights a non-negotiable Terraform skill.

Terraform import bridges the gap between:
Manual infrastructure
Fully automated Infrastructure as Code

Without import:
Terraform fails
Conflicts occur
Automation breaks

With import:
Legacy infrastructure becomes manageable
Terraform regains control
IaC adoption becomes possible

This is how Terraform is used in real AWS environments, not just greenfield projects.

🚀 Terraform Day 24: Highly Available Web Application on AWS (ALB + ASG + Private Subnets)

Jeeva — Tue, 30 Dec 2025 02:24:43 +0000

🧱 Architecture Overview
🌐 Networking Layer
Custom VPC
Public subnets (for ALB & NAT Gateway)
Private subnets (for EC2 instances)
Internet Gateway
Route tables for controlled traffic flow

⚖️ Load Balancing
Application Load Balancer (ALB)
Target groups with health checks
Listener forwarding traffic to healthy EC2 instances

🔄 Compute & Scaling
Launch Template with:
AMI
Security groups
User data script
Auto Scaling Group:
Min, max, desired capacity
CPU-based scaling policies
Multi-AZ EC2 placement

🐳 Application Deployment
Django web app
Docker installed via EC2 user data
Container launched automatically at instance startup

🔐 Security Design
EC2 instances do not have public IPs
Instances are reachable only via ALB
Private subnets isolate application servers
NAT Gateway allows:
Docker image pulls
OS updates
Outbound internet access only
This aligns with least-exposure security principles.

🧪 Testing & Validation
✅ High Availability Test
Application remains accessible via ALB
Individual EC2 instance failure does not break the app
Traffic automatically reroutes to healthy instances

🔄 Autoscaling Test
Load generated using Apache JMeter
CPU-based scaling policies evaluated
Observed that CPU alone may not reflect real traffic load
Highlights need for memory / request-based metrics in production

🔐 Private Access Test
Direct SSH blocked due to private subnet placement
EC2 Instance Connect Endpoint used for secure access
No public exposure of application servers

🏁 Conclusion
Day 24 demonstrates how real production web platforms are built on AWS.
This is not about launching a single EC2 instance — it’s about:
Availability
Fault tolerance
Security
Scalability
Automation

By combining ALB, Auto Scaling Groups, private networking, and Docker, Terraform enables a robust, enterprise-grade hosting solution.

This project forms a strong foundation for extending into full three-tier architectures with databases, caching, and CI/CD pipelines.

🚀 Terraform Day 23: Production-Grade Monitoring & Observability on AWS (Serverless)

Jeeva — Mon, 29 Dec 2025 14:15:44 +0000

🧱 Services Used
AWS Lambda – serverless compute
Amazon S3 – source & destination buckets
Amazon CloudWatch
Logs
Metrics
Dashboards
Alarms
Amazon SNS – email notifications
AWS CloudTrail – API activity auditing
Terraform (custom modules) – full automation

🧩 Terraform Architecture (Modular)
The project is split into multiple custom Terraform modules:
s3 – secure buckets with encryption & versioning
lambda – function, IAM role, permissions
cloudwatch_logs – log groups & filters
cloudwatch_metrics – custom metrics
cloudwatch_alarms – alert definitions
sns – notification channels
This mirrors real enterprise Terraform layouts.

📊 Observability Implementation
1️⃣ Logs (CloudWatch Logs)
Lambda logs are captured and analyzed using log metric filters.
Tracked patterns include:
Processing errors
Invalid file uploads
Large file sizes
Access denied events
Successful executions

Regex-based filters convert logs into metrics.

2️⃣ Custom Metrics
Beyond default Lambda metrics, custom metrics include:
Images processed successfully
Image processing failures
Invalid file types
Processing duration thresholds
File size violations

These metrics provide application-level visibility, not just infrastructure stats

3️⃣ Dashboards
A CloudWatch Dashboard is created entirely via Terraform (JSON):

Widgets include:
Invocation count
Error rate
Duration (Avg + P99 latency)
Concurrent executions
Custom error metrics
Log-based error trends

This dashboard is production-ready.

4️⃣ Alerts & Alarms
Multiple alarm categories are implemented:
❌ Lambda errors
⏱️ High execution duration
🔥 Concurrency limit breaches
📉 Invalid file uploads
🚫 Log-based failures

All alarms are parameterized via Terraform variables.

5️⃣ Notifications (SNS)
Separate SNS topics for alert types
Email subscriptions (manual confirmation)
Real-time alert delivery when alarms trigger

This completes the incident response loop.

🐋 Dockerized Lambda Layer Build

To avoid the classic “works on my machine” problem:
Lambda dependencies (Pillow) are built using Docker
Ensures compatibility with AWS Lambda Linux runtime
Terraform deploys the generated layer artifact

This is production-grade dependency management.

🧪 Testing & Failure Simulation
The project is actively tested by:
Uploading valid images → metrics increase
Uploading invalid files (PDF/GIF) → error alarms trigger
Uploading large files → size alarms trigger
Uploading multiple files → concurrency alarms trigger

Alerts are received via email in real time.

This proves the system actually works.

🚀 Terraform Day 22: Secure Two-Tier Architecture on AWS (EC2 + RDS)

Jeeva — Sun, 28 Dec 2025 11:39:54 +0000

🧱 Architecture Overview
The deployed architecture consists of:

🌐 Web Tier
EC2 instance in a public subnet
Accessible via public DNS
Runs a Flask application
Uses Security Groups to restrict inbound access

🗄️ Database Tier
MySQL RDS instance
Hosted in private subnets
No direct internet access
Accepts traffic only from web tier security group

🔐 Secrets Management
Database username & password generated dynamically
Stored securely in AWS Secrets Manager
Retrieved by EC2 during boot via user data

🧩 Terraform Module Design

This project is built using custom Terraform modules, a critical real-world practice.

Modules used:

VPC module
VPC
Public & private subnets
Internet Gateway
NAT Gateway
Route tables

Security Group module
Web SG (HTTP access)
DB SG (MySQL access only from web SG)

Secrets module
Random password generation
Secrets Manager storage

RDS module
MySQL instance
Private subnet placement
Credentials injected from Secrets Manager

The root module orchestrates everything by passing outputs between modules.

🔐 Secure Credential Handling (Critical)

One of the most important lessons in Day 22:
_
❌ No credentials in Terraform code
❌ No credentials in variables.tf
❌ No credentials in user data scripts

✅ Password generated using random_password
✅ Stored in AWS Secrets Manager
✅ Retrieved securely at runtime_

This is mandatory in real production environments.

⚙️ Application Deployment with User Data

The EC2 instance uses user data to:
Install system dependencies
Install Python and Flask
Fetch database credentials from Secrets Manager
Configure environment variables
Start the Flask application automatically

Result:
Infrastructure and application deploy together — fully automated.

🔄 Terraform Workflow Used

Standard, production-safe workflow:
terraform init
terraform plan
terraform apply

Notes:
RDS provisioning takes time — expected behavior
Outputs expose application endpoint safely
Infrastructure must be destroyed after testing to avoid costs

🚀 Terraform Day 21: Policy & Governance Automation on AWS

Jeeva — Fri, 26 Dec 2025 16:10:38 +0000

🎯 What Day 21 Is About

Day 21 demonstrates how to:
Enforce preventive controls using IAM policies
Enable detective controls using AWS Config
Store audit logs securely in S3
Detect non-compliant resources automatically
Troubleshoot real-world permission behavior

This is not theory — it’s hands-on governance automation.

🧠 Policy vs Governance (Core Concept)

Understanding this distinction is mandatory in real projects:

🔐 Policy (Preventive Control)
Implemented using IAM policies
Blocks actions before they happen

Example:
Deny delete without MFA
Deny uploads without encryption
Deny resource creation without required tags

📊 Governance (Detective Control)
Implemented using AWS Config
Detects violations after resources exist

Example:
Unencrypted buckets
Public access enabled
Missing mandatory tags

👉 Policy stops mistakes. Governance reports mistakes.
Both are required.

🗂️ Secure Audit Bucket with Terraform

A dedicated S3 bucket is created for governance logs.
Configured with:
✅ Server-side encryption
✅ Versioning enabled
✅ Public access fully blocked
✅ Bucket policy allowing AWS Config access
This bucket becomes the single source of truth for audit data.

Audit logs must be immutable, private, and durable — Terraform enforces this by design.

🔒 IAM Policies for Enforcement
Multiple custom IAM policies are created using Terraform.
Examples covered:
MFA enforcement for destructive actions
Encryption-in-transit enforcement for S3 uploads
Mandatory EC2 tagging to enforce cost and ownership standards

These policies are:
Written as JSON
Managed via Terraform
Attached to users and roles programmatically

This ensures rules are consistent, repeatable, and reviewable.

📈 AWS Config for Continuous Compliance

AWS Config is enabled end-to-end using Terraform:

Components created:
Config Recorder
Delivery Channel pointing to the audit bucket
Managed compliance rules

Rules demonstrated:
S3 public access prohibited
Encryption enabled on buckets and EBS volumes
Required resource tags
Root account MFA enabled

AWS Config continuously evaluates infrastructure and reports compliance status automatically

✅ Key Takeaways

✔ Policy = prevention
✔ Governance = detection
✔ Terraform can automate both
✔ Secure audit logging is non-negotiable
✔ AWS Config complements IAM — it does not replace it
✔ Testing policies is as important as writing them

This is how production AWS accounts are protected.

🚀 Terraform Day 20: Building Production Infrastructure Using Custom Terraform Modules

Jeeva — Thu, 25 Dec 2025 16:33:08 +0000

🧠 What Is a Terraform Module?
A Terraform module is a reusable, self-contained package of Terraform code.

A module typically contains:
main.tf – resources
variables.tf – inputs
outputs.tf – exposed values
Terraform treats every directory as a module.

Modules allow you to:
Encapsulate complexity
Enforce standards
Reuse infrastructure patterns
Scale cleanly across teams and environments

🧩 Types of Terraform Modules
1️⃣ Public Modules
Available from Terraform Registry
Maintained by providers or the community
Cannot be modified internally

2️⃣ Partner Modules
Co-managed by HashiCorp and partners
Verified and production-ready
Still externally controlled.

3️⃣ Custom Modules (Focus of Day 20)
Created and maintained by you or your organization
Full control over:
Code
Versioning
Security
Updates
👉 Production systems rely heavily on custom modules.

🏗 Root Module vs Custom Modules
🔹 Root Module
Entry point of the Terraform project
Where terraform init and terraform apply are executed
Orchestrates the entire infrastructure
Sources and connects custom modules

🔹 Custom Modules
Stored as subdirectories inside the root module
Each module has a single responsibility
Do not directly communicate with each other
The root module acts as the central coordinator.

📂 Typical Project Structure (Day 20 Style)
terraform-project/
├── main.tf # Root module
├── variables.tf
├── outputs.tf
├── modules/
│ ├── vpc/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ ├── eks/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ ├── iam/
│ └── secrets/
Each module encapsulates a single infrastructure domain.

🔁 How Modules Interact (Very Important)
Custom modules never talk to each other directly.

All communication happens through the root module:
Root module calls a custom module
Passes input variables
Custom module creates resources
Custom module exposes outputs
Root module consumes outputs
Outputs are passed into other modules as inputs

This ensures:
Loose coupling
Clear dependency flow
Maintainable architecture

🔗 Example: VPC → EKS Dependency Flow

VPC module outputs vpc_id
Root module captures vpc_id
Root module passes vpc_id into EKS module
EKS resources are created inside the correct VPC This pattern scales cleanly as infrastructure grows.

📥 Variables & Outputs in Modular Design
Variables
Define what a module expects
Passed from the root module
Keep modules flexible

Outputs
Define what a module exposes
Used by the root module
Enable inter-module coordination

Modules behave like functions:
Inputs → Processing → Outputs

🏁 Conclusion
Day 20 transitions Terraform from learning mode to architecture mode.

This session makes it clear that:

Terraform is not just about resources
Terraform is about designing systems
Custom modules are the backbone of production IaC

By mastering modular Terraform architecture, you unlock the ability to build large, maintainable, enterprise-grade cloud platforms.

This is how Terraform is used in the real world.

🚀 Terraform Day 19: Provisioners — Bootstrapping Infrastructure with Automation

Jeeva — Thu, 25 Dec 2025 07:51:27 +0000

🎯 What Are Terraform Provisioners?

Provisioners are execution blocks that run during the lifecycle of a Terraform resource.

They are commonly used to:
Run scripts
Install packages
Copy files
Perform post-creation setup

Provisioners execute only when a resource is created or recreated.
Terraform remains declarative — provisioners are optional escape hatches.

🧰 Types of Terraform Provisioners

Terraform supports three main provisioners:

_1️⃣ local-exec
Runs commands on the machine where Terraform is executed.

2️⃣ remote-exec
Runs commands on the remote resource (e.g., EC2 instance) via SSH.

3️⃣ file
Copies files from local machine to remote resource over SSH._
Each has a distinct purpose and execution context.

🖥️ Local-Exec Provisioner

local-exec runs locally, not on AWS.
Example use cases:
Logging instance details
Running validation scripts
Triggering local automation

Example:
provisioner "local-exec" {
command = "echo Instance ID: ${self.id}, Public IP: ${self.public_ip}"
}
🔹 No SSH required
🔹 Runs on your laptop / CI runner
🔹 Useful for notifications or metadata handling

🖧 Remote-Exec Provisioner

remote-exec runs commands inside the EC2 instance.
Requirements:
SSH access
Key pair
Security group allowing port 22

Example:
provisioner "remote-exec" {
inline = [
"sudo yum update -y",
"echo 'Provisioned by Terraform' > /tmp/info.txt"
]
}

This is commonly used to:
Install packages
Configure services
Bootstrap servers

📁 File Provisioner

The file provisioner copies files to remote instances.
Example:
provisioner "file" {
source = "welcome.sh"
destination = "/home/ec2-user/welcome.sh"
}

Typical pattern:
Copy script using file
Execute script using remote-exec
This allows complex bootstrapping logic.

🔐 SSH & Key Pair Requirements

For remote-exec and file provisioners:
EC2 key pair must exist
Private key must have correct permissions
chmod 400 my-key.pem

Terraform connection block example:
connection {
type = "ssh"
user = "ec2-user"
private_key = file("my-key.pem")
host = self.public_ip
}
Without proper SSH setup, provisioners will fail.

🔄 Understanding Provisioner Execution Behavior

Provisioners do not run on every terraform apply.
They run only when:
A resource is created
A resource is recreated
If no changes are detected, provisioners are skipped.

⚠️ Forcing Provisioners with terraform taint

To force re-execution:
terraform taint aws_instance.example
terraform apply

This:
Marks the resource as dirty
Forces destruction and recreation
Triggers provisioners again
This highlights Terraform’s state-driven behavior.

🏁 Conclusion

Day 19 provides a clear and honest view of Terraform provisioners.

They are powerful, but must be used carefully and intentionally.
Understanding how and when they execute is critical to avoiding unexpected behavior.

This session strengthens your grasp of Terraform internals, state-driven execution, and real-world automation patterns.

Provisioners are not the default tool —
but knowing them makes you a stronger Terraform engineer.