A developer creates a naked Pod for a production API. Why should they prefer a Deployment instead?
Select an answer to reveal the explanation.
Short Explanation
A lone Pod is a house of cards—knock it over and nothing rebuilds it for you. A Deployment is the contractor on retainer: it replaces failed Pods and rolls out new versions on purpose.
Full Explanation
When a developer creates a naked Pod for a production municipal API, prefer a Deployment instead. A Deployment provides self-healing replica management, declarative Pod template updates, rollout history, and controlled replacement strategies that a lone Pod does not. If a bare Pod dies with its node, nobody recreates it automatically; a Deployment restores the desired replica count so citizens keep reaching the API.
The claim that bare Pods cannot attach to a Service even when labels match is false—Endpoints follow label selectors regardless of controller. Only Deployments can mount ConfigMaps is also false; bare Pods mount ConfigMaps and Secrets normally. Naked Pods are not forbidden by the API server in every namespace by default; they are simply a weak choice for long-running production services.
Exam caveat: CKAD emphasizes controllers over unmanaged Pods for anything that must survive node failure and support rollouts. Bare Pods remain fine for quick experiments or one-off debugging, not city production APIs.
Operational check: kubectl delete pod on a bare Pod and observe it stays gone; delete a Deployment-owned Pod and confirm recreation; after image changes, use kubectl rollout status and kubectl rollout history on the Deployment.