Exercise 1: Why the Remote Backend Had to Be Configured First — Possible Solution
====================================================================

Every resource created after the backend is configured has its state
written to WHEREVER the currently-active backend points -- if
Terraform starts on the default local backend and the team only adds a
remote backend later, every resource created in the meantime has
already been recorded in a LOCAL state file, not the shared one. Per
Chapter 6, moving state to a new backend afterward requires an
explicit `terraform init -migrate-state` step, which isn't automatic
and has to be deliberately run and confirmed -- an extra step with real
risk (a migration that goes wrong, or a teammate who doesn't realize
they still need to re-init) that configuring the backend correctly
from the very first `apply` avoids having to do at all.

More fundamentally, Chapter 6 also established that local state is
inherently unsafe for anything beyond solo experimentation -- no
locking, no shared record for a team, and the plaintext-secrets-in-git
risk from Chapter 5 sitting on a single person's disk rather than
behind the encrypted, access-controlled S3 bucket this capstone
actually uses. Since this capstone's database tier includes a
`sensitive` `db_password` variable from Step 3, even the very first
resources created need their state protected by the same encrypted
backend the rest of the environment relies on -- there's no "safe"
window early on where local state would be acceptable, given secrets
are involved from the start.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the concrete migration cost of adding a backend later
(the explicit, error-prone `-migrate-state` step) and connects the
urgency specifically to this capstone's own sensitive variable, rather
than a generic "remote state is best practice" claim.