DEV Community: GOKULPRASATH N

Day 6/30: Organising Terraform – File Structure Best Practices 📂✨

GOKULPRASATH N — Sat, 29 Nov 2025 13:35:41 +0000

Day 6/30: Organizing Terraform – File Structure Best Practices 📂✨
Today marks Day 6 of my #30daysofAWSTerraform challenge! 🚀 As the codebase grows, keeping everything in a single main.tf file becomes unmanageable. Today, I learned how to modularize and organize Terraform files for better readability, maintainability, and scalability.
I refactored my monolithic code into a standard professional structure used by DevOps teams worldwide.

✅ Tasks Completed:

Refactoring: Split the single main.tf into logical files (providers.tf, variables.tf, outputs.tf).
Backend Isolation: Created a dedicated backend.tf to manage the Remote State configuration separately.
Variable Management: Moved variable definitions to variables.tf and actual values to terraform.tfvars.
Security Best Practices: Created a .gitignore file to prevent sensitive files like terraform.tfvars, .terraform/, and *.tfstate from being pushed to GitHub.

📝 Notes:
Standard File Structure:

main.tf → Core resource definitions (EC2, VPC, S3).
variables.tf → Declaration of input variables.
outputs.tf → Definition of output values (e.g., IPs, IDs).
providers.tf → Provider configuration and version constraints.
terraform.tfvars → Environment-specific values (GitIgnored!). Why split? It makes collaboration easier, code reviews faster, and helps avoid merge conflicts in large teams.

🔗 Resources:
Video I watched: https://www.youtube.com/watch?v=QMsJholPkDY
Mentor: Piyush Sachdeva

I am excited to dive into Type Constraints tomorrow to make my variables even more robust!

AWS #Terraform #CloudEngineering #DevOps #InfrastructureAsCode #techtutorialswithpiyush #TheCloudOpsCommunity #30daysofAWSTerraform

Day 5/30: The Power of Variables – DRY Principles & Precedence 🔄🏗️

GOKULPRASATH N — Fri, 28 Nov 2025 16:27:12 +0000

Today marks Day 5 of my #30daysofAWSTerraform challenge! 🚀 I moved beyond hardcoding values and explored Terraform Variables, a game-changer for writing reusable, clean, and scalable Infrastructure as Code.
By extracting values like Region, AMI IDs, and Instance Types into variables.tf, I learned how to deploy the exact same infrastructure across Dev, Staging, and Prod without rewriting a single line of the main configuration.

✅ Tasks Completed:
Input Variables: Created a variables.tf file to define reusable inputs (e.g., variable "instance_type") with default values and type constraints (String, Number, Bool).
Code Refactoring: Updated main.tf to replace hardcoded strings with var., making the code modular.
Variable Precedence: Experimented with different ways to assign values (CLI flags, Environment Variables, terraform.tfvars, Default values) and learned the order of precedence (CLI > tfvars > Env Var > Default).
Locals: Used locals block to perform intermediate calculations (e.g., combining resource names with project IDs) to avoid repetition inside resources.
Output Variables: Defined outputs.tf to print useful information (like the EC2 Public IP) to the console after terraform apply finishes.

📝 Notes:
DRY Principle: "Don't Repeat Yourself." If you copy-paste a value more than twice, turn it into a variable.
Security: Never commit terraform.tfvars if it contains sensitive secrets (add it to .gitignore!).
Type Safety: Always define type = string or type = number to catch errors early during terraform plan rather than failing mid-deployment.

🔗 Resources:
Video I watched: https://youtu.be/V-2yC39BONc?si=LmmQmXKh16BKAi2d
Mentor: Piyush Sachdeva

I am excited to learn about File Structure tomorrow to organize my growing code base!

AWS #Terraform #CloudEngineering #DevOps #InfrastructureAsCode #techtutorialswithpiyush #TheCloudOpsCommunity

30daysofAWSTerraform

Day 4/30: The Heart of Terraform – State Files & Remote Backends 🧠🗄️

GOKULPRASATH N — Thu, 27 Nov 2025 18:35:41 +0000

Today marks Day 4 of my #30daysofAWSTerraform challenge! 🚀 I explored the most critical component of Terraform: the State File (terraform.tfstate). It acts as the database for your infrastructure, mapping your code to real-world AWS resources.
I also learned why storing state locally is a recipe for disaster in team environments and how to move it to a secure Remote Backend using AWS S3.

✅ Tasks Completed:

State Analysis: Inspected the terraform.tfstate JSON file to understand how it stores metadata and resource attributes.
Remote Backend Setup: Configured an S3 bucket as a remote backend to store the state file securely instead of keeping it on my local machine.
State Locking: Enabled state locking (using S3/DynamoDB concepts) to prevent multiple team members from corrupting the state by running apply simultaneously.
Migration: Successfully initialized the backend (terraform init) to migrate my local state to the remote S3 bucket.

📝 Notes:

The Golden Rule: NEVER edit the terraform.tfstate file manually. It causes drift and can break your infrastructure mapping.
The Solution: Use a Remote Backend (like S3) to share state across the team, encrypt sensitive data, and enable locking.
Drift Detection: Terraform uses the state file to calculate the "delta" between your Desired State (Code) and Actual State (AWS).

🔗 Resources:
My Code & Progress: https://github.com/Gokulprasath-N/Terraform-Full-Course-Aws/tree/main/lessons/day04
Video I watched: https://www.youtube.com/watch?v=YsEdrl9O5os
Mentor: Piyush Sachdeva

I am excited to dive into Variables tomorrow to make my code more reusable!

AWS #Terraform #CloudEngineering #DevOps #InfrastructureAsCode #techtutorialswithpiyush

30daysofAWSTerraform

Day 3/30: My First Resource – S3 Bucket! 🪣☁️

GOKULPRASATH N — Wed, 26 Nov 2025 15:38:39 +0000

Today marks Day 3 of my #30daysofAWSTerraform challenge! 🚀 After setting up the provider yesterday, I provisioned my very first AWS resource: a Simple Storage Service (S3) bucket.
It might seem simple, but this exercise covered the entire Terraform Lifecycle—creation, modification, and destruction—proving that infrastructure is no longer static!

✅ Tasks Completed:
Resource Definition: Wrote the aws_s3_bucket block by referencing the official Terraform Registry documentation.
Full Lifecycle Execution: Ran the complete workflow: init → plan → apply (Creation) → destroy (Cleanup).
State Updates: Modified the bucket tags in the code and ran apply again to see how Terraform detects changes ("1 to change") without recreating the resource.
Automation: Used the -auto-approve flag to bypass the manual "yes" confirmation prompt (for lab environments only!).

📝 Notes:
Global Uniqueness: learned that S3 bucket names must be globally unique across all AWS accounts, not just mine.
Resource Syntax: resource "_" "" (e.g., resource "aws_s3_bucket" "my_bucket").
Idempotency: Terraform is smart enough to know that if I run apply twice without code changes, nothing happens.

AWS #Terraform #CloudEngineering #DevOps #InfrastructureAsCode #techtutorialswithpiyush

30daysofAWSTerraform

Day 2/30: Mastering Terraform Providers & Version Constraints 🧩☁️

GOKULPRASATH N — Tue, 25 Nov 2025 14:19:01 +0000

Today marks Day 2 of my #30daysofAWSTerraform challenge! 🚀 After setting up the foundation, I dove deep into Providers—the engines that power Terraform—and learned why version control is critical for production stability.

We often assume Terraform init just "works," but understanding what it downloads and how to lock versions prevents breaking changes when a provider updates unexpectedly.

✅ Tasks Completed:

Provider Configuration: Defined the AWS provider block and understood the difference between Official, Partner, and Community providers.

Version Locking: Implemented required_providers to lock the AWS provider version using the pessimistic operator (~>) to ensure stability while allowing safe patch updates.

Initialisation: Ran Terraform init to download the specific provider plugins required for the project.

Authentication: Configured the AWS CLI (aws configure) to allow Terraform to interact with my AWS account securely.

📝 Notes:

What is a Provider? A plugin that translates HCL code into API calls that the Cloud Provider (AWS/Azure/GCP) understands.

Version Constraints:

version = "5.0" -> Exact match (Safest but rigid).

version = "~> 5.0" -> Allows updates to 5.x but prevents breaking changes in 6.0.

The "Dependency Hell" Solution: Always separate the Terraform CLI version (required_version) from the Provider version (required_providers) to avoid compatibility issues.

🔗 Resources:

My Code & Progress: https://github.com/Gokulprasath-N/Terraform-Full-Course-Aws/tree/main/lessons/day02

Video I watched: https://www.youtube.com/watch?v=JFiMmaktnuM

I am excited to start provisioning actual resources like VPCs and EC2 instances tomorrow!

AWS #Terraform #CloudEngineering #DevOps #InfrastructureAsCode #techtutorialswithpiyush #30daysofAWSTerraform

Day 1/30: The Foundation – Why Terraform?

GOKULPRASATH N — Mon, 24 Nov 2025 15:29:29 +0000

Today marks the start of my #30daysofAWSTerraform challenge! 🚀 Before writing code, I focused on understanding why we need Infrastructure as Code (IaC) and setting up a robust development environment.
We often underestimate the pain of manual clicking in the AWS Console—until we have to replicate an environment for Production and everything breaks. Terraform solves this by treating infrastructure as software.

🏗️ What is Terraform?
Terraform is an open-source Infrastructure as Code (IaC) tool created by HashiCorp. It allows you to define and provision data center infrastructure using a high-level configuration language called HCL (HashiCorp Configuration Language).

Think of it as a blueprint for your cloud. Instead of manually clicking through the AWS console to create servers, databases, and networks, you write code that describes what you want, and Terraform makes it happen.

🔑 Core Purpose
Provisioning: Build infrastructure from scratch (e.g., AWS EC2, VPC, S3).
Management: Update and version control your infrastructure just like application code.
Cloud-Agnostic: Works with AWS, Azure, Google Cloud, Kubernetes, and hundreds of other providers.

💡 Why Do We Need It? (The "Why")
Before Terraform, managing infrastructure was painful:
Manual Clicking: "ClickOps" is slow, tedious, and prone to human error.
Inconsistency: "It works on my machine" issues because Dev and Prod environments drifted apart.
No History: Hard to track who changed what and when.
Terraform solves this by:
Automation: Spin up entire environments in minutes.
Consistency: The same code creates the exact same infrastructure every time.
Version Control: Track changes in Git/GitHub.

🛠️ Installation Guide
To get started, you need to install the Terraform CLI on your local machine.

For Windows
Download the binary from the official website. url: https://developer.hashicorp.com/terraform/install#windows --> Extract the .zip file --> Add the folder containing terraform.exe to your system's PATH environment variable --> Verify: Open PowerShell and run: terraform -version

✅ Tasks Completed:
Mastered IaC Concepts: Learned how Terraform solves the "It works on my machine" problem by ensuring consistency across Dev, Staging, and Prod.
Tooling Setup: Successfully installed Terraform CLI and verified the version.
Workflow Optimisation: Set up shell aliases (tf=terraform) and autocompletion to save time on future commands.
IDE Setup: Configured VS Code with the HashiCorp extension for better syntax support.

📝 Notes:
The Problem: Manual infrastructure takes hours/days and is prone to human error.
The Solution: Terraform interacts with Cloud APIs (like AWS) to provision resources automatically using HCL (HashiCorp Configuration Language).
Core Workflow: Write -> Plan (Dry Run) -> Apply (Create) -> Destroy (Clean up).

🔗 Resources:
My Code & Progress: https://github.com/Gokulprasath-N/Terraform-Full-Course-Aws
Video I watched: https://www.youtube.com/watch?v=xUtGqC-NXJE

I am excited to start writing actual HCL code tomorrow!

AWS #Terraform #CloudEngineering #DevOps #InfrastructureAsCode #techtutorialswithpiyush