Exercise 3: A "Missing" Log at Its Default Path — Possible Solution
====================================================================

REASON ONE: THE APPLICATION IS CONFIGURED TO LOG SOMEWHERE ELSE
------------------------------
Per this chapter, "most services let you set a custom log path - the
config file is the actual source of truth, not the convention." The
default path is only where the log lives if nobody has changed the
configuration; if a custom path was set, the log is being written
there instead, not at the default location at all.

REASON TWO: THE FILE WAS ALREADY ROTATED
------------------------------
Per this chapter, "the file you're looking for might have already been
rotated - renamed to access.log.1, or compressed to access.log.2.gz."
The log still exists and still contains real data, just under a
different filename than the one being searched for, as a normal
consequence of log rotation (covered in full in Chapter 9).

(A third valid reason from this chapter: a systemd unit file's
StandardOutput/StandardError directives can redirect a service's
output somewhere other than the journal or the expected default path
entirely.)

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly names two genuinely different reasons a log might not be
at its default path - a custom configured path, and rotation to a
renamed/compressed file - both directly drawn from this chapter's own
"When the Log Isn't Where You Expect" section, rather than assuming
the log simply doesn't exist.