Terraform Fundamentals · Module 05 of 12

References, dependencies, data sources and the dependency graph

Understand how Terraform derives ordering from references, when explicit depends_on is justified, and how data sources differ from managed resources.

Learning objectives

By the end of this module, you should be able to:

  • Explain implicit dependency edges created by references.
  • Use depends_on only when a dependency cannot be expressed through data flow.
  • Distinguish data sources from managed resources.

References create dependency edges

When one resource argument references another resource attribute, Terraform can infer ordering. This data-flow dependency is preferable because it documents why the dependency exists.

depends_on is an escape hatch

depends_on is useful for hidden behavioral dependencies that are not represented by an attribute reference. Overusing it makes plans more conservative and configuration harder to understand.

Data sources read existing information

Managed resources create or update objects; data sources query information. Data-source results can feed resource arguments, but data sources do not turn unmanaged objects into managed ones.

Worked examples

See the idea in practice.

Implicit dependency

resource "terraform_data" "network" { input = "net-a" }
resource "terraform_data" "app" {
  input = "using-${terraform_data.network.output}"
}
  • The reference creates an implicit edge from app to network.
Hands-on lab

Lab — Observe Terraform dependency ordering

Goal: Create an implicit dependency and inspect it through plan and graph output.

Before you start

  • Terraform CLI; Graphviz is optional if you want to render the DOT graph.
STEP 1

Create dependent resources

mkdir -p ~/gnu-terraform-labs/module05 && cd ~/gnu-terraform-labs/module05
cat > main.tf <<'EOF'
resource "terraform_data" "foundation" {
  input = "network-ready"
}

resource "terraform_data" "application" {
  input = "app-${terraform_data.foundation.output}"
}

output "application" {
  value = terraform_data.application.output
}
EOF
STEP 2

Initialize and plan

terraform init
terraform plan
STEP 3

Apply

terraform apply -auto-approve
STEP 4

Inspect graph source

terraform graph | head -30

Verify

  • The configuration applies without explicit depends_on.
  • The application output contains the foundation output.

Expected outcome

  • You can explain that references drive ordering through Terraform's dependency graph.

If it fails

  • terraform graph outputs DOT text; Graphviz is only needed for rendering.
  • Do not add depends_on simply to make plans look sequential.
Real-world connection

Good Terraform design expresses dependencies through data interfaces, which enables safe parallelism for independent graph branches.

Avoid these traps

Common mistakes

  • Adding depends_on everywhere.
  • Assuming file order controls resource creation order.
  • Confusing a data source read with importing a resource into state.
Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1How does Terraform normally infer dependencies?

Through expression references between objects.

2When should depends_on be used?

For a real dependency that cannot be represented through attribute data flow.

3Does a data source make Terraform manage the queried object?

No; it reads data but does not establish managed ownership.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.