Implicit vs Explicit Dependencies

Analogy categoryAnalogies

Terraform builds a directed acyclic graph (DAG) of every resource, data source, module, and output in your configuration before it creates, updates, or destroys anything. The order in which operations happen is not determined by the order resources appear in your .tf files — it is determined entirely by dependencies between them. Most of these dependencies are discovered automatically because Terraform's HCL interpolation syntax makes references visible in the graph builder. When a dependency cannot be seen through a direct attribute reference — for example, a hidden ordering requirement enforced by an external system rather than by data flow — you must declare it explicitly with the depends_on argument.

🏏

Cricket analogy: Terraform building a DAG before any resource is touched is like a team management analyzing every player's role before announcing the batting order, rather than picking batters in the order names appear on the team sheet.

How implicit dependencies are detected

An implicit dependency exists whenever one resource's configuration references an attribute of another resource, a module output, or a data source. Terraform's graph builder parses every expression in every block, finds these references, and adds an edge in the DAG pointing from the dependent resource back to the resource it depends on. This is the mechanism that lets you write aws_instance.web that references aws_subnet.main.id without ever telling Terraform 'create the subnet first' — the reference itself is the instruction.

🏏

Cricket analogy: An implicit dependency is like a scorecard automatically crediting a bowler's wicket to the correct over because the delivery record references that bowler's spell, without anyone manually declaring 'this wicket belongs to this bowler.'

hcl

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "main" {
  vpc_id     = aws_vpc.main.id       # implicit dependency on aws_vpc.main
  cidr_block = "10.0.1.0/24"
}

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.main.id # implicit dependency on aws_subnet.main
}

Why explicit dependencies are sometimes required

Some ordering requirements exist purely at the level of side effects in the target platform and never surface as an attribute reference. A classic example is an IAM policy that must be fully propagated before an application starts making calls that rely on it, or a resource that must be created after another because of an undocumented API race condition on the provider side. In these cases Terraform's graph has no edge to infer, because nothing in the resource's arguments points at the other resource. The depends_on meta-argument forces Terraform to add that edge manually, at the cost of making the relationship less self-documenting than a real reference.

🏏

Cricket analogy: An IAM policy needing time to propagate before use is like a substitute fielder needing the umpire's confirmation to register before fielding a catch — Terraform's depends_on is like a captain manually holding play until that confirmation lands, since the scorecard shows no automatic link.

hcl

resource "aws_iam_role_policy" "logging" {
  name   = "lambda-logging-policy"
  role   = aws_iam_role.lambda_exec.id
  policy = data.aws_iam_policy_document.logging.json
}

resource "aws_lambda_function" "processor" {
  function_name = "order-processor"
  role          = aws_iam_role.lambda_exec.arn
  handler       = "index.handler"
  runtime       = "python3.12"
  filename      = "lambda.zip"

  # No attribute of aws_iam_role_policy.logging is referenced above,
  # yet the policy must exist before the function starts invoking.
  depends_on = [aws_iam_role_policy.logging]
}

Think of implicit dependencies as footnotes Terraform writes for you automatically every time you cite another resource's data, while depends_on is a footnote you have to write by hand because the citation isn't visible in the text.

Overusing depends_on is a common anti-pattern. It forces strict sequential ordering and prevents Terraform from parallelizing unrelated resource creation, which can significantly slow down applies on large configurations. Prefer a real attribute reference whenever one is available — only fall back to depends_on when no such reference exists.

Dependencies across modules

The same graph logic extends across module boundaries. When a root module passes a resource's attribute into a child module as an input variable, or consumes a child module's output, Terraform wires the dependency edge through the module call just as it would within a single file. depends_on can also be applied to an entire module block, in which case every resource inside that module is treated as depending on the listed resources, which is a blunt but occasionally necessary tool for whole-module ordering.

🏏

Cricket analogy: Passing a resource's attribute into a child module is like a captain passing the toss result into a batting-order sub-plan, and depends_on on a whole module is like holding the entire top order until the pitch report module is finalized.

Terraform orders operations using a dependency graph (DAG), not file or block order.
Implicit dependencies are inferred automatically from attribute references between resources, data sources, and module outputs.
Explicit dependencies use the depends_on meta-argument when no attribute reference exists to expose the relationship.
depends_on can target a list of resources, data sources, or an entire module block.
Overusing depends_on reduces parallelism and hides the real reason for the ordering requirement.
Always prefer a genuine attribute reference over depends_on whenever the data is actually needed.

Practice what you learned

1. What determines the order in which Terraform creates resources during an apply?

2. Which of the following creates an implicit dependency?

3. When should you use depends_on?

4. What is a downside of overusing depends_on?

5. Can depends_on be applied to an entire module block?

Was this page helpful?

The Dependency Graph

count and for_each

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

Docker & Kubernetes Study Notes

YAML · 40 topics

Topics covered

#HCL#TerraformInfrastructureAsCodeStudyNotes#DevOps#ImplicitVsExplicitDependencies#Implicit#Explicit#Dependencies#Detected#StudyNotes#SkillVeris

Implicit vs Explicit Dependencies