Neeraj Kumar’s Post

“Terraform becomes powerful only when you understand its core commands. Here’s a quick cheat sheet that every DevOps engineer should know!” 🚀 Mastering Terraform Commands – Your Quick Cheat Sheet! If you're working with Infrastructure as Code, understanding Terraform commands is a game changer. Here’s a simple breakdown that can level up your workflow 👇 🔹 terraform init The starting point. It initializes your workspace, downloads required provider plugins, and sets up backend state configuration. 🔹 terraform plan Your preview mode. It shows exactly what changes Terraform will make—before anything is applied. Think of it as a safety checkpoint ✅ 🔹 terraform apply Time to execute! This command provisions or updates your infrastructure based on the plan. You’ll be prompted before real changes happen. 🔹 terraform destroy Need to tear everything down? This command safely removes all resources defined in your configuration. 🔹 terraform validate Catches syntax errors early. A must-run before planning or applying changes. 🔹 terraform fmt Keeps your code clean and consistent. Automatically formats your configuration files for better readability ✨ 🔹 terraform show & terraform state Provides deep visibility into your infrastructure state and helps manage it effectively. 💡 Pro Tip: Always run terraform plan before apply — it can save you from costly mistakes! #Terraform #DevOps #CloudComputing #InfrastructureAsCode #AWS #Azure #Automation #TechTips

🚀 How Terraform Works in a Real Production Environment Most people think Terraform is just about writing `.tf` files… but in reality, it’s all about the **𝗲𝗻𝗱-𝘁𝗼-𝗲𝗻𝗱 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄** that makes deployments reliable and production-ready. Here’s a simplified flow I follow: 🔹 Code is maintained in GitHub (version control is the backbone) 🔹 Remote state is securely stored in Azure Storage 🔹 CI/CD pipelines (Azure Pipelines) handle automation 📌 Step-by-step approach: ➡️ Pull code from repo to local ➡️ Create a feature branch ➡️ Make infrastructure changes ➡️ Commit & push changes ➡️ Run `terraform plan` for validation ➡️ Raise PR for review ➡️ Merge to main & trigger deployment 💡 Why this matters: ✔️ No direct changes in production ✔️ Full visibility via PR reviews ✔️ Safe deployments with plan validation ✔️ Centralized & secure state management ✔️ Scalable and team-friendly workflow 👉 Terraform is not just a tool, it’s a **𝗽𝗿𝗼𝗰𝗲𝘀𝘀 + 𝗱𝗶𝘀𝗰𝗶𝗽𝗹𝗶𝗻𝗲 + 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆**. Would love to know — how are you managing your Terraform workflows in production? #Terraform #DevOps #Azure #InfrastructureAsCode #CloudComputing #Automation #GitHub #CICD #Tech

 🚀 𝗘𝗮𝘀𝗶𝗲𝘀𝘁 𝘄𝗮𝘆 𝘁𝗼 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗗𝗿𝗶𝗳𝘁 (𝗭𝗲𝗿𝗼 𝗗𝗿𝗶𝗳𝘁) Today I cleared a very important DevOps concept: Terraform Drift — and it’s something every engineer should know 👇 🔹 𝗥𝗲𝗺𝗲𝗺𝗯𝗲𝗿 𝘁𝗵𝗲𝘀𝗲 𝟯 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀: 1️⃣ Terraform Code (.tf file) → What you want (Desired State) 2️⃣ Terraform State (.tfstate) → What Terraform remembers 3️⃣ Azure Portal (Real Infra) → What actually exists --- 💥 𝗪𝗵𝗲𝗻 𝗱𝗼𝗲𝘀 𝗱𝗿𝗶𝗳𝘁 𝗵𝗮𝗽𝗽𝗲𝗻? When someone makes a manual change in Azure (for example: adds a tag "env=prod") ➡️ But that change is NOT present in Terraform code 👉 Result = Mismatch = Drift --- 🔍 𝗛𝗼𝘄 𝘁𝗼 𝗱𝗲𝘁𝗲𝗰𝘁 𝗶𝘁? terraform plan 👉 It compares desired vs actual 👉 And shows: “Change detected” --- ✅ 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗭𝗲𝗿𝗼 𝗗𝗿𝗶𝗳𝘁? When all three are perfectly aligned: ✔️ Code ✔️ State ✔️ Real Infrastructure --- 🔥 𝗣𝗿𝗼 𝗧𝗶𝗽: Don’t just learn theory — try this: 👉 Create a Resource Group using Terraform 👉 Make a manual change in Azure Portal 👉 Run "terraform plan" 💡 That’s when the concept truly clicks! --- #𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 #𝗗𝗲𝘃𝗢𝗽𝘀 #𝗔𝘇𝘂𝗿𝗲 #𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗔𝘀𝗖𝗼𝗱𝗲 #𝗖𝗹𝗼𝘂𝗱𝗖𝗼𝗺𝗽𝘂𝘁𝗶𝗻𝗴 #𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴

🚀 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 — 𝗧𝗵𝗲 𝗛𝗶𝗱𝗱𝗲𝗻 𝗘𝗻𝗴𝗶𝗻𝗲 𝗕𝗲𝗵𝗶𝗻𝗱 𝗥𝗲𝗹𝗶𝗮𝗯𝗹𝗲 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 One of the biggest mistakes beginners make in Terraform is assuming that infrastructure is only about writing resource blocks. In reality, successful infrastructure is all about orchestration. 💡 𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗶𝘀: Not what resources you create — but in what order they are created. That’s where Terraform dependency becomes critical. 🔍 𝗪𝗵𝘆 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗠𝗮𝘁𝘁𝗲𝗿𝘀 Imagine creating: a Resource Group a Storage Account 𝗔 𝗦𝘁𝗼𝗿𝗮𝗴𝗲 𝗔𝗰𝗰𝗼𝘂𝗻𝘁 𝗰𝗮𝗻𝗻𝗼𝘁 𝗲𝘅𝗶𝘀𝘁 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗮 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝗚𝗿𝗼𝘂𝗽 𝗳𝗶𝗿𝘀𝘁. If Terraform doesn’t understand this relationship: ❌ resources may try to create in parallel ❌ deployment can fail ❌ pipelines become unreliable ⚙️ How Terraform Handles Dependency 1️⃣ Implicit Dependency (Automatic) Terraform is smart enough to detect relationships when one resource references another. 𝗘𝘅𝗮𝗺𝗽𝗹𝗲: A Storage Account using a Resource Group name from another resource. ➡️ Terraform automatically understands the order. 2️⃣ Explicit Dependency (depends_on) Sometimes, there is no direct reference between resources — but you still need controlled execution. 𝗧𝗵𝗮𝘁’𝘀 𝘄𝗵𝗲𝗿𝗲 𝗱𝗲𝗽𝗲𝗻𝗱𝘀_𝗼𝗻 𝗵𝗲𝗹𝗽𝘀. Use it when: ✔️ no direct resource reference exists ✔️ execution order is critical ✔️ you want to avoid race conditions 🧠 𝗞𝗲𝘆 𝗜𝗻𝘀𝗶𝗴𝗵𝘁: By default, Terraform tries to create resources in parallel to save time. That’s efficient — but only when dependencies are clear. If dependency is not defined properly: ⚠️ deployments can fail unexpectedly ⚠️ troubleshooting becomes painful 💥 𝗥𝗲𝗮𝗹 𝗗𝗲𝘃𝗢𝗽𝘀 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴: Infrastructure is not just provisioning. It’s about building systems that are: reliable predictable scalable 𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗶𝗲𝘀 𝗺𝗲𝗮𝗻𝘀: ✅ cleaner code ✅ safer deployments ✅ stronger production confidence Great infrastructure isn’t just built — it’s orchestrated with precision. #Terraform #DevOps #InfrastructureAsCode #Azure #CloudComputing #IaC #DevOpsEngineer #CloudAutomation #PlatformEngineering #SRE

Terraform Commands Every DevOps Engineer Should Know 🔹 terraform init Initializes the working directory, downloads providers & sets up backend. 🔹 terraform plan Shows execution plan — what Terraform will change. 🔹 terraform apply Applies changes to create/update infrastructure. 🔹 terraform destroy Deletes all managed resources (use carefully ⚠️). 🔹 terraform fmt Formats your code to standard style (clean & readable). 🔹 terraform show Displays the current state or execution plan in detail. 🔹 terraform output Shows output variables (like IPs, URLs). 🔹 terraform refresh (legacy but useful to know) Updates state file based on real infrastructure. 🔹 terraform state list Lists all resources in the Terraform state. 🔹 terraform state show Displays detailed info about a specific resource. 🔹 terraform import Brings existing resources under Terraform management. 🔹 terraform taint / untaint Marks resources for recreation (less used now but important concept). 💡 Pro Tip: Always run plan → apply, never directly apply in production. 👉 Terraform is not just commands — it’s about safe, predictable infrastructure automation. #Terraform #DevOps #InfrastructureAsCode #Cloud #Azure #Automation #DevOpsTools

Terraform Commands Every DevOps Engineer Should Know 🔹 terraform init Initializes the working directory, downloads providers & sets up backend. 🔹 terraform plan Shows execution plan — what Terraform will change. 🔹 terraform apply Applies changes to create/update infrastructure. 🔹 terraform destroy Deletes all managed resources (use carefully ⚠️). 🔹 terraform fmt Formats your code to standard style (clean & readable). 🔹 terraform show Displays the current state or execution plan in detail. 🔹 terraform output Shows output variables (like IPs, URLs). 🔹 terraform refresh (legacy but useful to know) Updates state file based on real infrastructure. 🔹 terraform state list Lists all resources in the Terraform state. 🔹 terraform state show Displays detailed info about a specific resource. 🔹 terraform import Brings existing resources under Terraform management. 🔹 terraform taint / untaint Marks resources for recreation (less used now but important concept). 💡 Pro Tip: Always run plan → apply, never directly apply in production. 👉 Terraform is not just commands — it’s about safe, predictable infrastructure automation. #Terraform #DevOps #InfrastructureAsCode #Cloud #Azure #Automation #devopstools

Day 20 of the 30-Day Terraform Challenge — Workflow for Deploying Application Code with Terraform Today was less about writing Terraform and more about operating it like a real engineering workflow. I implemented the full seven-step deployment process using my webserver cluster: • Version control with Git and feature branching • Change validation using terraform plan • Pull request with plan output for review • Automated checks (fmt, validate, test) • Version tagging for release tracking • Remote execution using HCP Terraform • Deployment verification through an Application Load Balancer The key shift today was moving from local execution to remote execution in Terraform Cloud. This introduced proper state management, audit logs, and secure handling of sensitive variables through workspace configuration. One of the biggest lessons is that infrastructure changes must follow the same discipline as application code. Terraform plan becomes your preview, your safety net, and your review artifact. Skipping that step is where most mistakes happen. I also explored how private registries enable teams to version and reuse infrastructure modules, making Terraform workflows scalable across projects. Final result: Successfully deployed infrastructure with version v3 visible through the ALB endpoint, confirming that the workflow from change to production works end to end. This is where Infrastructure as Code stops being just scripts and starts becoming a proper engineering system. #30DayTerraformChallenge #Terraform #TerraformCloud #DevOps #IaC #AWS #CloudComputing #InfrastructureAsCode #GitOps #AWSUserGroupKenya #EveOps

🚨 𝗠𝘆 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗱𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗳𝗮𝗶𝗹𝗲𝗱... 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗿𝗲𝗮𝘀𝗼𝗻 𝘀𝘂𝗿𝗽𝗿𝗶𝘀𝗲𝗱 𝗺𝗲! Last week, I was deploying infrastructure on Azure using Terraform. Everything looked perfect — clean code, no syntax errors. I ran `terraform apply`… and boom ❌ The deployment failed. After debugging for a while, I realized the issue wasn’t the code… 👉 it was the 𝘥𝘦𝘱𝘦𝘯𝘥𝘦𝘯𝘤𝘺. 🔍 𝗪𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘄𝗲𝗻𝘁 𝘄𝗿𝗼𝗻𝗴? I was trying to create a 𝘚𝘶𝘣𝘯𝘦𝘵 before the 𝘝𝘪𝘳𝘵𝘶𝘢𝘭 𝘕𝘦𝘵𝘸𝘰𝘳𝘬 was fully ready. Even though the code looked correct, Terraform didn’t clearly understand the dependency. 💡 𝗧𝗵𝗮𝘁’𝘀 𝘄𝗵𝗲𝗻 𝗶𝘁 𝗰𝗹𝗶𝗰𝗸𝗲𝗱... In Terraform, dependency defines the 𝗼𝗿𝗱𝗲𝗿 𝗶𝗻 𝘄𝗵𝗶𝗰𝗵 𝗿𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀 𝗮𝗿𝗲 𝗰𝗿𝗲𝗮𝘁𝗲𝗱. If the order is wrong → your deployment will fail. 🔗 𝗧𝘆𝗽𝗲𝘀 𝗼𝗳 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 ✅ I𝗺𝗽𝗹𝗶𝗰𝗶𝘁 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 (𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗰) When one resource references another, Terraform automatically creates the correct order. ✅ 𝗘𝘅𝗽𝗹𝗶𝗰𝗶𝘁 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 (`𝗱𝗲𝗽𝗲𝗻𝗱𝘀_𝗼𝗻`) When Terraform cannot detect it, you must define it manually. 👉 Correct Flow: Resource Group → Virtual Network → Subnet 💡 𝗟𝗲𝘀𝘀𝗼𝗻 𝗟𝗲𝗮𝗿𝗻𝗲𝗱: Even if your Terraform code is correct… 👉 missing dependency can break everything. 👉 Have you ever faced a similar issue in Terraform? Would love to hear your experience 👇 Learning with DevOps Insiders #Terraform #DevOps #Azure #InfrastructureAsCode #Learning

Instead of humans clicking through 10 different UIs, you expose each piece of your DevOps stack as an MCP Server… and let AI agents orchestrate the flow end-to-end. Here’s the core DevOps MCP stack I’d bet on for 2026 👇 🔹 Core Infrastructure / IaC Terraform MCP Server, Pulumi MCP Server, AWS MCP Server, Azure MCP Server, plus something like Spacelift Intent for policy-driven workflows. This becomes your “single brain” for infra changes instead of scattered scripts. 🔹 Source Control / Dev Platform GitHub MCP Server and GitLab MCP Server so your agents can open PRs, review diffs, comment on pipelines, and tie everything back to GitOps flows. 🔹 CI/CD & Pipeline Automation Jenkins MCP Server, Azure DevOps MCP Server, ArgoCD, FluxCD MCP Servers. Your pipelines stop being black boxes and become addressable, queryable, and fixable via MCP. 🔹 Kubernetes / Containers Kubernetes MCP Server plus Docker MCP Server / Docker Hub MCP Server and Lens MCP Server. Now an AI agent can inspect pods, roll back a deployment, or debug a failing service without you hunting through five dashboards. 🔹 Observability / Monitoring Prometheus MCP Server, Grafana MCP Server, Datadog MCP Server. You move from “what’s the dashboard URL?” to “explain why latency spiked in the last deploy and correlate it with this PR.” 🔹 Security, Compliance, Secrets HashiCorp Vault MCP Server, Snyk & Trivy MCP Servers, Prowler MCP Server, Wiz MCP Server. Security checks become first-class, callable tools in every workflow instead of an afterthought. The pattern across all of this: Expose each capability as an MCP Server → wire them into a consistent agent interface → let AI orchestrate the boring glue so humans can focus on architecture, reliability, and safety. If you’re building DevOps or platform engineering skills for the next 3–5 years, this is where I’d invest my energy. Save this post and steal the stack. Then customize it for your cloud, your org, your risk profile. 🔁 Your turn: What would you add or swap in this 2026 MCP-driven DevOps stack? Argo vs Flux, Jenkins vs GitHub Actions, Datadog vs OpenTelemetry — what’s your bet? #DevOps #PlatformEngineering #MCP #Kubernetes #Terraform #CloudNative #MLOps

Stop fighting your Infrastructure-as-Code deployment order! 🏗️ Ever had a Terraform apply fail because a resource was created before its prerequisite was ready? That’s where Dependencies come in. In Terraform, there are two ways to handle the "What comes first?" problem: 🔹 Implicit Dependencies: The "smart" way. Terraform sees Resource A using an ID from Resource B and automatically builds B first. No extra code needed! 🔹 Explicit Dependencies (depends_on): The "manual" way. Sometimes resources are linked logically but not through data. Use this to tell Terraform: "Don't touch Resource A until Resource B is fully finished." Pro-Tip: Lean on Implicit dependencies as much as possible—it keeps your code cleaner and easier to maintain. Save depends_on for those tricky edge cases! How do you handle complex dependencies in your modules? Let’s discuss below! 👇 #Terraform #DevOps #CloudComputing #IaC #AWS #PlatformEngineering