LinkedIn Draft — Workflow (2026-03-28)
Something every senior engineer learns the expensive way:
Terraform DAGs at scale: when the graph becomes the hazard
Terraform's dependency graph is elegant at small scale. At 500+ resources across a mono-repo, it becomes the most dangerous part of your infrastructure.
SAFE (small module): DANGEROUS (at scale):
[vpc] ──▶ [subnet] ──▶ [ec2] [shared-net] ──▶ [team-a-infra]
│ [team-b-infra]
│ [team-c-infra]
│ [data-layer]
One change → fan-out destroy/create
Where it breaks:
▸ Implicit ordering assumptions survive until a refactor exposes them — usually as an unplanned destroy chain in prod.
▸ Fan-out graphs make blast radius review near-impossible. 'What does this change affect?' has no fast answer.
▸ depends_on papering over bad module interfaces — it fixes the symptom and couples the modules permanently.
The rule I keep coming back to:
→ If a module needs depends_on to be safe, the module boundary is wrong. Redesign the interface — don't paper over it.
How I sanity-check it:
▸ terraform graph | dot -Tsvg > graph.svg — visualize fan-out and cycles before every major refactor.
▸ Gate all applies with OPA/Conftest + mandatory human review on any planned destroy operations.
The difference between a senior engineer and a principal is knowing which guardrails to build before you need them.
Curious what guardrails you've built around this. Drop your pattern below.
Top comments (0)