Explicit Dependencies and Graph Review

Scenario: A policy attachment depends on a role's eventual consistency, but no attribute reference exposes that relationship.

Terraform infers most dependencies from references. depends_on expresses a hidden behavioral dependency between whole objects or modules; use it sparingly because it broadens unknown values and reduces parallelism. terraform graph exposes graph structure, but the execution plan remains the authority for actions. Preconditions and postconditions validate assumptions; checks can monitor broader assertions without necessarily blocking every operation.

Analogy: A project schedule normally derives dependencies from deliverables. depends_on is the sticky note saying concrete must cure before framing—useful when the deliverable itself cannot express it.

A worked configuration

resource "fakecloud_policy_attachment" "api" {
  role_id = fakecloud_role.api.id
  policy  = "read-secrets"
  depends_on = [fakecloud_role_propagation.api]
}

Overusing module-level depends_on can make large portions of a plan unknown and serialize otherwise independent work. First look for a real data reference, then explain any explicit edge in a comment.

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.