Exercise 3: Why the Ticket Was Escalated as a Network Finding — Possible Solution
====================================================================

THE EVIDENCE GATHERED
------------------------------
Per this chapter's worked example: "other services reach fine - not a
general network problem. A ping to the jump host times out. A
traceroute shows the path dying at the exact same hop that always used
to pass through cleanly - genuine network-path evidence, not an
SSH-specific issue at all."

WHY THIS EVIDENCE POINTS SPECIFICALLY AT THE NETWORK LAYER
------------------------------
The checklist worked through in order: scope confirmed other services
work (rules out a general connectivity failure on the engineer's own
side), a ping timeout shows the target isn't responding at the network
level at all, and the traceroute pinpoints exactly where the path
breaks down - a specific hop that used to pass through cleanly. None
of this evidence involves SSH's own protocol at any point - the
failure happens well before an SSH connection could even be attempted,
at the basic network-reachability level.

WHY THIS RULES OUT AN SSH-SPECIFIC EXPLANATION
------------------------------
If the problem were specific to SSH itself (e.g. a misconfigured SSH
daemon, or an authentication issue), the underlying network path would
still be intact - ping and traceroute would both succeed normally, and
the failure would only appear once an actual SSH connection attempt
was made. Instead, the failure shows up at the ping/traceroute level,
before SSH is ever involved at all - evidence that the problem sits
below SSH entirely.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the specific evidence the chapter's worked example gathered
in order, and explains precisely why that evidence (a network-layer
failure visible via ping/traceroute, occurring before SSH is ever
reached) rules out an SSH-specific cause and supports escalating it as
a plain network finding instead.