Exercise 2: Deleting the Middle Item From a count = 3 Resource — Possible Solution
====================================================================

With `count = 3`, the three resources are addressed purely by
POSITION: `local_file.server_config[0]`, `[1]`, `[2]`. There is no
independent identity attached to each one beyond its numeric index --
Terraform has no way to know that index 1 specifically "is" whatever
the team intends to remove; it only knows the count changed from 3 to
2.

When the team edits the configuration down to what should logically be
"index 0 and index 2, with index 1 gone," Terraform instead sees a
LIST that shrank from 3 items to 2. Since addressing is purely
positional, its plan is: destroy `[2]` (the former index 2, since it no
longer has a slot in a 2-item list) and destroy-then-recreate `[1]`
(since whatever now occupies logical position 1 in the shortened list
is, from Terraform's perspective, a DIFFERENT resource than whatever
used to be at `[1]`) -- even though the team's actual intent was to
leave the item that's now at position 1 (originally index 2) completely
untouched. In effect, two of the three resources get destroyed and one
gets recreated, to accomplish what should have been a single deletion.

`for_each`, by contrast, keys each resource by a stable NAME rather
than a position -- `local_file.server_config["web"]`,
`["api"]`, `["worker"]`. Deleting `"api"` from the underlying set only
ever affects `local_file.server_config["api"]`; `"web"` and `"worker"`
are referenced by their own names, not by where they happen to sit
in a list, so removing one item from the middle of the set has zero
effect on the other two -- Terraform's plan shows exactly one resource
destroyed and nothing else touched.

WHY THIS WORKS AS AN ANSWER
------------------------------
This traces the concrete mechanical consequence (positional indices
shifting causes an unintended destroy+recreate cascade on unrelated
resources) rather than just stating "count is worse," and explains
precisely why for_each's name-based keys structurally can't have this
problem.