Terraform – Referring to other resource blocks

Learn how to reference resource attributes in Terraform using the .. pattern. Master implicit dependencies and string interpolation to create dynamic, connected infrastructure configurations.

In real-world infrastructure, resources are rarely isolated. Many resource settings depend on values produced by other resources (for example: an ID, a name, or a generated secret). Terraform lets you reference those values directly, so you can build connected, realistic infrastructure without manually copying values between files.

In the example below, we create:

  • a random string using the random provider, and
  • a local file whose content includes that generated string using the local provider.

A good habit is to verify resource arguments and outputs from the provider documentation. Terraform providers and resources are documented in the Terraform Registry. For example, the random_string resource defines an output attribute called result, which becomes available after terraform apply.

Terraform Registry documentation showing random_string resource attributes (including result)

We are interested in the output attribute result, which Terraform marks as “known after apply” during the plan phase (because it will be generated when Terraform actually creates the resource).

Terraform random_string documentation snippet showing the result attribute

Understanding Terraform Resource References

Terraform exposes every resource as <resource_type>.<resource_name>.<attribute>. For example:

  • random_string.randomstring.result → the generated string (after apply)

When you want to embed a reference inside a longer string, use string interpolation:

  • ${random_string.randomstring.result}

In the next snippet, we write a file whose content includes the random string. The file will be created only after the random string exists, because we referenced it in content.

resource "random_string" "randomstring" {
  length = 15
}

resource "local_file" "dynamicfile" {
  content  = "Hey! This file contains a randomly generated string: ${random_string.randomstring.result}"
  filename = "randomfile.txt"
}

Beginner note: Even if you swap the block order, Terraform will still create them in the correct order. Terraform does not execute “top to bottom like a script”; it builds a dependency graph based on references.

terraform init
terraform plan
terraform apply
Initializing the backend...
Initializing provider plugins...
- Finding latest version of hashicorp/random...
- Finding latest version of hashicorp/local...
- Installing hashicorp/random v3.8.1...
- Installed hashicorp/random v3.8.1 (signed by HashiCorp)
- Installing hashicorp/local v2.6.2...
- Installed hashicorp/local v2.6.2 (signed by HashiCorp)
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

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. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
PS D:\tflab\tflabs_values_from_resource_block> terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

# local_file.dynamicfile will be created
+ resource "local_file" "dynamicfile" {
+ content = (known after apply)
+ content_base64sha256 = (known after apply)
+ content_base64sha512 = (known after apply)
+ content_md5 = (known after apply)
+ content_sha1 = (known after apply)
+ content_sha256 = (known after apply)
+ content_sha512 = (known after apply)
+ directory_permission = "0777"
+ file_permission = "0777"
+ filename = "randomfile.txt"
+ id = (known after apply)
}

# random_string.randomstring will be created
+ resource "random_string" "randomstring" {
+ id = (known after apply)
+ length = 15
+ lower = true
+ min_lower = 0
+ min_numeric = 0
+ min_special = 0
+ min_upper = 0
+ number = true
+ numeric = true
+ result = (known after apply)
+ special = true
+ upper = true
}

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

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.
PS D:\tflab\tflabs_values_from_resource_block> terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

# local_file.dynamicfile will be created
+ resource "local_file" "dynamicfile" {
+ content = (known after apply)
+ content_base64sha256 = (known after apply)
+ content_base64sha512 = (known after apply)
+ content_md5 = (known after apply)
+ content_sha1 = (known after apply)
+ content_sha256 = (known after apply)
+ content_sha512 = (known after apply)
+ directory_permission = "0777"
+ file_permission = "0777"
+ filename = "randomfile.txt"
+ id = (known after apply)
}

# random_string.randomstring will be created
+ resource "random_string" "randomstring" {
+ id = (known after apply)
+ length = 15
+ lower = true
+ min_lower = 0
+ min_numeric = 0
+ min_special = 0
+ min_upper = 0
+ content_sha256 = (known after apply)
+ content_sha512 = (known after apply)
+ directory_permission = "0777"
+ file_permission = "0777"
+ filename = "randomfile.txt"
+ id = (known after apply)
}

# random_string.randomstring will be created
+ resource "random_string" "randomstring" {
+ id = (known after apply)
+ length = 15
+ lower = true
+ min_lower = 0
+ min_numeric = 0
+ min_special = 0
+ min_upper = 0
+ filename = "randomfile.txt"
+ id = (known after apply)
}

# random_string.randomstring will be created
+ resource "random_string" "randomstring" {
+ id = (known after apply)
+ length = 15
+ lower = true
+ min_lower = 0
+ min_numeric = 0
+ min_special = 0
+ min_upper = 0
+ resource "random_string" "randomstring" {
+ id = (known after apply)
+ length = 15
+ lower = true
+ min_lower = 0
+ min_numeric = 0
+ min_special = 0
+ min_upper = 0
+ lower = true
+ min_lower = 0
+ min_numeric = 0
+ min_special = 0
+ min_upper = 0
+ number = true
+ min_special = 0
+ min_upper = 0
+ number = true
+ number = true
+ numeric = true
+ result = (known after apply)
+ special = true
+ upper = true
}

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

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

random_string.randomstring: Creating...
random_string.randomstring: Creation complete after 0s [id=gOLU9h7)x*S{qE3]
local_file.dynamicfile: Creating...
local_file.dynamicfile: Creation complete after 0s [id=c5eb868ffab9763cc53a94aa3cb5f70d02aab50f]

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

Repo link – srnyapathi/tflabs_values_from_resource_block

During terraform plan, you will see (known after apply) for the generated values (like random_string.randomstring.result). That is expected: Terraform can only know them after the resource is created.

Implicit Dependency

If you observe closely, local_file.dynamicfile uses random_string.randomstring.result inside its content. Because of that reference, Terraform automatically understands that:

  • random_string.randomstring must be created first, and
  • local_file.dynamicfile must be created after it.

This automatic ordering is called implicit dependency. It is the primary way Terraform detects relationships between resources (through expressions/references).

Sometimes you may have a dependency that is not visible through arguments (for example, a resource must exist before another runs, but no attribute is directly referenced). In such rare cases, Terraform provides an explicit dependency mechanism using depends_on.

In practice, random values are often used for generating unique suffixes (to avoid naming collisions) or for credentials. For sensitive passwords, make sure you choose a resource/type that matches your security needs and store secrets safely (for example, a secret manager rather than plain text files).

Conclusion

Referencing values across resources is one of the most powerful parts of Terraform. Once you understand <resource_type>.<name>.<attribute> and string interpolation, you can connect resources naturally just like real infrastructure works. Terraform then uses those references to automatically build a dependency graph and apply resources in the right order (implicit dependency). As your setups grow, this pattern keeps your configuration clean, avoids manual copy/paste, and makes your infrastructure easier to evolve safely.

srnyapathi
srnyapathi
Articles: 41