Exercise 3: Why "Just Make It Public to Test" Is a Bad Idea — Possible Solution
====================================================================

Why this is a bad idea:

Per the chapter, a database that's unreachable from outside its
network is very often working EXACTLY AS DESIGNED -- Chapter 5 covered
the deliberate pattern of placing databases in a private subnet
specifically so they are NOT directly reachable from the internet,
precisely to reduce the attack surface. Making the database publicly
accessible "temporarily" to resolve a testing inconvenience directly
undoes that intentional security boundary -- and "temporarily" is a
genuinely risky word here, since a temporary change made under time
pressure is a well-known way permanent security regressions get
introduced: it's easy to forget to revert, and even a short exposure
window is enough for a database sitting on the open internet to be
found and probed by automated scanning that happens constantly across
the entire internet, not just when someone is deliberately targeting
this specific system.

This trades a minor, one-time inconvenience (a developer's laptop
can't reach the database directly) for an ongoing, serious security
risk (the database is now reachable by anyone on the internet, not
just the developer) -- a poor trade even if nothing goes wrong
immediately.

The correct approach instead:

1. A BASTION HOST -- a single, tightly access-controlled server placed
   in a public subnet specifically to allow authorized users to
   "jump" through it into the private network, rather than opening the
   private resource itself to the internet.

2. A VPN CONNECTION -- allowing an authorized user's laptop to join the
   private network directly and securely, so the database remains
   unreachable from the general internet the entire time.

3. AN APPLICATION-TIER PROXY -- a controlled intermediary that the
   application already uses to reach the database, which could
   plausibly be reused for authorized testing access without exposing
   the database directly.

Any of these preserves the private-subnet security boundary while
still solving the actual underlying need -- legitimate, authorized
access for testing -- without exposing the database to the entire
internet in the process.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly applies the chapter's own warn-box, which names exactly
this scenario and lists exactly these three correct alternatives
(bastion host, VPN, app-tier proxy) -- the core reasoning being that
"database unreachable from outside" is frequently a working security
feature, not a bug, and the fix should restore authorized access
without removing the boundary that made the database appropriately
inaccessible to everyone else in the first place.