Exercise 3: Why "SQLi-Clean" Isn't the Same as "Database Secure" — Possible Solution
====================================================================

These are two different claims because they test two entirely
different threat models, exactly as Chapter 1 established at the very
start of this course. A SQL injection review examines whether
UNTRUSTED INPUT REACHING THE APPLICATION can be smuggled into a query
as code — it is, by design, a test of the APPLICATION layer's own
defenses (parameterized queries, input handling).

It says NOTHING about:

- whether database accounts are individually attributable or shared
  (Ch.2), or scoped to least privilege rather than granted everything
  (Ch.3)
- whether the database's network port is reachable from somewhere it
  shouldn't be (Ch.4)
- whether data is actually encrypted at rest and in transit, with
  connections genuinely verifying certificates (Ch.5-6)
- whether sensitive access is logged anywhere tamper-resistant (Ch.7)
- whether backups are encrypted, isolated, and have ever actually been
  restored successfully (Ch.8)
- whether the database software itself has default accounts still
  present, unused risky features enabled, or unpatched known CVEs
  (Ch.9)

A clean SQLi review can coexist with ALL of these being wrong
simultaneously, because none of them are things a SQL injection test
was ever designed to check.

WHAT WOULD NEED TO BE VERIFIED ADDITIONALLY: essentially this
chapter's own six-step test plan (Exercise 1) — accounts, network
exposure, encryption, auditing, backups, and hardening — each
independently confirmed, not assumed. Only once BOTH the application-
layer review (SQLi-clean) AND this course's infrastructure-layer
verification pass does "our database is secure" become a claim with
real evidence behind it, rather than one half of the picture mistaken
for the whole.