Exercise 2: The Three-Way Comparison Behind Drift Detection — Possible Solution
====================================================================

`terraform plan` compares three distinct things, not two:

1. CONFIGURATION -- what the `.tf` files declare should exist (e.g.
   "this instance should have type t3.micro").

2. STATE -- what Terraform last recorded as actually existing, from the
   previous apply (e.g. "state says this instance is t3.micro, created
   at such-and-such ID").

3. REAL INFRASTRUCTURE -- what's genuinely running right now, checked
   via a REFRESH step that queries the actual provider (e.g. AWS
   itself) for the real, current attributes of that same resource ID.

Drift is specifically a MISMATCH between #2 (state) and #3 (real
infrastructure) -- state says one thing, but the refresh discovers
reality now says something different, meaning something changed the
real resource WITHOUT going through Terraform. A manual console change
-- someone resizing the instance directly in the AWS console, say --
never touches Terraform's state file at all; state still says
"t3.micro" right up until the next `plan` runs its refresh step and
discovers the real instance is now, say, t3.large.

Once that mismatch is detected, `plan` then does its normal comparison
against #1 (configuration): since the configuration still says
"t3.micro," and refresh just revealed the real world now says
"t3.large," Terraform's plan will show an action to bring the instance
BACK to t3.micro on the next apply -- which is precisely the "manual
fix gets silently reverted by the next automated apply" scenario
`cloud1-11` warned about, now explained mechanically rather than just
described as a symptom.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies all three sources being compared (not just
"config vs. reality"), pinpoints drift specifically as a state-vs-
real-infrastructure mismatch detected by the refresh step, and traces
through to why the SUBSEQUENT plan then shows an action reverting the
manual change back toward configuration -- connecting the mechanism to
the specific `cloud1-11` scenario it explains.