Exercise 2: Configuration Drift, Even With IaC in Use — Possible Solution
====================================================================

What configuration drift is:

Configuration drift is when the ACTUAL state of deployed
infrastructure no longer matches what's recorded as the INTENDED
state -- environments (or a tool's own tracked understanding of what
exists) quietly diverge from what they're supposed to be over time,
often without anyone noticing until something breaks or behaves
unexpectedly.

How it can still happen even with IaC in genuine use:

Per the chapter, an IaC tool relies on a STATE FILE that tracks what
it currently believes exists, so it can compute the difference between
that and the desired state described in the config. If someone makes
a change DIRECTLY in the console -- a "quick console fix" during an
incident, made outside the IaC tool entirely -- that change is real
and does affect the actual infrastructure, but the IaC tool's state
file was never updated to reflect it. The tool's tracked understanding
of reality and the ACTUAL reality have now diverged -- which is
configuration drift, happening specifically BECAUSE someone bypassed
the IaC tool for a one-off change, not because the organization failed
to adopt IaC at all.

The practical consequence, per the chapter: the next time the tool
runs a plan, its output can be confusing -- it may show changes that
don't obviously correspond to anything the team intentionally edited
in the config, because it's actually trying to reconcile the drift
introduced by that earlier manual change, not a genuine config update.

WHY THIS WORKS AS AN ANSWER
------------------------------
This shows that IaC adoption REDUCES drift risk but doesn't eliminate
it entirely -- the specific mechanism (a manual change bypassing the
tool, leaving its state file stale) is exactly the scenario the
chapter's own tip-box describes, and connects the abstract definition
of "drift" to the chapter's own concrete real-world example of how it
actually creeps back in.