Let's think about it this way for a second
When Resource A's argument references Resource B (something like `resource_b.id`), Terraform automatically understands from that reference that 'B has to be created before A' (an Implicit Dependency) — Terraform builds the dependency graph for you. Sometimes two resources need a logical order even without a direct attribute reference between them (say, an IAM permission has to exist before a resource can be created) — in that case you write an Explicit Dependency yourself with `depends_on = [resource_x]`.
Let's connect this to a real scenario
If `aws_instance` has `subnet_id = aws_subnet.app.id`, Terraform creates the subnet before the instance (implicit) — no need to specify the order manually. In a scenario like an IAM role needing to be attached before a Lambda function can run, where there's no attribute reference but a logical order is still required, you'd write `depends_on = [aws_iam_role_policy_attachment.lambda_policy]`.
Let's look at it together
resource "aws_subnet" "app" {
vpc_id = data.aws_vpc.existing.id
cidr_block = "10.0.1.0/24"
}
# Implicit dependency: references aws_subnet.app.id above
resource "aws_instance" "web" {
subnet_id = aws_subnet.app.id
instance_type = "t3.micro"
ami = "ami-0abcdef1234567890"
}
# Explicit dependency: no direct attribute reference, but order matters
resource "aws_instance" "worker" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.micro"
depends_on = [aws_instance.web]
}$ terraform graph
# shows aws_subnet.app -> aws_instance.web -> aws_instance.worker
# as a dependency chain, in the order Terraform will create them5-minute try-it
Write two resources (one referencing an attribute of the other) and run `terraform graph` — read the dependency order straight from the output.
A quick word of caution
If a dependency chain gets too long (A depends on B depends on C...) apply time can drag on, since Terraform can no longer create things in parallel — only add a reference/depends_on when there's a genuine dependency.