Exercise 2: Why the Lock File Is Committed and .terraform/ Is Not — Possible Solution
====================================================================

`.terraform.lock.hcl` records the EXACT provider version and checksum
that was actually installed when `init` last ran -- a small, purely
textual record of a decision ("this configuration uses hashicorp/local
v2.5.1, with this exact checksum"). Committing it to git means every
teammate (or CI runner) who later runs `terraform init` against this
same configuration gets that identical provider build, not merely
"something matching ~> 2.5" that could quietly differ in patch version
between two people's machines -- exactly the reproducibility guarantee
the chapter draws a direct parallel to.

`.terraform/`, by contrast, is not a record of a decision -- it's the
actual DOWNLOADED BINARY of the provider plugin itself, a large,
regeneratable local cache. Nothing about it needs to be preserved in
git, since `terraform init` will recreate it identically on any machine
by reading the lock file and re-downloading the exact same provider
version it specifies. Committing it would bloat the repository with
binary files that add no information beyond what the lock file already
records.

The parallel the chapter draws explicitly: this is the same relationship
as `package-lock.json` (committed) vs. `node_modules/` (never
committed) in Node's ecosystem, or `Gemfile.lock` (committed) vs. the
installed gems themselves in Ruby's. In every case, the LOCK FILE is
the small, textual, reproducibility-guaranteeing record; the actual
downloaded artifacts are a disposable local cache regenerated from it.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes the lock file (a record of a version decision) from
the `.terraform/` directory (the disposable binary artifacts that
decision produces) by what each actually IS, not just by "one is
committed and one isn't," and correctly identifies the specific
cross-ecosystem parallel the chapter itself draws.