Exercise 1: Why Provisioners Break the Desired-State Model — Possible Solution
====================================================================

Chapter 1 established Terraform's core model: describe a DESIRED STATE
declaratively, and let Terraform compute the difference against ACTUAL
state, tracked via state itself (formalized in Chapter 5). Every
resource attribute Terraform manages has a known, trackable value it
can compare against on every future plan.

A `local-exec`/`remote-exec` provisioner's command is not a resource
attribute at all -- it's an arbitrary shell command (or set of
commands) executed as a SIDE EFFECT of a resource being created.
Terraform has no way to represent "the effect of running `sudo
systemctl start nginx`" as a piece of desired state to compare against
in the future, because that effect isn't a declared attribute with a
known target value -- it's just an action that either ran or didn't.

Concretely, what Terraform can no longer track:

1. WHETHER THE COMMAND SUCCEEDED IN ANY LASTING SENSE. Terraform knows
   whether the command's exit code indicated success at the moment it
   ran, but has no ongoing awareness of whether whatever it did is
   still true later (e.g. whether nginx is still running).

2. WHETHER THE EFFECT HAS DRIFTED. Since there's no attribute
   representing the provisioner's result, a later `plan` has nothing
   to compare against -- if someone manually stops nginx afterward,
   Terraform has no mechanism to detect that as drift the way it would
   for a genuine resource attribute (per Chapter 5's three-way
   comparison).

3. HOW TO REVERSE OR RE-APPLY IT. Since the command isn't a declared
   attribute, Terraform doesn't automatically re-run it if the
   resource's other properties change, and doesn't know how to "undo"
   it on destroy unless a separate `when = destroy` provisioner is
   explicitly written for that purpose.

WHY THIS WORKS AS AN ANSWER
------------------------------
This connects the provisioner problem directly back to Chapter 1's
desired-state model and Chapter 5's drift-detection mechanism, naming
specifically what tracking capability is lost (ongoing success,
drift detection, re-application) rather than a vague "it's not
declarative."