Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

4.2.1. Attributes and Cross-Resource References

💡 First Principle: Every managed object exposes attributes (some you set, some the provider computes after creation), and referencing a computed attribute is what forces correct ordering — you literally can't use a value that doesn't exist yet, so Terraform creates the source first.

Resources are addressed as <TYPE>.<NAME> and their attributes as <TYPE>.<NAME>.<ATTRIBUTE> (for example aws_vpc.main.id). Some attributes are arguments you provided; others are computed — only known after the provider creates the object (like a generated ID or IP). Referencing a computed attribute elsewhere both passes the value and tells Terraform "create the source before the consumer."

Terraform also exposes other named values you reference the same way: var.name (input variables), local.name (locals), module.name.output (module outputs), data.type.name.attr (data sources), plus count.index, each.key/each.value, and path/terraform info objects.

⚠️ Exam Trap: Know the addressing syntax precisely. Resource attributes have no prefix (aws_vpc.main.id); data sources use data.; variables use var.; module outputs use module.. Mixing these up — e.g., writing var.aws_vpc.main — is a common distractor pattern.

Reflection Question: Why does referencing a resource's computed attribute (like an auto-generated ID) guarantee correct creation order, while a hard-coded string wouldn't?

Alvin Varughese
Written byAlvin Varughese
Founder18 professional certifications