Exercise 1: What CrashLoopBackOff Actually Means, and the First Command — Possible Solution
====================================================================

What it actually means mechanically:

Per the chapter, "this ISN'T a special error state, it's the NORMAL,
EXPECTED behavior of Chapter 11's own restart policy responding to a
container that keeps failing." Tying directly to `k8s1-11`'s
restart policy material: the container starts, exits (crashes, or
exits with a code the restart policy treats as a failure), and
Kubernetes automatically restarts it per the pod's configured
`restartPolicy` (typically `Always` for a long-running Deployment
pod). Critically, per the chapter, each successive restart attempt is
separated by an INCREASING BACKOFF DELAY -- the container isn't
restarted instantly every time; the wait between attempts grows
longer with each repeated failure, which is exactly where the name
"CrashLoopBackOff" comes from: it's crashing, in a loop, with a
backoff delay.

This is Kubernetes doing EXACTLY what it's supposed to do -- Chapter
11's restart mechanism is functioning correctly. The status itself
isn't telling you Kubernetes is broken; it's telling you the
CONTAINER keeps failing, and Kubernetes keeps faithfully trying to
restart it per policy.

What the first command should be:

`kubectl logs --previous` (or `-p`). Per the chapter, "the root cause
is almost always in the APPLICATION itself, not Kubernetes... check
kubectl logs --previous (Chapter 7) first." Since the container has
already been restarted at least once (CrashLoopBackOff implies
repeated failures), a plain `kubectl logs` would show the CURRENT,
freshly-started instance's brief output rather than the actual error
that caused the crash -- exactly the trap Chapter 7 covered. `--previous`
retrieves the logs from the instance that actually crashed, which is
where the real explanation (a config error, a missing Secret/
ConfigMap value, a failed dependency check, per this chapter's own
listed causes) will actually be visible.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the MECHANISM behind the status name itself (restart
policy + increasing backoff delay = "CrashLoopBackOff") directly from
Chapter 11's material, and then names the specific command Chapter 7
established as the correct first move -- `--previous` -- rather than
plain `kubectl logs`, which this chapter explicitly warns would show
the wrong, unhelpful output.