Forem: TechOpsBySonali

🚀 Secrets Safe, 3-Tier Deployments Fast: Terraform + Azure Key Vault Complete Hands-On Guide

TechOpsBySonali — Mon, 01 Dec 2025 10:40:33 +0000

Deploying the same 3-tier application again and again — dev, test, prod — shouldn’t feel like déjà vu every time.
But in many cloud teams, it does.
Manual fixes… copy-pasted Terraform… secrets hardcoded inside .tfvars…
One small change in dev, not updated in prod…
Boom! Configuration drift, broken deployments, security risks.

This hands-on guide shows you exactly how to eliminate all of that using:

✅ Terraform Modular Architecture
✅ Azure Key Vault for Secure Secrets Management
✅ Remote State in Azure Storage
✅ GitHub Actions for Fully Automated CI/CD

By the end, you’ll be able to deploy dev, test, and prod environments identically, securely, and on autopilot.

🔥 1. The Problem: Manual Deployments = Drift + Errors + Chaos

Most teams still deploy environments like this:

Copy old Terraform folder
Change a few names
Adjust IPs manually
Forget a network rule
Hardcode passwords “for now” 😅
Fix mistakes after something breaks

Result?

❌ Inconsistent infra across environments
❌ Security breaches due to exposed secrets
❌ Time wasted troubleshooting
❌ Zero auditability
❌ No single source of truth

This hands-on solves exactly this.

🚀 2. Why This Use Case Matters

Cloud teams today need consistency + speed + security.
Manually managing infra no longer works.

This use case delivers:

🧱 Reusable Terraform Modules

Resource Group, VNet, Subnet, NSG, VM — once written, reused forever.

🔐 Zero Secret Sprawl

Passwords and sensitive values stored in Azure Key Vault, pulled directly in Terraform.

🚦 Environment-driven Deployment

All differences (dev/test/prod) live in terraform.tfvars.

🤖 GitHub Actions = Fully Automated Deployments

Plan → Validate → Apply → Audit logs — everything automated.

This is production-grade Terraform, not just a tutorial.

🕒 3. When You Need This Use Case

You need this setup when:

✔️ Deploying multiple environments
✔️ Avoiding inconsistent infra
✔️ Securing all secrets centrally
✔️ Enabling fast onboarding
✔️ Needing auditability and governance
✔️ Running builds from CI/CD pipelines
✔️ Scaling infra to multiple regions

This architecture grows as your company grows.

🛠️ 4. Prerequisites

Azure Subscription
Azure CLI
Terraform Installed
Git + GitHub
Key Vault access
Optional: GitHub Actions Service Principal

You’re ready.

🎯 5. Challenge Questions (Interview-Level)

These make great DevOps interview questions too:

How do you avoid copy-paste Terraform for dev/test/prod?
How do you secure plaintext secrets in Terraform?
How do you stop network drift between environments?
How do you enable new developers to deploy infra securely?
How do you prove that all environments are deployed from the same code?
How do you roll back a Terraform deployment?
How do you prevent faulty tfvars from affecting prod?
How do you design a module for both Linux & Windows VMs?
How do you deploy identical infra to two regions?
Why are modules better than plain Terraform scripts?

🧑‍💻 6. Complete Hands-On Implementation

Below is the full real-life end-to-end setup.

STEP 1️⃣ — Authenticate to Azure & Configure Git

az login
git config --global user.name "yourname"
git config --global user.email "yourmail@example.com"

Initialize GitHub repository:

git init
echo "# azure-3-tier-architecture" >> README.md
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/<yourid>/azure-3-tier-architecture.git
git push -u origin main

STEP 2️⃣ — Create Backend Resources

LOCATION="eastus"
RG_NAME="tfstate-rg"
STORAGE_NAME="mytfstate12345"
CONTAINER_NAME="tfstate"
KV_NAME="mykeyvault12345"

az group create --name $RG_NAME --location $LOCATION
az storage account create --name $STORAGE_NAME --resource-group $RG_NAME --location $LOCATION --sku Standard_LRS
az storage container create --name $CONTAINER_NAME --account-name $STORAGE_NAME

STEP 3️⃣ — Create Key Vault + Secrets

az keyvault create --name $KV_NAME --resource-group $RG_NAME --location $LOCATION

Store secrets

az keyvault secret set --vault-name $KV_NAME --name "vm-username" --value "learning"
az keyvault secret set --vault-name $KV_NAME --name "vm-password" --value "Redhat@12345"

STEP 4️⃣ — Create GitHub Service Principal

az ad sp create-for-rbac --name "github-spn" --role="Contributor" --scopes="/subscriptions/<subid>" --sdk-auth

Save JSON output.

Grant Key Vault access:

az role assignment create \
  --assignee <clientId> \
  --role "Key Vault Secrets User" \
  --scope $(az keyvault show --name $KV_NAME --query id -o tsv)

STEP 5️⃣ — Create Terraform Structure

terraform/
├── backend.tf
├── main.tf
├── variables.tf
├── environments/
│   ├── dev/terraform.tfvars
│   ├── test/terraform.tfvars
│   └── prod/terraform.tfvars
└── modules/
    ├── rg/
    ├── vnet/
    ├── subnet/
    ├── nsg/
    └── vm/

STEP 6️⃣ — Add Root Terraform Files

backend.tf

terraform {
  backend "azurerm" {
    resource_group_name  = "tfstate-rg"
    storage_account_name = "mytfstate12345"
    container_name       = "tfstate"
    key                  = "3tier/dev.tfstate"
  }
}

variables.tf

variable "location" { type = string }
variable "rg_name" { type = string }
variable "vnet_name" { type = string }
variable "vm_name" { type = string }

main.tf

provider "azurerm" {
  features {}
}

module "rg" {
  source   = "./modules/rg"
  name     = var.rg_name
  location = var.location
}

module "vnet" {
  source   = "./modules/vnet"
  name     = var.vnet_name
  location = var.location
  resource_group_name = module.rg.name
}

module "subnet" {
  source = "./modules/subnet"
  name   = "${var.vnet_name}-subnet"
  vnet_name = module.vnet.name
  resource_group_name = module.rg.name
  nsg_id = module.nsg.id
}

module "nsg" {
  source = "./modules/nsg"
  name   = "${var.vnet_name}-nsg"
  location = var.location
  resource_group_name = module.rg.name
}

data "azurerm_key_vault" "kv" {
  name                = "mykeyvault12345"
  resource_group_name = "tfstate-rg"
}

data "azurerm_key_vault_secret" "vm_username" {
  name         = "vm-username"
  key_vault_id = data.azurerm_key_vault.kv.id
}

data "azurerm_key_vault_secret" "vm_password" {
  name         = "vm-password"
  key_vault_id = data.azurerm_key_vault.kv.id
}

module "vm" {
  source              = "./modules/vm"
  name                = var.vm_name
  location            = var.location
  resource_group_name = module.rg.name
  subnet_id           = module.subnet.id
  admin_username      = data.azurerm_key_vault_secret.vm_username.value
  admin_password      = data.azurerm_key_vault_secret.vm_password.value
}

STEP 7️⃣ — Environment Variables

dev

rg_name  = "rg-dev"
vnet_name = "vnet-dev"
vm_name   = "vm-dev"
location = "eastus"

STEP 8️⃣ — Build Modules

(Example: Resource Group)

modules/rg/main.tf

resource "azurerm_resource_group" "rg" {
  name     = var.name
  location = var.location
}

modules/rg/variables.tf

variable "name" { type = string }
variable "location" { type = string }

modules/rg/outputs.tf

output "name" { value = azurerm_resource_group.rg.name }

Repeat similar for vnet, subnet, nsg, vm.

🎉 Final Output

You now have:

✔️ Modular Terraform
✔️ Secure secrets with Key Vault
✔️ Remote state
✔️ Reusable environments
✔️ Ready for GitHub Actions automation

This is true enterprise-grade Infrastructure as Code.

⭐ Follow Me for Daily DevOps & Cloud Content

🔵 LinkedIn: @techopsbysonali
🐦 Twitter / X: @techopsbysonali
📸 Instagram: @techopsbysonali
📝 Medium: @techopsbysonali
📚 Dev.to: @techopsbysonali
🌐 Hashnode: techopsbysonali.hashnode.dev
🖋️ Blogger: techopsbysonali.blogspot.com

📲 Join My WhatsApp Communities
**
👉 Personalized Guidance: https://wa.me/7620774352
👉 Latest Updates Group: https://lnkd.in/gVTvmRBa
👉 Pune Local Meetup Group: https://lnkd.in/gQbKaUeX

Terraform Workspaces: Proven Multi-Environment Patterns for Real-World DevOps

TechOpsBySonali — Sun, 23 Nov 2025 14:13:06 +0000

Managing multiple environments (dev, staging, prod) is a core requirement for any modern infrastructure setup. Terraform offers several ways to do this — but Terraform Workspaces are often misunderstood, overused, or misused.

This guide cuts through the noise with clear, real-world patterns that developers can safely use in production-grade workflows.

What Terraform Workspaces Actually Do

Terraform Workspaces do NOT:

❌ create separate directories
❌ give you different pipelines
❌ create different backend configurations

They ONLY provide:

✔ Separate state files within the same backend
✔ A way to reference the current workspace via terraform.workspace
✔ Simple environment switching from the CLI

terraform workspace new dev
terraform workspace new prod

terraform workspace select dev
terraform workspace select prod

You can use the workspace name in resources:

resource "aws_s3_bucket" "example" {
  bucket = "myapp-${terraform.workspace}"
}

This creates:

myapp-dev
myapp-prod

That’s all workspaces do — state separation + naming context.

When You Should (and Should NOT) Use Workspaces

✔ Use Workspaces When…

Infra topology is identical across environments
Your team has small/medium infrastructure
You want simple state isolation
You need quick environment testing

✘ Avoid Workspaces When…

Environments have different architectures
You need different backends per environment
Every environment has its own repo
Your CI/CD pipeline cannot safely switch workspaces

When environments diverge significantly →
Use folder-based or repo-based separation instead.

Multi-Environment Patterns

Below are practical Terraform patterns used by DevOps teams of all sizes.

Pattern 1: Simple Workspace-Based Environments

A clean, minimal approach.

infra/
  main.tf
  variables.tf
  outputs.tf

Example:

variable "region" {}

provider "aws" {
  region = var.region
}

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"

  tags = {
    Environment = terraform.workspace
  }
}

Run:

terraform workspace new dev
terraform apply -var="region=us-east-1"

terraform workspace new prod
terraform apply -var="region=us-east-1"

Good for:
✔ Small projects
✔ Simple infra

Limitations:
✘ Doesn’t provide per-env backend security

Pattern 2: Workspaces + Per-Environment Variable Files

A scalable improvement over Pattern 1.

infra/
  main.tf
  variables.tf
  env/
    dev.tfvars
    prod.tfvars

Example: env/dev.tfvars

region        = "us-east-1"
instance_type = "t3.micro"

CI/CD:

terraform workspace select dev
terraform apply -var-file="env/dev.tfvars"

Benefits:
✔ Separate configs
✔ Same infra topology
✔ Controlled differences

Pattern 3: Workspaces with Dynamic Backends

Store state in separate backend keys.

terraform {
  backend "s3" {
    bucket = "my-terraform-states"
    key    = "env/${terraform.workspace}/terraform.tfstate"
    region = "us-east-1"
  }
}

Resulting state files:

env/dev/terraform.tfstate
env/prod/terraform.tfstate

Pros:
✔ Strong isolation
✔ Good for regulated industries

Cons:
✘ Backend configs cannot always use variables
✘ May require partial backend config overrides in CI/CD

Pattern 4: Hybrid Model — Workspaces + Folder-Based Environments

Perfect for mid-sized teams.

infra/
  modules/
    network/
    compute/
  env/
    dev/
      main.tf
    prod/
      main.tf

Example: env/dev/main.tf

module "app" {
  source      = "../../modules/compute"
  environment = terraform.workspace
}

Why teams love this pattern:

✔ Versioned modules
✔ Clean environment overrides
✔ Workspace state isolation

Real-World Scenario Example

A microservices platform needs:

Same infra topology across environments
Different EC2 sizes for dev vs prod

env/
  dev.tfvars
  prod.tfvars

dev.tfvars:

instance_type      = "t3.micro"
enable_monitoring  = false

prod.tfvars:

instance_type      = "m5.large"
enable_monitoring  = true

CI/CD deploy step:

terraform workspace select prod
terraform apply -var-file=env/prod.tfvars -auto-approve

Outcome:

Fully isolated state
Clean promotions
Parameterized infra

Developer Tips

💡 Never store secrets in .tfvars → use Vault, SSM, or env variables.

💡 Avoid switching workspaces inside long pipelines — risk of deploying to wrong environment.

💡 Validate workspace names:

locals {
  allowed   = ["dev", "stage", "prod"]
  is_valid  = contains(local.allowed, terraform.workspace)
}

resource "null_resource" "validate" {
  count = local.is_valid ? 0 : 1
}

💡 Use workspaces only when architecture remains consistent.

Common Questions Developers Ask

1. Are workspaces the same as Git branches?

No. Workspaces only isolate terraform state, not code.

2. Should I use workspaces for production?

✔ Yes — if infra is identical
✘ No — if prod requires unique architecture

3. Do workspaces isolate backend buckets?

Only if you configure the backend key:

key = "env/${terraform.workspace}/terraform.tfstate"

4. Should each environment have its own workspace or folder?

Use workspaces → simple infra
Use folders/repos → complex infra

5. Do workspaces prevent mistakes?

They avoid state overlap but do not protect against bad pipelines.

Related Tools & Ecosystem

Terragrunt — advanced multi-env orchestration
Atlantis — Terraform GitOps
Spacelift / Terraform Cloud — remote runs
tflint / tfsec / Terrascan — linting & security
Infracost — cost analysis
Pre-commit Terraform Hooks — automatic linting

Conclusion

Terraform Workspaces are powerful when used correctly.
They shine when your environments:

share the same architecture
need simple state isolation
require parametrized differences

Use these patterns to structure your environments safely and avoid the common pitfalls most teams fall into.

⭐ Follow Me for Daily DevOps & Cloud Content

🔵 LinkedIn: @techopsbysonali
🐦 Twitter / X: @techopsbysonali
📸 Instagram: @techopsbysonali
📝 Medium: @techopsbysonali
📚 Dev.to: @techopsbysonali
🌐 Hashnode: techopsbysonali.hashnode.dev
🖋️ Blogger: techopsbysonali.blogspot.com

📲 Join My WhatsApp Communities

👉 Personalized Guidance: https://wa.me/7620774352
👉 Latest Updates Group: https://lnkd.in/gVTvmRBa
👉 Pune Local Meetup Group: https://lnkd.in/gQbKaUeX