Resource dependencies (implicit) in Terraform - Commands & Configuration

Introduction

When you create cloud resources with Terraform, some resources need others to be ready first. Terraform figures out these connections automatically without you telling it. This helps avoid errors and makes your setup smoother.

When you create a virtual machine that needs a network to be ready first.

When you set up a database that depends on a storage bucket being created.

When you deploy an application that requires a load balancer to exist before it starts.

When you want Terraform to handle the order of resource creation without extra instructions.

When you want to avoid errors caused by resources trying to use others that are not ready yet.

Config File - main.tf

main.tf

provider "aws" {
  region = "us-east-1"
}

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

resource "aws_subnet" "example_subnet" {
  vpc_id            = aws_vpc.example_vpc.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
}

resource "aws_instance" "example_instance" {
  ami           = "ami-0c94855ba95c71c99"
  instance_type = "t2.micro"
  subnet_id     = aws_subnet.example_subnet.id
}

This file creates three AWS resources:

• aws_vpc.example_vpc: A virtual private cloud network.
• aws_subnet.example_subnet: A subnet inside the VPC, which uses the VPC's ID to link itself.
• aws_instance.example_instance: A virtual machine that uses the subnet's ID.

Terraform automatically understands the order: VPC first, then subnet, then instance, because each resource uses the ID of the previous one.

Commands

This command sets up Terraform in the current folder by downloading necessary plugins and preparing the environment.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.0.0...

- Installed hashicorp/aws v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure.

This command shows what Terraform will create or change without actually doing it. It helps you check your setup before applying.

Terminal

terraform plan

Expected Output

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # aws_vpc.example_vpc will be created

  + resource "aws_vpc" "example_vpc" {

      + cidr_block = "10.0.0.0/16"

      + id         = (known after apply)

    }



  # aws_subnet.example_subnet will be created

  + resource "aws_subnet" "example_subnet" {

      + cidr_block        = "10.0.1.0/24"

      + id                = (known after apply)

      + vpc_id            = (known after apply)

      + availability_zone = "us-east-1a"

    }



  # aws_instance.example_instance will be created

  + resource "aws_instance" "example_instance" {

      + ami           = "ami-0c94855ba95c71c99"

      + instance_type = "t2.micro"

      + subnet_id     = (known after apply)

      + id            = (known after apply)

    }



Plan: 3 to add, 0 to change, 0 to destroy.

This command creates the resources defined in the configuration. The flag skips asking for confirmation to speed up the process.

Terminal

terraform apply -auto-approve

Expected Output

aws_vpc.example_vpc: Creating...

aws_vpc.example_vpc: Creation complete after 3s [id=vpc-0abcd1234efgh5678]

aws_subnet.example_subnet: Creating...

aws_subnet.example_subnet: Creation complete after 2s [id=subnet-0abcd1234efgh5678]

aws_instance.example_instance: Creating...

aws_instance.example_instance: Still creating... [10s elapsed]

aws_instance.example_instance: Creation complete after 15s [id=i-0abcd1234efgh5678]



Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

→

-auto-approve - Skip confirmation prompt to apply changes immediately

This command shows a graph of resource dependencies Terraform detected. It helps visualize the order Terraform will create resources.

Terminal

terraform graph

Expected Output

"digraph {

  compound = "true"

  newrank = "true"

  node [label="aws_vpc.example_vpc", shape=box]

  "aws_vpc.example_vpc";

  node [label="aws_subnet.example_subnet", shape=box]

  "aws_subnet.example_subnet";

  node [label="aws_instance.example_instance", shape=box]

  "aws_instance.example_instance";

  "aws_subnet.example_subnet" -> "aws_vpc.example_vpc";

  "aws_instance.example_instance" -> "aws_subnet.example_subnet";

}

"

Key Concept

Terraform automatically figures out which resources depend on others by looking at how you reference them, so it creates them in the right order without extra instructions.

Common Mistakes

Not referencing dependent resource IDs in later resources.

Terraform cannot detect the order to create resources, which may cause errors or resources trying to use others that don't exist yet.

Always use resource attributes (like IDs) from one resource inside another to let Terraform know about the dependency.

Trying to force dependencies manually when Terraform already detects them.

This can make the configuration more complex and harder to maintain without adding value.

Trust Terraform's implicit dependency detection unless you have a special case requiring explicit dependencies.

Summary

Terraform detects resource dependencies automatically by how resources reference each other.

Use resource attributes like IDs from one resource inside another to create implicit dependencies.

Commands: 'terraform init' prepares Terraform, 'terraform plan' shows what will happen, 'terraform apply' creates resources, and 'terraform graph' visualizes dependencies.

Practice

1. What does Terraform use to determine the order of resource creation when no explicit depends_on is set?

easy

A. The alphabetical order of resource names

B. The order resources are written in the file

C. References between resources inside the configuration

D. Manual user input during apply

Solution

1. Step 1: Understand Terraform's dependency mechanism

   Terraform automatically detects dependencies by checking if one resource references another inside its configuration.

2. Step 2: Compare with other options

   The order in the file, alphabetical order, or manual input do not affect resource creation order unless explicitly coded.

3. Final Answer:

   References between resources inside the configuration -> Option C

4. Quick Check:

   Implicit dependencies = references [OK]

Hint: Look for resource references to find dependencies [OK]

Common Mistakes:

• Thinking order in file matters
• Assuming alphabetical order controls creation
• Believing manual input sets dependencies

2. Which of the following Terraform resource blocks correctly creates an implicit dependency on aws_vpc.main?

easy

A. resource "aws_subnet" "subnet1" { vpc_id = "vpc-123456", cidr_block = "10.0.1.0/24" }

B. resource "aws_subnet" "subnet1" { cidr_block = "10.0.1.0/24" }

C. resource "aws_subnet" "subnet1" { depends_on = [aws_vpc.main], cidr_block = "10.0.1.0/24" }

D. resource "aws_subnet" "subnet1" { vpc_id = aws_vpc.main.id, cidr_block = "10.0.1.0/24" }

Solution

1. Step 1: Identify implicit dependency via reference

   resource "aws_subnet" "subnet1" { vpc_id = aws_vpc.main.id, cidr_block = "10.0.1.0/24" } references aws_vpc.main.id inside vpc_id, creating an implicit dependency.

2. Step 2: Check other options

   resource "aws_subnet" "subnet1" { cidr_block = "10.0.1.0/24" } lacks any reference, so no implicit dependency. resource "aws_subnet" "subnet1" { depends_on = [aws_vpc.main], cidr_block = "10.0.1.0/24" } uses explicit depends_on, not implicit. resource "aws_subnet" "subnet1" { vpc_id = "vpc-123456", cidr_block = "10.0.1.0/24" } uses a hardcoded string, no reference.

3. Final Answer:

   resource "aws_subnet" "subnet1" { vpc_id = aws_vpc.main.id, cidr_block = "10.0.1.0/24" } -> Option D

4. Quick Check:

   Reference attribute = implicit dependency [OK]

Hint: Implicit dependency needs resource attribute reference, not hardcoded values [OK]

Common Mistakes:

• Confusing explicit depends_on with implicit
• Using hardcoded IDs instead of references
• Missing the reference attribute in resource

3. Given the following Terraform snippet, what is the correct order of resource creation?

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

resource "aws_subnet" "subnet1" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_instance" "web" {
  subnet_id = aws_subnet.subnet1.id
  ami       = "ami-123456"
  instance_type = "t2.micro"
}

medium

A. aws_vpc.main -> aws_subnet.subnet1 -> aws_instance.web

B. aws_instance.web -> aws_subnet.subnet1 -> aws_vpc.main

C. aws_subnet.subnet1 -> aws_vpc.main -> aws_instance.web

D. aws_vpc.main -> aws_instance.web -> aws_subnet.subnet1

Solution

1. Step 1: Identify dependencies from references

   aws_subnet.subnet1 depends on aws_vpc.main via vpc_id. aws_instance.web depends on aws_subnet.subnet1 via subnet_id.

2. Step 2: Determine creation order

   Terraform creates resources in order of dependencies: first aws_vpc.main, then aws_subnet.subnet1, then aws_instance.web.

3. Final Answer:

   aws_vpc.main -> aws_subnet.subnet1 -> aws_instance.web -> Option A

4. Quick Check:

   Dependency chain order = B [OK]

Hint: Follow references to find creation order [OK]

Common Mistakes:

• Ignoring dependency direction
• Assuming alphabetical or file order
• Mixing up resource references

4. You have two resources: aws_security_group.sg and aws_instance.web. The instance should be created after the security group. The code is:

resource "aws_security_group" "sg" {
  name = "web-sg"
}

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

Why might Terraform create the instance before the security group, and how to fix it?

medium

A. Because no reference exists; add vpc_security_group_ids = [aws_security_group.sg.id] to instance

B. Because depends_on is missing; add depends_on = [aws_security_group.sg] to instance

C. Because resource names are unordered; rename aws_security_group.sg to sg1

D. Because Terraform always creates instances first; no fix possible

Solution

1. Step 1: Identify missing implicit dependency

   The instance resource does not reference the security group, so Terraform sees no dependency and may create in any order.

2. Step 2: Fix by adding reference

   Adding vpc_security_group_ids = [aws_security_group.sg.id] creates an implicit dependency, ensuring the security group is created first.

3. Final Answer:

   Add vpc_security_group_ids referencing security group to instance -> Option A

4. Quick Check:

   Reference creates implicit dependency [OK]

Hint: Add resource attribute reference to create implicit dependency [OK]

Common Mistakes:

• Relying only on depends_on when reference is better
• Changing resource names expecting order change
• Assuming Terraform creates instances first always

5. You have a Terraform configuration with three resources: aws_lb.lb, aws_lb_target_group.tg, and aws_lb_listener.listener. The listener must be created after the load balancer and target group. The target group references the load balancer's ARN. The listener references the target group's ARN. However, you want to ensure the listener is created only after both are fully ready. Which is the best way to enforce this implicit dependency correctly?

hard

A. Use explicit depends_on everywhere and avoid references

B. Reference aws_lb.lb.arn in aws_lb_target_group.tg and aws_lb_target_group.tg.arn in aws_lb_listener.listener without using depends_on

C. Create the listener first, then the target group and load balancer

D. Add depends_on = [aws_lb.lb, aws_lb_target_group.tg] in aws_lb_listener.listener and no references

Solution

1. Step 1: Understand implicit dependency chaining

   Referencing aws_lb.lb.arn in the target group creates an implicit dependency on the load balancer. Referencing aws_lb_target_group.tg.arn in the listener creates an implicit dependency on the target group.

2. Step 2: Avoid unnecessary explicit depends_on

   Using references allows Terraform to build the dependency graph automatically and safely without manual depends_on, which should be reserved for special cases.

3. Final Answer:

   Use references to create implicit dependencies without depends_on -> Option B

4. Quick Check:

   Implicit references chain dependencies best [OK]

Hint: Chain resource references to build implicit dependencies [OK]

Common Mistakes:

• Overusing depends_on instead of references
• Creating resources in wrong order manually
• Avoiding references and relying only on depends_on