Desired State and the Dependency Graph

Scenario: Three resources are listed in the wrong textual order, yet Terraform builds them correctly—and parallelizes two unrelated resources.

References such as fakecloud_network.app.id create implicit graph edges. Terraform walks the directed acyclic graph, executes independent vertices concurrently, and reverses dependency order during destruction. Use depends_on only for a real dependency Terraform cannot infer; gratuitous edges serialize work and hide the data relationship. Unknown values shown as (known after apply) are placeholders that allow planning around provider-computed results.

Analogy: A spreadsheet recalculates cells from references, not from where formulas appear on the page. Terraform similarly follows dependencies rather than file order.

A worked configuration

resource "fakecloud_server" "api" {
  name       = "api"
  network_id = fakecloud_network.app.id
}

output "server_id" {
  value = fakecloud_server.api.id
}

Graph quality is an operational feature. Clear attribute references produce safer create and destroy ordering, useful architecture diagrams, and smaller blast radii. Hidden dependencies surface as intermittent apply failures that often disappear on retry—the worst kind of automation bug.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-dependency-ordering Terraform lab. Open /labs/terraform and choose slug tf-dependency-ordering; the lab runs real Terraform against the offline FakeCloud provider.