An engineer deletes an unmanaged (naked) Pod that served an open-data API. What happens compared with deleting a Pod owned by a Deployment?
Select an answer to reveal the explanation.
Short Explanation
Naked Pods have no parent watching them—delete one and it stays deleted. Put the same workload under a Deployment and the controller shrugs and makes another.
Full Explanation
When an engineer deletes an unmanaged naked Pod that served an open-data API, the naked Pod stays gone; a Deployment-managed Pod would be recreated by its controller. Naked Pods have no ReplicaSet or Deployment owner to reconcile them back into existence. Deployment-managed Pods are owned by a controller that creates replacements to meet desired replicas—critical for understanding why municipal APIs should not run as unprotected Pods in production namespaces.
The naked Pod is not always recreated by kube-scheduler within sixty seconds; the scheduler places Pods, it does not own recreation of deleted naked Pods. Both naked and Deployment Pods are not restored identically by CoreDNS. etcd does not automatically clone any deleted Pod merely because it had a Service label.
Exam caveat: ownership references explain who recreates what after deletes. Operational check: delete a Deployment Pod and watch recreation; delete a naked Pod and confirm it remains absent unless you recreate it manually for the open-data API. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.