Exercise 1: Why Declarative State Comparison Avoids the Run-It-Twice Problem — Possible Solution
====================================================================

An imperative script encodes a fixed SEQUENCE OF ACTIONS, not a target
state. "Create a VM, then attach a disk, then open port 443" has no
awareness of what already exists -- it simply executes each step in
order. Run it a second time and "create a VM" is still just "create a
VM": if one already exists, the script either fails outright (a naming
conflict) or blindly creates a second one, since nothing in the script
ever checks current reality before acting.

A declarative tool like Terraform never encodes a sequence of actions
at all -- it encodes a DESIRED END STATE ("there should be exactly one
VM, with this disk, with this port open"). Before doing anything,
Terraform reads the ACTUAL current state (via its own state tracking,
covered in Chapter 5) and computes the DIFFERENCE between what's
declared and what actually exists. Only that difference becomes the
plan of action. Running the same configuration a second time, with
nothing changed, produces a plan with zero actions -- because desired
state and actual state already match. This property is called
idempotency: applying the same configuration repeatedly always
converges to, and then stays at, the same end state, rather than
re-running side effects each time.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly locates the root cause (imperative scripts have no
concept of "already exists," declarative tools compare against actual
state before acting) rather than just restating that Terraform is
"smarter," and names the specific property (idempotency) that the
chapter's plan/apply workflow depends on.