Addresses and Attribute References

Scenario: An engineer runs a state command against server.api, forgetting the type and instance key, and operates on nothing.

A resource address identifies a block and optionally an instance: fakecloud_server.api, fakecloud_server.api[0], or fakecloud_server.api["blue"]. References create graph dependencies and propagate values. Provider-computed attributes may remain unknown during planning. Avoid copying IDs into variables when Terraform can reference the producing object directly; copied IDs hide dependency edges and become stale.

Analogy: An address is a library call number; an attribute reference is a citation. A copied sentence loses the live connection to its source.

A worked configuration

resource "fakecloud_network" "app" { name = "app" }
resource "fakecloud_server" "api" {
  name       = "api"
  network_id = fakecloud_network.app.id
}
output "api_address" { value = fakecloud_server.api.address }

Stable, meaningful addresses make state operations and refactors safer. Renaming labels changes Terraform's address even when provider settings stay identical, so pair address changes with moved blocks rather than accepting destroy/create.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-dependency-ordering Terraform lab. Open /labs/terraform and choose slug tf-dependency-ordering; the lab runs real Terraform against the offline FakeCloud provider.