Exercise 1: Full-Disk Encryption's Real Boundary — Possible Solution
====================================================================

The critical difference is whether the disk is currently UNLOCKED or
not.

STOLEN SERVER SCENARIO: the server is powered off (or its disk is
physically removed) when it's stolen. Full-disk encryption means the
data on that disk is encrypted ciphertext with no way to read it
without the decryption key — the thief has a drive full of unreadable
noise. This is exactly the scenario full-disk encryption is designed
to prevent.

COMPROMISED DATABASE ACCOUNT SCENARIO: the server is RUNNING, which
means the disk has already been unlocked (decrypted) as part of normal
boot-up, and stays that way for as long as the server is powered on. A
compromised or overprivileged database account querying that running
system reads data through the database engine exactly as any
legitimate query would — the encryption has already been transparently
removed by the OS before the database or any query ever touches the
data. Full-disk encryption has nothing left to protect at this point;
its entire job was already done (or not needed) the moment the disk
was unlocked at boot.

The underlying principle: full-disk encryption protects data specifically
while it is AT REST in the literal sense — powered off, not currently
being accessed by a running system. Once a system is running and the
disk is unlocked, that specific protection has already served its
purpose and no longer applies to anything happening on the live system.