Exercise 3: Renaming a Resource Safely With terraform state mv — Possible Solution
====================================================================

The correct command is:

    terraform state mv local_file.web local_file.app_server

Per Chapter 3's addressing rules, a resource's identity in Terraform's
eyes is its ADDRESS (type + local name) -- `local_file.web` and
`local_file.app_server` are, from Terraform's perspective, two
completely different resources, even if the underlying HCL block is
otherwise identical. Simply editing the block's label in the .tf file
from "web" to "app_server," without also updating state, would make
Terraform's next plan see: `local_file.web` no longer appears in
configuration (plan: destroy it) and `local_file.app_server` appears
with no matching state entry (plan: create it) -- exactly the
destroy-then-create outcome the team wants to avoid.

`terraform state mv` updates the STATE FILE's own mapping directly,
telling Terraform "the real object state used to track under
`local_file.web` should now be tracked under `local_file.app_server`"
-- so once the .tf file's label is also updated to match, `plan` sees
a state entry that already lines up with the renamed configuration
block, with the real object's ID unchanged throughout. No destroy, no
create, just a name change in Terraform's own bookkeeping.

Why hand-editing the state file directly is risky instead: state's
internal JSON structure includes exact resource IDs, dependency
metadata, and provider-specific attribute schemas that have to stay
internally consistent for Terraform to parse the file correctly. A
manual edit that gets the resource's key renamed but misses an
internal reference elsewhere in the same file (or introduces a typo,
or breaks the JSON syntax itself) can corrupt state badly enough that
Terraform loses track of the resource entirely -- exactly the risk the
chapter's own tip-box warns about. `terraform state mv` performs the
same rename through Terraform's own understanding of the file's
structure, so it can't leave state in an inconsistent condition the
way a manual edit can.

WHY THIS WORKS AS AN ANSWER
------------------------------
This names the exact command, explains WHY a plain .tf label edit alone
would trigger a destroy+create (tying back to Chapter 3's addressing
rules), and explains the specific mechanical risk of hand-editing state
(internal consistency Terraform's own tooling guarantees but a manual
edit doesn't) rather than a vague "it's risky" claim.