Exercise 1: Why sensitive = true Alone Doesn't Protect a Secret — Possible Solution
====================================================================

`sensitive = true` operates purely at the DISPLAY layer -- it tells
Terraform's CLI to print `(sensitive value)` instead of the real string
whenever that variable would otherwise appear in `plan`/`apply` output.
It changes nothing about how or where the actual value is STORED.

The real value is still written into the state file, in plaintext,
exactly as it would be without the sensitive flag -- state has to
record the true value of every resource attribute in order for
Terraform to later compare desired state against actual state (the
mechanism established back in Chapter 1's Exercise 1), and a redacted
placeholder wouldn't let it do that. So the secret is fully readable by
anyone who can open the state file directly, regardless of the CLI
never displaying it.

What actually needs protecting is the STATE FILE ITSELF -- who can read
it, where it's stored, and whether it's encrypted -- which is exactly
Chapter 5's own subject. Marking a variable sensitive is a useful,
worthwhile precaution against a secret appearing in a terminal log or a
CI job's captured output, but it is not, by itself, a complete answer
to "is this secret actually protected" -- that answer depends on the
state file's own security, covered next.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes what `sensitive` actually changes (display output
only) from what it doesn't (storage), correctly identifies the state
file as still holding the plaintext value and explains WHY it has to
(to support desired-vs-actual comparison), and names the real
protection surface (state file security) rather than treating the flag
as a complete solution.