Exercise 2: Ten Ordinary Variables Plus One API Key — Why encrypt_string Fits Better — Possible Solution
====================================================================

Explanation:

Per the chapter's own compare-table, encrypting the whole file makes
its diff entirely opaque ciphertext, with no visible structure at
all -- meaning a reviewer looking at a future change to this file
would see nothing meaningful in a code review or git blame, even for
changes to the nine completely ordinary, non-sensitive variables that
have nothing to do with the one API key. That's a real, unnecessary
cost here: only one out of eleven total values actually needs
protecting, but whole-file encryption would hide all eleven equally.

encrypt_string, by contrast, offers exactly the right granularity for
this situation -- it encrypts only the api_key value itself, leaving
the other ten ordinary variables (their names AND their values) fully
readable in the file and in any future diff. A teammate reviewing a
change to one of the nine unrelated variables would see a normal,
readable diff for that specific change, while the api_key entry stays
protected as an opaque !vault block regardless of what else in the
file changes. Given that only one value out of many actually needs
encryption, encrypt_string's per-value granularity is the better fit
-- whole-file encryption would be reasonable if EVERY value in the
file were sensitive, but that's not the case described here.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly applies the chapter's own compare-table (diff
readability and granularity) to the specific 10-ordinary/1-sensitive
ratio described in the exercise, explaining why whole-file encryption
would be real overkill here rather than just restating the general
tradeoff.