K8s objects: free-recall review
Free-recall prompts across the K8s objects unit. Answer each in your own words first, then reveal the model answer and compare.
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — reconstructing the mechanism is what makes it stick when you are staring at a broken rollout at 2am.
Reconstruct the unit’s core mechanisms — the reconciliation loop, the workload hierarchy, Service selectors, readiness vs liveness, ConfigMap/Secret propagation, and resource requests vs limits — without looking back at the lesson.
- 01Why does a Deployment self-heal after a node failure but a bare Pod does not?
- 02Describe the Pod to ReplicaSet to Deployment hierarchy — what single job does each layer add?
- 03How does a Service know which pods to route to, and what is the failure mode of overlapping labels?
- 04Contrast readiness, liveness, and startup probes — which one gates traffic, and what is the classic outage?
- 05Why does updating a ConfigMap or Secret not roll the pods that consume it, and how do teams force a refresh?
- 06Explain the difference between resource requests and limits, and why CPU and memory behave differently at the limit.
If you could reconstruct each answer from memory, you hold the unit’s spine: controllers reconcile declared state forever (so Deployments self-heal and bare Pods do not), the hierarchy adds one job per layer (Pod runs, ReplicaSet counts, Deployment rolls), Services bind to pods by label with no ownership awareness, readiness gates traffic while liveness restarts and startup covers slow boots, ConfigMap/Secret changes never auto-roll so you hash them into an annotation, and resources split into throttled CPU and OOMKilled memory. Now when you face a production incident, you will trace it to exactly one of these mechanisms before you start changing anything.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.