Exercise 1: TDE Doesn't Cover Every Backup Method — Possible Solution
====================================================================

WHY THIS IS STILL A SERIOUS RISK: TDE encrypts the data files and
backups produced BY THE DATABASE ENGINE ITSELF as part of its own
built-in backup mechanism. A mysqldump, however, is a completely
separate tool that connects to the database, reads out the data
through normal queries, and writes it back out as plain-text SQL
statements by default — it has no awareness of TDE at all and produces
its own independent output file, unencrypted, regardless of whatever
encryption settings the live database itself uses.

In practice, this means the team could have a genuinely well-encrypted
live database (via TDE) sitting right next to a nightly mysqldump.sql
file that contains every row of the same data in fully readable plain
text — the exact same sensitive data, protected by TDE in one location
and completely unprotected in another, simply because a different tool
produced it.

THE FIX: encrypt the dump itself, independently of TDE — for example,
piping mysqldump's output directly into an encryption tool so the
plain-text version never touches disk unencrypted at all:

mysqldump shop_db | gpg --encrypt --recipient backups@example.com > backup.sql.gpg

This treats the dump file as its own thing requiring its own
encryption, rather than assuming TDE's protection extends to a tool
that TDE was never designed to cover.