Exercise 1: Why Terraform Needs a State File at All — Possible Solution
====================================================================

Without a state file, Terraform would have no persistent record of
which real-world objects it had already created versus which objects
merely happen to exist for some other reason -- created by hand, by a
different tool, or by a previous unrelated run. Given only a
configuration file saying "there should be one VM with these
properties," Terraform would have to guess, on every single `plan`,
whether a VM matching that description already exists and was created
BY this configuration, or whether it needs to create a new one.

Concretely, what breaks without state:

1. NO WAY TO DISTINGUISH "already created by me" FROM "just happens to
   match." Two resources could end up looking identical from the
   outside (same type, same name, same attributes) without one having
   any actual relationship to the other -- state is what ties a
   specific configuration block to a specific real object by its
   unique ID, not by matching attributes.

2. RISK OF DUPLICATE CREATION. Re-running `apply` without state to
   check against could create a second copy of a resource that
   already exists, since there'd be no record telling Terraform
   "this one's done."

3. THE DESIRED-VS-ACTUAL COMPARISON FROM CHAPTER 1 BECOMES IMPOSSIBLE.
   That comparison specifically requires an "actual state" side to
   compare against -- state IS that side. Idempotency (Chapter 1
   Exercise 1, demonstrated concretely in Chapter 2 Exercise 1) depends
   entirely on having a reliable record of what already exists to
   diff the configuration against.

WHY THIS WORKS AS AN ANSWER
------------------------------
This names three concrete, specific failures (no created-by-me
tracking, duplicate-creation risk, and the collapse of the
desired-vs-actual comparison the whole course has built on since
Chapter 1) rather than a single vague "state keeps track of things"
answer.