Attributes, References, and Meta-arguments

Terraform keeps every addressable object in one flat namespace, and a reference expression walks into it with dots. The five prefixes you will use every day:

resource "aws_instance" "web" {
  ami                    = data.aws_ami.ubuntu.id      # data source attribute
  subnet_id              = aws_subnet.private[0].id    # managed resource, indexed
  iam_instance_profile   = var.instance_profile        # input variable
  tags                   = local.common_tags           # local value
  vpc_security_group_ids = [aws_security_group.web.id] # resource → attribute, wrapped in a list
}

The traversal reads left to right, and the first segment names the scope: var, local, data, module, each, count, terraform are reserved prefixes; anything else starts with a resource type (aws_instance, aws_subnet). The second segment is the object's local name, and together they form the address you met in state — aws_instance.web — with attribute accesses (.id, .private_ip), indexes ([0], ["blue"]), and more segments continuing to the right. Every one of these is an expression, which leads to the assignment rule that HCL enforces without exception: name = expression — an equals sign between an identifier and exactly one expression. You cannot write ami = "x" "y", and there is no comma-separated multi-assignment; repeated attributes in one body are a parse error, as you saw in Block Structure and Nesting.

The error messages from bad traversals are a vocabulary worth learning, because they localize your bug in one read. "Reference to undeclared resource" means the type+name does not exist anywhere in the directory — usually a typo or a resource you deleted. "Unsupported attribute" means the object exists but has no attribute of that name — usually a provider version change or a wrong guess about the schema, fixed by reading terraform state show <addr> for the real attribute list. "Invalid index" means the key is out of range or missing from the collection. And "A reference to a resource type must be followed by at least one attribute access" fires when you write aws_instance.web alone where a scalar is expected — a whole resource object is not a string, so you must descend to an attribute (.id).

Two traversal forms deserve separate mention because they show up constantly in real configurations. The splat expression compresses "map every element to an attribute": aws_subnet.private[*].id is the shorthand for projecting the id of every element, producing a list of IDs that feeds directly into arguments like vpc_security_group_ids or a join(",", ...) — you saw it in the last topic and will keep seeing it. And index expressions accept expressions, not just literals: var.subnets[each.value], local.rules["ingress"], and data.aws_subnets.chosen.ids[0] are all ordinary traversals with a computed key, which means dictionaries (maps and objects) double as lookup tables in configurations — a locals map of per-environment settings indexed by terraform.workspace is a pattern you will meet again in the variables topic.

Two practical rules complete the picture. References may appear anywhere an expression may: attribute values, variable defaults are the one exception (defaults cannot reference anything), outputs, count and for_each expressions, even inside string templates. And the reference does not "fetch a value" the way a function call might — it establishes a dependency. When Terraform sees subnet_id = aws_subnet.private[0].id it records: this resource cannot be planned before that subnet's ID is known. Every dependency edge in the graph starts as a dot in a reference like this one, which you will manipulate deliberately in Implicit and Explicit Dependencies.

Open a resource block's schema documentation and you will never find the word count. That is because some keys in a block body are interpreted by Terraform itself, before any provider is consulted — meta-arguments. Recognizing them by name is the difference between reading configuration and misreading it:

Two of them rewrite the object's address, which is why they dominate interview questions. With count, every reference to the resource becomes a list and needs an index or a splat:

resource "aws_ebs_volume" "data" {
  count             = 3
  availability_zone = "${var.region}${count.index}abc"   # count.index: 0, 1, 2
}

resource "aws_volume_attachment" "data" {
  for_each    = toset(["blue", "green"])
  volume_id   = aws_ebs_volume.data[each.key].id    # for_each: each.key / each.value
  device_name = "/dev/sdf"
}

The consequence to internalize: switching a resource from count = 2 to for_each = toset(["blue", "green"]) changes every address — [1] becomes ["green"] — and Terraform will plan to destroy the old instances and create new ones unless you terraform state mv each one first. That is the practical reason teams reach for for_each whenever instances carry meaningful names: count's numeric indexes are fragile the moment the set is reordered or an element is inserted.

Meta-arguments interact with the type system too. count must be a number, for_each a map or set (a tuple errors with "Invalid for_each argument... must be a map or set"), and depends_on accepts only a list of whole object references — depends_on = [aws_iam_role.app] — never attribute references, because ordering is about objects, not values. Because Terraform recognizes these names itself, an unknown key is not silently ignored: cont = 3 fails validation with "Unsupported argument", your typo caught before it does nothing forever.

A compact example shows how the address-changing pair behaves on a realistic resource:

resource "aws_sns_topic" "events" {
  for_each = toset(var.event_topics)   # ["orders", "billing"] -> two instances

  name = "${var.project}-${each.value}"
}
# addresses: aws_sns_topic.events["orders"], aws_sns_topic.events["billing"]

References to it take keys: aws_sns_topic.events["orders"].arn, or the splat values(aws_sns_topic.events)[*].arn when you want all of them. Two practical rules of thumb hard-won in production: prefer for_each whenever instances carry names you would recognize in a console, because a filtered or reordered list then produces targeted, reviewable diffs instead of index-shifted carnage; and treat count as the choice for anonymous, identical replicas where nothing meaningful can be removed from the middle. The lifecycle meta-argument — the fourth in the table — is complex enough to deserve its own advanced topic later; provider and depends_on are covered in depth in the resources and dependencies phases ahead.

Here is the sentence that confuses every newcomer, stated precisely: referencing an object that does not exist yet is legal, and the reference resolves to an unknown value at plan time. The plan output writes it as (known after apply):

resource "aws_instance" "web" {
  ami = data.aws_ami.ubuntu.id
}

output "public_ip" {
  value = aws_instance.web.public_ip
}

+ resource "aws_instance" "web" {
      + id = (known after apply)
      + public_ip = (known after apply)   # provider cannot compute it before the server exists
  }

Nothing here failed. Terraform knows aws_instance.web will exist after this apply, and it knows the attribute's type; what it cannot know is the value the cloud will assign. So the value is typed and deferred, and the plan is still a complete, executable document: create the object, then compute dependents. This is precisely what lets one plan contain a whole dependency chain of resources that reference each other — the graph plus unknowns replace any need to run commands step by step.

Unknowns propagate like a type-preserving fog. Any expression built on an unknown produces an unknown of the result type: "i-${aws_instance.web.id}" is an unknown string; length(var.list) on a known list is known; an arithmetic op on an unknown number is an unknown number. Conditionals have the sharpest rule: if the predicate is unknown, the whole conditional is unknown of the branches' unified type — you cannot force Terraform to choose a branch from a fact the cloud has not supplied. Functions refuse to guess too: cidrsubnet(var.cidr, 4, 0) with an unknown var.cidr returns an unknown rather than an error, because evaluation is deferred, not broken.

Unknowns are also the reason a plan for a brand-new environment lists (known after apply) on most computed attributes while every configuration decision is already fully determined. The distinction to rehearse: arguments you wrote are known (they will be sent to the API as planned); attributes the provider reports back — IDs, ARNs, generated IPs — are unknown until the object exists. That is why plan review focuses on the arguments: they are the entire set of decisions you are making, and the unknowns are just the receipts. After the first successful apply the values become known — recorded in state, shown by terraform show — and later plans display the concrete old → new diff instead of a deferred placeholder, which is why perpetual (known after apply) on an attribute you expected to stabilize is itself a signal worth investigating.

The honest version of the keyPoint you will read in older material: referencing a not-yet-applied object does not make the plan fail — it makes the resulting value unknown until apply. Plan-time failures are reserved for references that can never resolve: undeclared resources, unsupported attributes, and — the interesting one — cycles. If resource A references B and B references A, dependency detection hits the impossibility head-on with "Cycle: aws_instance.a → aws_instance.b → aws_instance.a", naming the loop. Cycles are the graph refusing to lie about order, and breaking one usually means extracting a value to a third object or questioning whether the ordering you forced was ever real. Read the graph explicitly with terraform graph -type=plan (it prints GraphViz DOT), which turns "why is this waiting?" from archaeology into a picture.