Error: Unsupported attribute: "This object does not have an attribute named" in Terraform

TL;DR

You asked for an attribute that does not exist on that object. Most of the time you reached past a module boundary (module outputs are the only view a caller gets) or you used a resource attribute that the provider renamed or removed. Fix the reference to use an attribute the object actually has, then terraform validate to confirm.

The error

Error: Unsupported attribute

  on extra.tf line 2, in output "direct":
   2: value = module.app.terraform_data.server.id
     ├────────────────
     │ module.app is object with 1 attribute "server_id"

This object does not have an attribute named "terraform_data".

Steps to fix

1. Read the line the error names. The ├ line tells you exactly what the object has (here: one attribute, server_id). That is the whole allowed interface.

• Expected: you can see the mismatch between what you wrote and what exists.

1. If you referenced a resource inside a module (module.app.terraform_data.server.id), stop: callers cannot reach into modules. Add an output inside the module exposing what you need, then reference module.app.[output_name].

• Expected: the output name appears in the module's outputs.tf.

1. If you referenced a resource attribute directly (aws_instance.web.private_ip), check the provider docs for that resource: the attribute may have been renamed in a newer provider version, or it may only exist after apply (use the exact documented name).

• Expected: docs list the attribute you switched to.

1. Run terraform validate.

• Expected: Success! The configuration is valid.

When to use this

• You see Unsupported attribute / does not have an attribute named after editing references, upgrading a provider, or wiring module outputs.

When NOT to use this

• Unsupported argument (wrong argument inside a block) is a different error with a different fix. Reference to undeclared resource means the whole resource is missing, not just the attribute.

Compatibility

• Terraform 0.12+ (expression errors are stable across 1.x). Provider attribute renames are the usual trigger on major provider upgrades (AWS provider 4.x/5.x/6.x moved several).

Root cause

Terraform evaluates attribute access against the object's type. A module call evaluates to an object containing only its declared outputs, never the resources inside it. For resources, the attribute set comes from the provider schema, so a provider upgrade that renames or drops an attribute turns a working reference into this error with zero config changes on your side.

Edge cases

• With count/for_each, remember the resource is a tuple/map: aws_vpc.this.id must be aws_vpc.this[0].id (or wrap in try()).
• data.terraform_remote_state.X.outputs only has keys the other configuration actually outputs; a renamed output upstream breaks this reference.
• Splat expressions (aws_instance.web.*.id) return tuples; accessing .id on the tuple itself gives this error.