TerraformWhat you will learn: What Terraform is → HCL (variables, locals, outputs) → State management (remote state, locking, import) → Reusable modules with versioning → Multi-environment (tfvars, folder pattern, workspaces) → Multi-cloud (AWS + Azure + GCP) → Drift detection and remediation → Access control and secrets → Compliance scanning (Checkov, tfsec, Infracost) → CI/CD pipeline (GitHub Actions + Jenkins) → 10 senior interview Q&As with production war stories
What is Terraform
HCL Basics
State
Modules
Multi-Env
Multi-Cloud
Drift
Access Control
Compliance
CI/CD
Troubleshoot
Interview Q&A
🔷 What is Terraform?
›Terraform is an Infrastructure as Code (IaC) tool by HashiCorp. You write code in HCL (HashiCorp Configuration Language) to define cloud infrastructure, and Terraform creates and manages it automatically. It is declarative — you describe what you want, Terraform figures out how to get there.
IaC vs Manual Provisioning
| Aspect | Manual (Portal/CLI) | Terraform IaC |
|---|---|---|
| Consistency | Different every time | Identical every time |
| Speed | Hours/days | Minutes |
| Auditability | None | Git history = full audit trail |
| Repeatability | Impossible to guarantee | Guaranteed — same code = same infra |
| Rollback | Manual, risky | terraform apply of previous Git version |
| Review process | No review | PR review of infrastructure changes |
| Drift detection | None | terraform plan shows every drift |
Terraform vs Alternatives
| Tool | Type | When to use |
|---|---|---|
| Terraform | Multi-cloud IaC | Any cloud, multi-cloud, best ecosystem |
| Pulumi | Multi-cloud IaC (real code) | When team prefers Python/TypeScript over HCL |
| AWS CloudFormation | AWS-only IaC | AWS-locked, free, no state management needed |
| Azure Bicep / ARM | Azure-only IaC | Azure-locked teams, native Azure integration |
| Ansible | Config management | Server configuration, not infra provisioning |
Terraform core workflow
📝 HCL Fundamentals — Variables, Locals, Outputs
›File Structure — always use this layout
| File | Purpose |
|---|---|
main.tf | Resources — the actual infrastructure |
variables.tf | Variable declarations with types and descriptions |
outputs.tf | Values exported for other modules or humans |
locals.tf | Computed values, avoid repetition |
backend.tf | Remote state configuration |
providers.tf | Provider versions and authentication |
terraform.tfvars | Variable values — DO NOT commit to Git if it has secrets |
versions.tf | Terraform version constraints |
variables.tf — types, validation, sensitive
locals.tf — computed values and naming conventions
outputs.tf — export values for other modules
🗄️ State Management — Remote State, Locking, Import
›Terraform state (.tfstate) is Terraform's memory — it records every resource it has created including all cloud-assigned properties (resource IDs, IP addresses, connection strings). On every plan and apply, Terraform compares your .tf files against state to calculate what needs to change.
Why remote state is mandatory for teams
- Local state — stored on your laptop. If you leave the team, state is gone. Two engineers cannot work simultaneously.
- Remote state — stored in cloud (Azure Storage, S3+DynamoDB). Anyone on the team can run Terraform. State is locked during apply — prevents simultaneous changes corrupting state.
Remote backend — Azure Storage and AWS S3
State Commands — know all of these
terraform state commands
terraform import — bring manual resources under Terraform
When someone creates a resource manually (portal, CLI) without Terraform. You need to bring it under Terraform management without destroying and recreating it.
Import existing resources
📦 Reusable Modules — Design, Versioning, Registry
›A module is a reusable package of Terraform files — like a function in programming. Modules enable DRY (Don't Repeat Yourself) infrastructure. Write once, use in dev/staging/prod with different variable values.
Module folder structure
Module structure — internal and calling
Module versioning — critical for teams
Module versioning — pin versions
Complete reusable AKS module example
modules/aks-cluster/main.tf
🌍 Multi-Environment — tfvars, Workspaces, Folder Pattern
›The most common Terraform architecture question at senior interviews: "How do you manage dev, staging, and prod with the same Terraform code?"
Two approaches — know both, prefer folder pattern
| Folder per environment | Workspace per environment | |
|---|---|---|
| Isolation | Complete — separate state, separate runs | Same code, separate state |
| Risk | Low — impossible to accidentally affect prod | Higher — one wrong workspace select = prod |
| Clarity | Easy to see difference between envs | Harder to track which workspace |
| Recommended for | Production teams, regulated environments | Simple projects, single cloud account |
Folder pattern — recommended for production
tfvars — environment-specific values
Workspaces — alternative approach
☁️ Multi-Cloud Terraform — AWS + Azure + GCP
›Terraform is the only IaC tool that manages all three major clouds with the same workflow. This is its biggest advantage over CloudFormation (AWS-only) or Bicep (Azure-only).
Multi-cloud provider configuration
Provider aliases — multiple accounts same cloud
📡 Drift Detection & Remediation
›Drift occurs when someone modifies infrastructure directly (Azure portal, AWS console, CLI) without going through Terraform. The real state now differs from what Terraform's state file records. This is one of the most important topics at architect-level interviews.
How drift happens
- Developer manually adds a firewall rule in the console "just this once"
- Ops team resizes a VM manually during an incident, forgets to update Terraform
- Cloud provider automatically changes a setting (certificate rotation, auto-scaling)
- Legacy resources created before Terraform adoption
Detect drift — terraform plan -refresh-only
Drift remediation decision tree
| Scenario | Action | Command |
|---|---|---|
| Manual change was wrong — revert it | Apply Terraform to restore desired state | terraform apply |
| Manual change was intentional — keep it | Update .tf files to match, then apply | terraform import + plan + apply |
| Resource not in Terraform yet | Import it into state, write config | terraform import |
| Stop future drift | Enforce policy — deny console changes | Azure Policy / AWS SCP |
Prevent drift — automated detection pipeline
🔐 Access Control, Permissions & Secrets
›Access control for Terraform infrastructure is a two-layer problem: who can run Terraform (human operators) and what Terraform can do (service principal permissions). Getting this wrong means either too-permissive access (security risk) or operators constantly blocked.
Principle: Terraform runs with least privilege
| Identity | What it is | Permissions |
|---|---|---|
| CI/CD Service Principal | Automated pipeline identity | Contributor on specific resource groups only |
| Developer | Human operator | Read on prod state, full on dev/staging |
| SRE/Platform team | Infrastructure owners | Full on all environments via PR approval |
| terraform plan (PR) | Automated — runs on every PR | Read-only on all resources |
| terraform apply (prod) | Runs after manual approval | Write on approved resources only |
Azure service principal for Terraform CI/CD
Secrets management — never in tfvars
✅ Compliance & Security Scanning
›At enterprise scale (Razorpay, JP Morgan, Walmart) every Terraform PR must pass compliance checks before merge. Checkov and tfsec catch misconfigurations before they reach cloud — a CRITICAL finding in prod costs 1000x more to fix than in a PR.
Compliance tools
| Tool | What it checks | When to run |
|---|---|---|
| Checkov | Security misconfigs: public S3, unencrypted disks, open SGs, missing encryption | Every PR — blocks merge on CRITICAL |
| tfsec | Security and best practice violations | Every PR |
| terraform validate | Syntax and schema validation | Every PR — fast, runs first |
| terraform fmt | Code formatting | Every PR — fail on diff |
| Infracost | Cost estimation — shows cost change in PR comment | Every PR — informational |
| Terratest | Integration tests — provision real infra, assert, destroy | Nightly or on module changes |
| OPA/Sentinel | Policy as code — custom compliance rules | In Terraform Cloud/Enterprise |
Compliance scanning commands
⚡ Terraform in CI/CD — Jenkins + GitHub Actions
›Terraform should NEVER be run manually from a laptop in production. All production changes go through CI/CD with: automated plan on PR → human review of plan → approval gate → automated apply. This gives you audit trail, peer review, and prevents "oops I ran apply against prod by mistake".
GitHub Actions — complete Terraform pipeline
Jenkins pipeline — Terraform stages
🔍 Troubleshooting — Real Production Problems
›Most common Terraform failures and fixes
| Error | Cause | Fix |
|---|---|---|
| Error acquiring the state lock | Previous apply crashed, lock not released | terraform force-unlock <lock-id> |
| Resource already exists | Resource created manually, not in state | terraform import resource.id |
| State is corrupted/inconsistent | Concurrent apply, crash during apply | Restore state from backup, use state commands to fix |
| Plan shows destroy unexpected resource | Resource renamed in code, for_each key changed | terraform state mv old new before apply |
| Provider authentication failed | Expired credentials, wrong env vars | Refresh service principal token, check ARM_ env vars |
| Cycle detected | Circular dependency between resources | Use depends_on or restructure module |
Production troubleshooting commands
🎯 Interview Questions — Senior Level
›TERRAFORM · ARCHITECT
How do you structure Terraform for a team of 10 engineers managing 5 environments?
Monorepo with three sections: modules/ (reusable building blocks versioned with Git tags), environments/ (one subfolder per environment with its own backend.tf and terraform.tfvars), and shared/ (data sources common across environments). Governance rules: no direct resource creation outside modules — everything through a module for consistency. Module changes require PR review from 2 engineers. Environments are promoted in order: dev → staging → uat → prod. Pipeline runs terraform plan on every PR so engineers see the infrastructure diff before merging — same as they see code diffs. State files in Azure Storage with separate containers per environment, locking enabled. Result at HPE: reduced infrastructure drift by 80% compared to ad-hoc portal changes.
TERRAFORM · ENGINEER
What is Terraform state and why is losing it catastrophic?
Terraform state is Terraform's memory — it maps between your HCL configuration and real cloud resources including all cloud-assigned properties (resource IDs, IP addresses, connection strings). On every plan and apply, Terraform reads state to understand what exists and calculates only the diff. Losing state means Terraform no longer knows what it manages. Running terraform apply after losing state tries to create everything again — either fails because resources exist, creates duplicates, or worse, if running terraform plan -destroy it calculates that everything needs to be destroyed because nothing is in state. Prevention: always remote state (Azure Storage or S3), never local. Enable blob versioning on Azure Storage for point-in-time recovery. Enable DynamoDB state locking for S3 to prevent concurrent applies corrupting state. Back up state files regularly. At HPE: weekly automated backup of all state files to a separate storage account in a different region.
TERRAFORM · PRODUCTION
Production Terraform apply destroyed a resource that should not have been destroyed. What happened and how do you recover?
This happens from a few causes: resource renamed in code (Terraform sees destroy old + create new), for_each key changed, depends_on cycle, or someone ran terraform apply without reviewing the plan carefully. Immediate recovery: check if the resource was deleted or replaced. If deleted and the resource has backups (RDS snapshot, Azure disk snapshot): restore from backup, then terraform import the restored resource into state. If the resource was infrastructure (VNet, subnet): recreate via terraform apply — K8s pods will reschedule, services will recover. Post-incident actions: add -target flag to apply to prevent accidental broad destroys, enforce plan review step before apply, add require_approval = true for prod in Atlantis. Prevention: terraform plan -out=tfplan always, apply only the saved plan, never allow apply without reviewing plan output. In CI/CD: never auto-apply to production — always require manual approval after reviewing plan. We had this at HPE: a VNet was recreated after a module refactor. Recovery took 4 hours. After this we added state mv steps to our refactoring runbook.
TERRAFORM · ARCHITECT
What is Terraform drift and how do you detect and prevent it at enterprise scale?
Drift occurs when real infrastructure diverges from Terraform state — usually from manual console changes, auto-scaling, or provider-initiated changes. Detection: scheduled nightly Jenkins job runs terraform plan -refresh-only -detailed-exitcode. Exit code 2 = changes detected = drift. Alert sent to Slack. Review in the morning and decide: was this change intentional (update .tf files + import) or unauthorized (revert with terraform apply). Prevention: Azure Policy / AWS SCP denying resource modifications except from the Terraform service principal. Every infrastructure change must be a PR with plan output — no exceptions for production. Atlantis automates this: plan on PR, apply after merge. For compliance-heavy environments (banking, telco): every resource has a mandatory terraform managed tag, and Azure Policy alerts on any resource without this tag — indicates it was created outside Terraform.
TERRAFORM · ENGINEER
Explain count vs for_each in Terraform. When should you use each?
count creates a list of resources numbered by index: count = 3 creates resource[0], resource[1], resource[2]. Problem: if you remove resource[0], indices shift — resource[1] becomes resource[0], resource[2] becomes resource[1]. Terraform sees this as destroy resource[0], modify resource[1], modify resource[2]. You wanted to delete one but Terraform destroys and recreates two. for_each creates a map keyed by string: for_each = { "east" = ..., "west" = ... } creates resource["east"] and resource["west"]. Deleting "east" from the map only deletes resource["east"] — "west" is untouched. Rule: always use for_each for real production resources. Use count only for on/off patterns (count = var.enable_feature ? 1 : 0). Real consequence: we had 5 subnets created with count at HPE. Removing subnet index 2 caused Terraform to plan destroying and recreating subnets 3 and 4 — which had running K8s nodes. Caught in plan review, avoided production incident.
TERRAFORM · ARCHITECT
How do you manage secrets in Terraform? What are the risks?
Three layers of risk: 1) Secrets in .tf files committed to Git — visible to everyone with repo access, permanent in Git history even after deletion. 2) Secrets in terraform.tfvars committed to Git — same problem. 3) Secrets in state file — Terraform stores all resource attributes in state including sensitive fields like connection strings, passwords, private keys. State file is often stored in S3/Azure Storage with broad team access. Solutions in order of security: Mark variables sensitive = true — Terraform redacts them from plan output and logs. Use environment variables (TF_VAR_secret_name) in CI/CD pipelines — never hardcode. Read secrets from Key Vault data sources at apply time (data "azurerm_key_vault_secret"). Use random_password resource to generate passwords and store in Key Vault — Terraform never transmits the actual value after creation. For state file: encrypt at rest (Azure Storage server-side encryption, S3 with KMS), restrict access to state container to only the Terraform service principal and SRE team.
TERRAFORM · PRODUCTION
Someone created 50 Azure resources manually over 6 months. How do you bring them under Terraform without downtime?
This is a common enterprise adoption problem — "shadow IT" that needs governance. My approach: Phase 1 — Inventory. Use az resource list to enumerate all manually created resources. Categorize by team and criticality. Phase 2 — Write configuration. For each resource, write the Terraform HCL to match current settings. Use Azure Exporter or aztfexport tool to auto-generate .tf files from existing resources — saves 80% of writing time. Phase 3 — Import in non-production first. Pick the lowest-risk environment, run terraform import for each resource, then terraform plan to verify zero changes before proceeding. Phase 4 — Production import. Import 5-10 resources at a time in off-peak hours. After each batch: terraform plan shows no changes = safe to proceed. Phase 5 — Enforce going forward. After all resources imported: Azure Policy denying resource creation outside Terraform service principal. Total timeline at HPE for 200 resources: 3 weeks with 2 engineers. Main risk: import succeeds but plan shows unexpected changes — always review plan before applying after import.
TERRAFORM · ENGINEER
What is the difference between Terraform Cloud, Terraform Enterprise, and self-hosted Atlantis?
Terraform Cloud (SaaS): HashiCorp-hosted, free tier available. Manages state, runs plans and applies in hosted runners, VCS integration, basic RBAC. Limitation: runners cannot reach private networks without agent setup. Good for: small-medium teams, public cloud without network restrictions. Terraform Enterprise (self-hosted): Runs in your own infrastructure. Full RBAC, SSO, audit logging, Sentinel policy as code, private network access. Good for: enterprises with compliance requirements, air-gapped environments. Cost: expensive ($20+ per user per month). Atlantis (open source, self-hosted): Simple Terraform pull request automation. Runs plan on PR as bot comment, applies on merge. No state management — you bring your own backend. Good for: teams that want PR-driven Terraform without paying for Cloud/Enterprise. We use Atlantis at HPE — lightweight, free, runs inside our AKS cluster with access to private networks, full audit trail in GitHub.
TERRAFORM · PRODUCTION
Terraform plan works but apply fails halfway through. 20 resources created, 5 failed. What do you do?
Partial apply is one of the most stressful Terraform situations. What happened: Terraform applies resources in dependency order. It created 20, hit an error on resource 21. State file records the 20 successfully created resources. The 5 failed ones are NOT in state. First action: do NOT re-run terraform apply immediately. The 20 created resources might have created side effects (RBAC assignments, DNS records, security groups) that apply again would duplicate. Investigation: check the error message carefully. Common causes: permission denied (service principal missing a role), resource name conflict (already exists manually), quota exceeded, API rate limit. Fix the root cause first. Then: terraform plan again to see the full picture. If the plan shows only creating the failed resources and no unexpected changes to the 20 already created: apply is safe. If the plan shows unexpected changes to existing resources: investigate state inconsistency with terraform state show. At HPE: we hit an Azure quota limit for public IPs. Fixed the quota, re-ran apply, it created only the remaining resources. The 20 already created were untouched.
TERRAFORM · ARCHITECT
How do you handle Terraform provider version upgrades across 50 microservices?
Provider upgrades are high-risk in large organizations because provider changes can introduce breaking changes or plan diffs on unchanged resources. Strategy: pin all providers with version constraints in versions.tf — never allow automatic upgrades (no version = latest is dangerous). Use ~> 3.90 style: >= 3.90, < 4.0. Upgrade process: 1) Create a dedicated branch for the upgrade. 2) Update version constraint in one non-prod environment. 3) Run terraform init -upgrade to fetch new provider. 4) Run terraform plan — review ALL changes carefully. Even minor provider upgrades can cause plan diffs if provider fixes a bug in how it reads resource state. 5) Apply in dev, test for 1 week. 6) Roll out to staging and prod. For 50 microservices: use a module that sets the required_providers block — all callers inherit the constraint. When you update the module version, all services that upgrade to the new module version get the new provider constraint. This staggers the upgrade naturally through the promotion process.
TERRAFORM · ENGINEER
How do you structure Terraform for multiple environments and what are the best practices?
The recommended structure uses reusable modules with separate environment directories. Folder structure: modules/ folder contains reusable, environment-agnostic infrastructure definitions (modules/aks/, modules/network/, modules/database/). Each module takes variables as inputs and produces outputs. environments/ folder has a subdirectory per environment: environments/dev/, environments/staging/, environments/production/. Each environment's main.tf calls the modules with environment-specific values. Separate state per environment: each environment has its own backend.tf pointing to a different Azure Storage container or AWS S3 prefix. Never share state between environments — a corrupted state in dev should never affect production. tfvars files: dev.tfvars, staging.tfvars, production.tfvars contain the variable values per environment (VM sizes, replica counts, retention periods). CI/CD integration: dev pipeline runs on feature branches, applies automatically. Staging applies on merge to main. Production requires manual approval gate before apply. Always run terraform plan in the pipeline and store the plan output — apply only executes the reviewed plan, not a fresh plan. Remote state locking (via Azure Storage lease or DynamoDB) prevents two pipeline runs from applying simultaneously. Never allow terraform apply from a local machine against production.
TERRAFORM · ENGINEER
What are the advantages of Bicep over ARM templates for Azure infrastructure?
Both Bicep and ARM Templates define Azure infrastructure declaratively, but Bicep is the modern replacement for ARM JSON. Syntax: ARM is verbose JSON with heavy nesting. Bicep is a domain-specific language that compiles to ARM — much cleaner syntax with 40-60% less code for the same resource. Readability: a 200-line ARM template is typically 80 lines in Bicep. String interpolation, conditional expressions, and loops are much more readable. Modules: Bicep has first-class module support — split infrastructure across multiple files, call modules like functions. ARM has linked templates but they require URL references and are harder to manage. Type safety: Bicep has strong typing and intellisense in VS Code. ARM JSON has limited validation. Tooling: Bicep CLI and VS Code extension provide instant feedback. No need to understand ARM's complex schema. Compilation: Bicep always compiles to ARM — you can decompile existing ARM templates to Bicep with bicep decompile. This lets you start with existing ARM templates and migrate gradually. When to choose Terraform over Bicep: Terraform manages multi-cloud infrastructure (Azure + AWS + GCP) in one codebase. Bicep is Azure-only. If your infrastructure is purely Azure, Bicep is excellent. If you have any multi-cloud, Terraform wins.
🗺️ Learning Roadmap
›Week 1
Foundations
Install Terraform
Write first resource (Azure RG or AWS S3)
Understand plan vs apply vs destroy
Learn variables and outputs
Week 2
State & Modules
Configure remote state (Azure Storage or S3)
Create your first module
Multi-environment with tfvars
terraform state commands
Week 3-4
Production Patterns
Drift detection with plan -refresh-only
terraform import for existing resources
Checkov and tfsec compliance scanning
Terraform in CI/CD pipeline
Month 2
Architect Level
Module library with versioning
Multi-cloud provider configuration
Terragrunt for DRY backends
OPA/Sentinel policy as code
Terraform Cloud or self-hosted Atlantis
TERRAFORM · ENGINEER
What is Terraform State and why is Remote State important?
Terraform State (terraform.tfstate) is a JSON file that tracks every resource Terraform manages — resource IDs, current configuration, dependencies. When you run terraform apply, Terraform compares your .tf files (desired state) with the state file (known state) to determine what needs to change. Without the state file, Terraform cannot know what it has already created. Remote State stores this file in a shared backend (Azure Blob Storage, S3, Terraform Cloud) instead of locally. Why it matters: Team collaboration — multiple engineers share the same state, no conflicts. State locking — Azure Storage uses blob leases to lock state during apply, preventing two pipeline runs from applying simultaneously and corrupting state. Backup and history — state is versioned in blob storage, you can recover from corruption. Separate state per environment — dev, staging, and production each have their own state file in their own storage container. Never share state between environments. Azure backend configuration: terraform { backend "azurerm" { resource_group_name = "rg-terraform-state"; storage_account_name = "stterraformstate"; container_name = "tfstate"; key = "production/terraform.tfstate" } }
TERRAFORM · ENGINEER
What is Terraform Drift and how do you detect and handle it?
Drift occurs when infrastructure is modified outside Terraform — someone changes a resource in the Azure portal, a colleague runs an az CLI command, or an automated process modifies a resource. The Terraform state file no longer matches the actual infrastructure. Terraform detects drift during terraform plan — it shows the difference between what state says should exist and what actually exists in Azure. If a VM's SKU was changed in the portal, plan shows: ~ azurerm_virtual_machine.main: vm_size: "Standard_D2s_v3" → "Standard_D4s_v3". How to handle: the correct approach is to update the .tf file to match the desired state and apply. Never manually revert changes in the portal. For enforcing no drift: run terraform plan in a scheduled pipeline daily — if drift is detected, create a ticket. terraform apply --refresh-only updates the state file to match actual infrastructure without making changes — useful for importing manual changes into state. Prevention: deny portal access to infrastructure resources using Azure Policy — all changes must go through Terraform PRs.
TERRAFORM · ARCHITECT
How do you structure Terraform for multiple environments at scale?
The structure I use: separate environment directories with shared reusable modules. Root structure: modules/ directory contains environment-agnostic resource definitions (modules/aks/, modules/network/, modules/keyvault/). Each module takes input variables and produces outputs. environments/ directory: environments/dev/main.tf, environments/staging/main.tf, environments/production/main.tf. Each environment calls the modules with environment-specific variables. Separate state per environment in Azure Blob Storage — different container per environment, ideally different storage account for production isolation. CI/CD: separate pipeline per environment. Dev pipeline applies on every merge to main. Staging applies after dev validation. Production requires manual approval gate. Pipeline always runs plan first, stores the plan file, apply only executes that reviewed plan — never a fresh plan in production. The plan output is attached to the Change Request for review. Variable management: terraform.tfvars files per environment for non-secret values. Sensitive values (client secrets, passwords) come from Azure Key Vault or pipeline variable groups — never in .tfvars files or Git.
TERRAFORM · ENGINEER
What is Terraform Output and when do you use it?
Terraform Output exposes resource attribute values after deployment, making them available to other Terraform configurations or pipelines. Example: output "aks_cluster_endpoint" { value = azurerm_kubernetes_cluster.main.kube_config[0].host sensitive = true }. Common uses: expose AKS cluster endpoint for CI/CD pipelines, expose Key Vault URI for application configuration, expose load balancer IP for DNS configuration, pass values between Terraform modules using module.modulename.output_name. In a pipeline: terraform output -raw aks_cluster_endpoint gives the value for use in subsequent steps. For module composition: the networking module outputs the subnet ID, the AKS module takes the subnet ID as an input. This is how modules compose without hardcoding resource IDs. Mark sensitive outputs with sensitive = true — Terraform will hide them in plan output and require explicit retrieval.
TERRAFORM · PRODUCTION
Walk through your process before a production Terraform apply.
Structured process to ensure no surprises. 1. Branch: all infrastructure changes in a feature branch, PR reviewed by at least one other engineer. 2. terraform fmt and terraform validate run in pre-commit hooks and CI pipeline — catch syntax errors before review. 3. terraform plan output attached to the PR — reviewer reads the plan, not just the .tf files. The plan shows exactly: resources to add (green +), modify (yellow ~), destroy (red -). Red is the danger signal — destroyed resources in production need careful review. 4. Change Request raised with the plan output attached. CAB or change manager approves. 5. Deployment window scheduled — low-traffic period. 6. terraform plan run again immediately before apply in the same pipeline — catches any drift that occurred since the PR was approved. If plan output differs, stop and investigate. 7. terraform apply -auto-approve executes only the previously reviewed plan. 8. Validate: run smoke tests, check application health, verify resources in Azure portal match expected state. 9. Monitor with Azure Monitor alerts for 30 minutes after apply. 10. terraform show to confirm final state matches expected configuration.
Continue Learning