# Knowledge Check: Choosing the Right Workload Primitive

---

**1. You need to run a database migration script exactly once when a new version deploys. Which
primitive fits, and why not a Deployment?**

*Answer:* A Job. A Deployment expects its Pods to run forever and replaces any that exit; a
migration script is supposed to exit successfully when done, which a Deployment would treat as
a failure to "fix" by restarting it — the wrong behavior for a task that's supposed to finish.

---

**2. A CronJob scheduled for "every 5 minutes" keeps creating Jobs that fail immediately due to
a bad image tag. What actually happens over the next hour if nobody notices?**

*Answer:* A new failing Job (and its Pod) gets created roughly every 5 minutes, accumulating
failed Job/Pod objects and consuming cluster resources — nothing stops this automatically. This
is exactly the kind of slow, easy-to-miss resource exhaustion a real on-call engineer should
watch for.

---

**3. True or false: a DaemonSet's Pod count scales with a `replicas` field, the same as a
Deployment.**

*Answer:* False. A DaemonSet has no `replicas` field — its Pod count is implicitly "one per
matching node," and it grows or shrinks automatically as nodes join or leave the cluster.

---

**4. You need a log-shipping agent that must run on every node, including any new node added
later. Which primitive, and what would go wrong if you used a Deployment with a high replica
count instead?**

*Answer:* A DaemonSet. A Deployment's replicas are placed by the scheduler wherever it decides
is best — nothing guarantees one per node, and a newly-added node wouldn't automatically get a
copy the way a DaemonSet guarantees.

## Instructor Notes

**Facilitation:** Question 2 is worth emphasizing — it's a genuinely realistic "how does a
cluster quietly get into trouble" scenario, not just trivia.

**Approximate timing:** 5 minutes.