A network workspace in HCP Terraform publishes an output named vpc_id. Several application workspaces read it through tfe_outputs and are linked by run triggers. A developer wants to rename the output to network_vpc_id. What is the main risk, and how should it be handled?
Select an answer to reveal the explanation.
Short Explanation
An output is a public promise, and other workspaces have built on it. If you rename it, every consumer that asks for vpc_id gets nothing back, so keep both names for a while, move the consumers, then retire the old one. The trap is the moved block, which only renames resources and modules.
Full Explanation
Root module outputs are the interface other workspaces consume. The tfe_outputs data source, which HashiCorp recommends over terraform_remote_state because it does not need full state access, returns the source workspace's outputs keyed by name, so a consumer referencing vpc_id fails as soon as an apply in the source workspace removes that output. Run triggers then make the failure spread quickly, because each successful apply in the network workspace queues runs in the linked workspaces. The safe approach is an expand and contract change: add network_vpc_id alongside vpc_id, migrate each consumer, and remove the old output only after all of them have been updated. Outputs are not addressed by position; they form a named map. Moved blocks apply to resources and module calls, not to output values, so they cannot redirect a consumer to a new output name. Removing run triggers changes only whether runs queue automatically; consumers read current outputs on each run regardless, and nothing is frozen. Exam caveat: identify consumers before the change by reviewing run trigger connections and the workspace's remote state sharing settings, since any of those workspaces may read outputs. Operational check: list the workspaces linked to the network workspace, search their code for the output name, and confirm each consumer plans cleanly against the new name before deleting the old output.