Exercise 3: Making an Incident Fix Stick — the Two Legitimate Options — Possible Solution
====================================================================

Per the chapter, the two legitimate ways to make a manual fix stop
being reverted are:

OPTION (A) -- UPDATE THE CONFIGURATION TO MATCH THE NEW REALITY. If the
manual change is genuinely the correct, intended long-term state (say,
the incident revealed the instance needed a larger size permanently,
not just during the emergency), the `.tf` file itself should be edited
to declare that new value as the desired state. Once configuration and
reality agree, the next `plan` shows no diff, and there's nothing left
for `apply` to revert.

OPTION (B) -- IMPORT, IF THE RESOURCE WASN'T UNDER TERRAFORM AT ALL. If
the fix was applied to a resource Terraform doesn't manage in the first
place (less likely for an existing managed resource, but relevant if
the incident involved standing up something new by hand), that
resource needs to be brought under management via `terraform import`
plus a matching resource block, following Exercise 2's own workflow,
before Terraform has any awareness of it to preserve or revert.

Why "just don't run apply for a while" isn't a real fix: it doesn't
change the underlying mismatch between configuration and reality at
all -- it only delays the moment Terraform notices. The drift is still
there, silently, the whole time apply is avoided; per Chapter 5's
drift-detection mechanism, the very next `plan` (run by anyone, at any
point in the future, possibly someone with no memory of the incident)
will immediately surface the exact same "revert this back toward
configuration" action, with no warning that it represents an
intentional incident fix rather than genuine drift to be corrected.
Avoiding apply doesn't resolve the mismatch; it just defers the
eventual, uninformed revert to some later, likely worse, moment --
directly the "manual fix gets silently reverted by the next automated
apply" scenario `cloud1-11` warned about in the first place, simply
postponed rather than prevented.

WHY THIS WORKS AS AN ANSWER
------------------------------
This states both legitimate options precisely (update config vs.
import, matching exactly when each applies) and explains why avoiding
apply specifically fails -- it doesn't remove the underlying
config/reality mismatch, it only delays when that mismatch gets
noticed and acted on, likely by someone with no context for why the
change was made.