Exercise 2: The CronJob → Job → Pod Three-Layer Relationship — Possible Solution
====================================================================

The relationship, per the chapter, top to bottom:

A CRONJOB creates JOBS, on a recurring schedule defined by
`spec.schedule` (standard cron syntax). Each time the scheduled time
arrives, the CronJob creates a brand NEW Job object -- per the
chapter, "each scheduled run creates a new Job object."

A JOB creates PODS, according to its own `completions` and
`parallelism` settings (per this chapter's own material) -- a Job
might create just one pod for a simple one-off task, or multiple pods
running concurrently (up to the `parallelism` limit) working toward
the total `completions` count required.

A POD is where the actual work happens -- the container(s) defined in
the Job's (and, by extension, the CronJob's) pod template actually
run and execute the task.

So the full chain is: CronJob (schedule) -> Job (one per scheduled
run, tracks completions/parallelism) -> Pod(s) (the actual running
work). This matches the chapter's own explicit statement of the
nesting in the YAML structure itself:
`spec.jobTemplate.spec.template.spec` -- a CronJob spec CONTAINING a
Job spec CONTAINING a pod spec, three layers deep, directly mirroring
the three-layer object relationship.

WHY THIS WORKS AS AN ANSWER
------------------------------
This states the creation direction explicitly at each layer (CronJob
creates Jobs; Jobs create Pods) and connects it directly to the
chapter's own nested YAML structure, showing that the object
relationship and the YAML nesting are two views of the exact same
three-layer hierarchy -- which is exactly the point the chapter's own
tip-box makes about why keeping the layers straight matters for later
troubleshooting.