Exercise 3: Why admin_email Gets Vault Protection Anyway — Possible Solution
====================================================================

Honest answer:

The colleague has a fair point that admin_email isn't a password or
an API key in the traditional sense -- on its own, an email address
leaking isn't catastrophic the way a database credential leaking
would be. But per ansible1-8's own material, the real question isn't
"is this value maximally sensitive" -- it's "would I be comfortable
with this value being fully public, forever, in this repository's
git history." An admin email address tied to a specific
infrastructure's Let's Encrypt registration is still a piece of
information an attacker could use for reconnaissance or targeted
phishing against whoever administers this specific server -- genuinely
minor compared to a real credential, but still not something with
zero value to keep private. Encrypting it costs almost nothing
(ansible1-8's own encrypt_string keeps the rest of the vars file fully
readable), so the practical cost of protecting a mildly sensitive
value is low even if the value itself isn't maximally critical.

-- A genuinely sensitive value this capstone would need to protect the
same way in a real deployment --

Any credentials this capstone's roles don't currently show explicitly
but a REAL deployment would need -- most concretely, an API token if
DNS-01 validation were used instead of the HTTP-01 validation implied
by the --apache flag (a DNS provider API key, needed to prove domain
ownership via DNS records, is a genuine credential with real access to
modify DNS). Alternatively, if fail2ban or the firewall role were
extended to send alert notifications (e.g. via a Slack webhook URL or
an email-relay service's own API key), that webhook URL or API key
would be a real secret, on the same level pipelines1-5/crypto1-11
already warned about, and would need exactly the same encrypt_string
treatment this chapter gave admin_email.

WHY THIS WORKS AS AN ANSWER
------------------------------
This gives an honest, non-defensive answer that concedes the
colleague's point is partly fair while still explaining the real
reasoning (low cost, non-zero risk) rather than overstating
admin_email's own sensitivity, and names a genuinely more sensitive
credential a real deployment of this same capstone would plausibly
need to protect.