Lets Look at Resource Referencing with Demo

In this lesson we cover Terraform resource referencing — a core concept for building dynamic, connected infrastructure. Resource referencing lets one block consume attributes from another (for example, a subnet ID or DNS zone), which reduces hard-coded values and makes configurations easier to maintain and evolve. Why this matters:

Create dynamic configurations that adapt when underlying resources change.
Let Terraform infer ordering via its dependency graph instead of manually sequencing operations.
Reference resources unambiguously using their addresses (for example, aws_vpc.my_vpc).

A short HCL example illustrating block structure:

# single-line comment
block_type "block_label" "block_name" {
  first_argument  = expression_or_value
  second_argument = expression_or_value
  third_argument  = expression_or_value
}

attribute_abc = "value_1"
attribute_2   = "value_2"

Below is a conceptual diagram showing networks at the top and consumers (firewall, VM, Kubernetes cluster, DNS record) that depend on network/data lookups.

A purple infographic titled "Resource Referencing" that explains Terraform concepts and benefits, with bullet points like dynamic configurations, automatic dependency mapping, and resource identifiers. The right side shows a flow diagram of resource dependencies (Network Configuration, Firewall, Virtual Machine, Kubernetes Cluster, DNS Record, and Data Lookup).

How references and data sources interact

Use data blocks to read existing resources (for example, an existing DNS zone or VPC).
Use attributes from data or resource blocks as inputs to other resources.
Terraform ensures data lookups occur before resources that depend on them, so the correct values are available during planning and apply.

For example, you might use a data source to find a DNS zone, then pass an attribute like zone_id into a record:

Data source fetches current state (account, region, external network).
Resources use those attributes to create or manage dependent objects.
Changes ripple through the dependency graph so Terraform knows what to plan and apply.

In larger projects you’ll commonly use multiple block types: resource, data, variable, output, provider, etc. The diagram below summarizes these relationships and how they form Terraform’s internal dependency graph.

A slide titled "Resource Referencing" showing a flowchart of purple boxes labeled "Resource", "Data", "Output", and "Variable" with arrows between them to illustrate dependency relationships (Terraform).

Quick HCL demo and style guidance

File extensions: .tf.
Format consistently with terraform fmt to follow the canonical HCL style.
Resource addresses follow <type>.<name> (for example, github_repository.production-repo).
Use an editor with HCL support (for example, VS Code with the HashiCorp Terraform extension) to get block scaffolding and syntax highlighting.

Example: creating a GitHub provider and repository (well-formatted):

provider "github" {
  token = var.github_token
}

resource "github_repository" "production-repo" {
  name        = "prod-repo"
  description = "Repo for our production app"
  private     = true
}

Editor tips

Scaffolding often suggests provider and resource blocks.
Run terraform fmt after editing to align equals signs and standardize layout across all .tf files in the working directory.

Unique local names and addressing Terraform identifies each resource by its address: <type>.<local_name>. Within the same resource type, local names must be unique. Invalid (duplicate local names):

# Invalid: duplicate local names for the same resource type
resource "github_repository" "production-repo" {
  name        = "prod-repo"
  description = "Repo for our production app"
  private     = true
}

resource "github_repository" "production-repo" {
  name        = "prod-repo"
  description = "Repo for our production app"
  private     = true
}

Valid — distinct local names for multiple repositories:

resource "github_repository" "production-repo" {
  name        = "prod-repo"
  description = "Repo for our production app"
  private     = true
}

resource "github_repository" "testing-repo" {
  name        = "test-repo"
  description = "Repo for our testing app"
  private     = true
}

Note: you may reuse the same local name across different resource types because the full address includes the type (for example, github_user.production-repo vs github_repository.production-repo).

Do not use the same local name for multiple resources of the same type. Terraform will raise a duplicate address error during planning. Use descriptive, unique local names to avoid ambiguity in large configurations.

Splitting resources into multiple files Terraform treats all .tf files in a single working directory as one combined configuration. Splitting resources into logical files improves readability and maintainability. Example layout: github.tf

provider "github" {
  token = var.github_token
}

resource "github_repository" "production-repo" {
  name        = "prod-repo"
  description = "Repo for our production app"
  private     = true
}

test.tf

resource "github_repository" "testing-repo" {
  name        = "test-repo"
  description = "Repo for our testing app"
  private     = true
}

Formatting multiple files

Running terraform fmt in the working directory formats all .tf files there.
If files are already formatted, terraform fmt only reports the files it changed.

Example terminal interactions:

# Format files in the current directory
bk~$ terraform fmt
github.tf
test.tf
bk~$

If only github.tf needed formatting:

bk~$ terraform fmt
github.tf
bk~$

Useful references

Terraform data sources: https://developer.hashicorp.com/terraform/language/data-sources
terraform fmt command: https://developer.hashicorp.com/terraform/cli/commands/fmt
GitHub provider: https://registry.terraform.io/providers/integrations/github/latest
HCL extension for VS Code: https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform

Quick reference table

Concept	Purpose	Example
Resource address	Unique identifier for a resource	`github_repository.production-repo`
Data source	Read existing or external resources	`data "aws_ami" "ubuntu" { ... }`
Formatting	Standardize HCL layout across files	`terraform fmt`
Filesystem layout	Split logical concerns across `.tf` files	`github.tf`, `network.tf`, `main.tf`

Summary

Use resource referencing to avoid hard-coded values and to let Terraform compute dependencies automatically.
Give each resource a unique local name within its type to avoid address collisions.
Organize resources into multiple .tf files for clarity; Terraform evaluates them as a single configuration.
Enforce consistent formatting with terraform fmt.

Use resource references to create clear, maintainable relationships between blocks, and rely on Terraform’s dependency graph instead of manual ordering.

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Lets Look at Resource Referencing with Demo

Watch Video