A resource's friendly name and its state address can look similar in a short snippet. Treat them as separate fields in the request so a cosmetic cleanup does not quietly become an identity change.
Compare a label edit with a key edit
This original teaching configuration uses Terraform's built-in terraform_data resource. It records a display label without creating a cloud service:
locals {
teams = {
finance = { display_name = "Finance desk" }
support = { display_name = "Support desk" }
}
}
resource "terraform_data" "team" {
for_each = local.teams
input = each.value.display_name
}
The two configured addresses are terraform_data.team["finance"] and terraform_data.team["support"]. HashiCorp's for_each reference, checked October 24, 2026, describes keys as instance identifiers. The terraform_data reference explains the built-in resource used here.
Changing "Finance desk" to "Finance service desk" leaves the key finance in place. Changing finance to accounts changes the configured address. Terraform cannot infer that the new key represents the same intended instance merely because its label resembles the old one.
| Proposed edit | Configured address afterward | Question for review |
|---|---|---|
| Edit the finance display_name | terraform_data.team["finance"] | Does the input update match the intended label change? |
| Rename finance to accounts | terraform_data.team["accounts"] | Is this intentionally a new instance, or is an explicit migration needed? |
This table describes configuration identity. It is not an observed plan or a promise about a cloud provider's replacement behavior. In another resource type, provider rules and changed arguments also determine the planned actions.
Ask for address analysis before a patch
Review this Terraform rename proposal before editing anything.
Terraform version and relevant provider versions: [PASTE]
Exact resource/module block and for_each input: [PASTE]
Current relevant instance addresses, with secrets removed: [PASTE]
Desired user-visible name and what identity must stay stable: [ENTER]
Existing plan, if available: [PASTE OR NONE]
List the current and proposed instance addresses. Distinguish a map
key change from a display value change. Explain whether my intended
rename needs only an argument edit or a separately reviewed state
migration. Identify missing state/provider evidence. Do not infer
that similar labels mean the same instance. Propose a minimal patch
and expected plan questions; do not apply, import, delete or move state.
Do not claim an actual plan was run unless I supplied its output.
OpenAI's prompting guidance supports giving the goal and relevant constraints. For this task, the important constraint is the identity that must remain stable, not simply the spelling the team wants to see.
Read the actual plan against the intended change
If only the label should change, investigate any unexpected instance removal or creation before proceeding. If a key really must change while preserving the intended managed object, review Terraform's migration mechanism for the actual addresses and version instead of accepting a guessed state command.
Keep sensitive state contents out of the conversation; supply only the permitted address and argument evidence needed for this review. A saved plan also deserves the same handling rules as other infrastructure evidence.
For a filesystem problem inside a container, the Docker explanation guide addresses image and mount paths. Here, finish by recording the approved identity mapping and the real plan outcome. An explanation of the rename is ready for review before any apply is authorized.