Exercise 1: Missing Crash Details in kubectl logs — Possible Solution
====================================================================

What's likely happening:

Per the chapter's own tip-box, "a container that already restarted is
showing its NEW logs, not the ones from the crash." Since the pod's
restart policy (Chapter 11, Course 1) automatically restarted the
container after it crashed, `kubectl logs` -- run with no special
flag -- shows the logs of the CURRENTLY RUNNING container instance,
which is the fresh, just-started one. That new instance has only been
running for a few seconds, so naturally there's only a few seconds of
output -- and none of it has anything to do with whatever caused the
PREVIOUS instance to crash, because that previous instance's logs
aren't what's being displayed at all.

What would actually show the crash's cause:

`kubectl logs --previous` (or `kubectl logs -p`). Per the chapter,
this flag "retrieves a crashed container's LAST logs before it
restarted" -- specifically requesting the logs from the PRIOR
container instance (the one that actually crashed), rather than the
current, freshly-restarted one. This is exactly the command needed to
see whatever error message, stack trace, or other output the
container produced right before it died.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly applies the chapter's own explanation of WHY plain
`kubectl logs` shows the wrong thing after a restart (it shows the
CURRENT instance, not the one that crashed) and names the specific
flag the chapter itself calls out as the fix, rather than a vague
"check the logs more carefully" answer.