Infrastructure as Code: Patterns That Scale
Modules for reuse, workspaces or stacks for isolation, remote state with locking, and a PR-driven plan/apply flow. Mono-stack Terraform is technical debt waiting to happen.
Deep dive
State is everything
Remote state in Azure Storage / S3 with locking (blob lease / DynamoDB). Never commit state. Never let two pipelines apply to the same state concurrently.
Stack sizing
A stack should map to a blast radius — one stack per environment per logical concern (network, data, app). Mono-stacks make 10-minute applies into 60-minute ones and amplify the blame radius of mistakes.
Drift
Schedule regular terraform plan to detect drift. Investigate, don't auto-apply.
Bicep vs Terraform on Azure
Bicep is excellent if you're all-Azure — first-class resource support, no provider lag. Terraform wins for multi-cloud or where you already have HCL expertise.
Real-world example
From productionOne repo, one state, all environments. A junior engineer's PR to add a tag triggered a 40-minute plan that proposed destroying a prod database (state drift from a manual fix). Split into network/data/app stacks per env; plans now under 3 minutes, blast radius per PR shrunk to one concern.
Interview questions
1 senior-levelQ1How do you structure Terraform for a multi-team org?▾
Stacks scoped by blast radius (network, data, app) × environment, with remote state per stack. Shared modules in a versioned registry. Atlantis or Terraform Cloud for PR-driven plan/apply with policy gates (OPA, Sentinel).
Common mistakes
Storing state in git.
Using
countfor environment toggles — use modules.Letting devs run
terraform applyfrom laptops.
Trade-offs
Many small stacks add coordination overhead; few large stacks add risk.
Bicep removes provider lag but ties you to Azure.