how/workflow

Dependency graph: what Terraform runs in parallel and what it blocks

How Terraform learns the order to create resources in. The graph built from implicit refs, parallel "layers", and why destroy runs in exactly the reverse direction.

When you write:

hcl

resource "aws_s3_bucket" "demo" {

  bucket = "linuxlab-${random_id.suffix.hex}"

you implicitly told Terraform that aws_s3_bucket.demo depends on random_id.suffix. Not because you said so directly, but because the bucket name holds a reference to an attribute of another resource. That is an implicit reference.

Terraform reads all such references, builds a directed acyclic graph (DAG) from them, and decides on its own what to create first, what next, and what in parallel. Press ▶ and see what this looks like on five resources.

step 1/6·00 · five resources in HCL

§ steps

A teaching example: a bucket that depends on random_id (for a unique name), an IAM role, an IAM policy (attached to the role), an attachment (needs both the role and the policy).

In HCL the dependencies are not written explicitly. Terraform will see them on its own at the moment of the next command.

recap

What to remember:

Dependencies are computed from the code. Any reference A.B.C in the values of resource X automatically creates an edge A → X.
If a dependency exists but is not visible in the code (for example, an IAM role must exist before Lambda tries to assume it, and Lambda never mentions that role in HCL), you write tf-depends-on explicitly. This is a rare case, not the first option.
Within a single graph layer Terraform creates resources in parallel (up to 10 at a time by default, flag -parallelism=N). That is why large configs are faster than they seem.
On destroy the graph reverses: leaves (nothing depends on them) are deleted first, roots (others depend on them) come last.
A cycle in the graph means Error: Cycle. Terraform refuses to work until you untangle it (usually through refactoring or a null_resource with break-the-cycle logic). See tf-dag-internals.

Next: tf-module-io-flow on how the graph crosses module boundaries.

§ dig into the knowledge base

§ try it hands-on

§ steps

A teaching example: a bucket that depends on random_id (for a unique name), an IAM role, an IAM policy (attached to the role), an attachment (needs both the role and the policy).

In HCL the dependencies are not written explicitly. Terraform will see them on its own at the moment of the next command.