Exercise 1: Why Ticket 1 Wasn't a Password Problem — Possible Solution
====================================================================

WHY IT WASN'T A PASSWORD PROBLEM
------------------------------
Per this chapter, the app's own log showed "[WARN] Login rejected:
account status = inactive (user_id 118)" - the account itself had been
marked inactive, so the login was being rejected regardless of whether
the correct password was entered. The user's password was never
actually the issue; the account they were logging into had been
disabled by a separate process.

WHICH LAYER CONTAINED THE REAL CAUSE
------------------------------
Per this chapter, this was found at "Layer 3 (application auth)" -
Chapter 5's third layer, application-level authentication. Layers 1
(network) and 2 (blocked before the app - fail2ban) were both checked
and ruled out first, following the outside-in order Chapter 5
established, before Layer 3's own application log revealed the actual
account-status cause.

WHAT ACTUALLY CAUSED THE ACCOUNT TO BE MARKED INACTIVE
------------------------------
Per this chapter, "an overnight account-cleanup job... incorrectly
flagged this active admin account as inactive during a routine sweep"
- a separate automated process, not the user's own login attempt at
all, caused the underlying condition Layer 3 revealed.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains why the password was never actually the problem
(the account itself was disabled), correctly identifies Layer 3 as
where this was found, and correctly names the overnight cleanup job as
the actual root cause behind that layer's own finding.