The Dependency Graph

Underneath every plan and apply, Terraform builds a directed acyclic graph of resources and walks it. This is not trivia. The graph is why Terraform runs independent resources in parallel, why a dependency loop is a hard error rather than a warning, and why resources get created in an order you never wrote down. When an apply does something in an order that confuses you, the graph is the answer.

You can mostly ignore it until the day you can't — a surprising apply order, a cycle error, an apply that hangs on teardown. On that day, knowing the graph exists and how to print it turns a baffling problem into a five-minute diagnosis.

What the Graph Contains

The graph has a node for every resource, data source, provider, input variable, and output. The edges are the dependencies — every reference you write becomes an edge, and so does every depends_on. A provider node is a parent of every resource that uses it, because the provider must be configured before any of its resources can be created. The graph is the complete, machine-readable picture of what depends on what, assembled from your configuration before any API is called.

Parallelism

Terraform walks the graph concurrently. Any two nodes with no path between them are independent and can be processed at the same time, which is why a config with twenty unrelated S3 buckets applies far faster than twenty sequential creates would. The default concurrency is 10 operations at once, tunable with -parallelism=N. This parallelism is the practical reason implicit dependencies matter so much — every unnecessary depends_on you add removes an opportunity for Terraform to do work in parallel.

Cycles

The graph must be acyclic — the "A" in DAG. If two resources reference each other, directly or through a chain, Terraform cannot decide which to build first and fails with a cycle error that names the resources in the loop. Cycles usually sneak in through module wiring: a module's output feeds another module whose output feeds back. The error output below names the two edges, which is exactly what you need to break the loop.

# Error: Cycle: aws_security_group.a, aws_security_group.b

# sg.a references sg.b in an ingress rule, and
# sg.b references sg.a in its own ingress rule —
# neither can be created first.

The fix is never to force an order with depends_on — that cannot resolve a true cycle. You break the loop by restructuring: pull the mutual reference into a separate resource. For the two security groups above, the answer is a standalone aws_security_group_rule (or aws_vpc_security_group_ingress_rule) that references both groups, so each group no longer references the other.

Inspecting the Graph

terraform graph emits the graph in DOT format, which you pipe into Graphviz to render a diagram. On a small config it is overkill; on a large one with a confusing apply order, seeing the actual edges is faster than reasoning about them. The command below renders the graph to an SVG you can open and trace.

# emit DOT and render with Graphviz
terraform graph | dot -Tsvg > graph.svg

Graph and Destroy

Destruction reverses every edge in the graph. A resource that depended on another during creation is destroyed before it, so the dependency is satisfied in reverse. This is why a wrong dependency does not only break creation — it can make teardown fail or hang, because Terraform tries to delete something that still has a dependent the reversed graph did not account for. Getting the edges right, mostly through references, is what makes both directions of the graph walk safely.