Implicit vs Explicit Dependencies
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.'
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.
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?
You May Also Like
The Dependency Graph
Terraform builds a directed acyclic graph of every resource before executing, determining safe, maximally parallel ordering for creates, updates, and deletes.
count and for_each
Compare Terraform's two meta-arguments for creating multiple copies of a resource or module, and understand why for_each is usually the safer choice.
Resources and Resource Blocks
The resource block is Terraform's fundamental unit of infrastructure declaration, describing a single managed object like a virtual machine, network, or storage bucket.
Provisioners and When to Avoid Them
Understand Terraform's provisioner blocks for running scripts on resource creation, why HashiCorp considers them a last resort, and what to use instead.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics