Exercise 2: Two Different Root Causes for a Pending Pod, and How describe Distinguishes Them — Possible Solution
====================================================================

Two genuinely different root causes this chapter names for a Pending
pod:

1. INSUFFICIENT CLUSTER RESOURCE CAPACITY. Per the chapter, "insufficient
   cluster resource capacity for the pod's own requests (Chapter 10)"
   -- the pod's CPU/memory requests are larger than what any current
   node has available, so the scheduler has nowhere to place it.

2. AN UNSATISFIABLE PERSISTENTVOLUMECLAIM. Per the chapter, "a
   PersistentVolumeClaim (Chapter 8) that can't be bound to any
   available PersistentVolume" -- the pod references storage that
   simply isn't available yet (no matching PV, or the StorageClass
   can't dynamically provision one for some reason), so the pod can't
   start even if plenty of CPU/memory capacity exists elsewhere.

(A third valid cause the chapter also names: a node selector/affinity
rule that no current node satisfies.)

How `kubectl describe pod` helps distinguish between them:

Per the chapter, "kubectl describe pod again shows the SPECIFIC
scheduling failure reason" -- rather than just reporting the generic
"Pending" status, `describe` surfaces the scheduler's own explanation
in its Events section, phrased specifically enough to tell these
cases apart directly:

- For the RESOURCE CAPACITY case, the Events would typically show a
  message along the lines of "Insufficient cpu" or "Insufficient
  memory," explicitly naming which resource type couldn't be
  satisfied on any candidate node.

- For the PVC-BINDING case, the Events would instead show a message
  related to volume binding/provisioning failure -- something
  referencing the PVC by name and explaining why it couldn't be bound,
  which is a completely different kind of message from a resource-
  capacity complaint.

Because these two failure modes produce genuinely DIFFERENT, specific
messages in `describe`'s Events output, reading that output directly
-- rather than guessing based on the generic "Pending" status alone --
is what actually distinguishes which of the two (or more) possible
causes is the real one in a given case.

WHY THIS WORKS AS AN ANSWER
------------------------------
This names two of the chapter's own explicitly listed causes for
Pending pods and explains that `describe`'s value specifically comes
from surfacing DIFFERENT, cause-specific messages for each -- directly
matching the chapter's own "shows the SPECIFIC scheduling failure
reason" claim, rather than treating `describe` as generically useful
without explaining what it actually reveals.