A city website Pod managed by a Deployment crashes and disappears from the node. What should restore the desired replica count?
Select an answer to reveal the explanation.
Short Explanation
Controllers are the cleanup crew: if a Deployment says three Pods and one dies, the ReplicaSet spins up another. DNS and Services route traffic—they do not babysit replica counts.
Full Explanation
When a city website Pod managed by a Deployment crashes and disappears from the node, the Deployment's ReplicaSet controller creates a replacement Pod to match desired replicas. That self-healing path is a core reason municipal sites run under Deployments rather than naked Pods: the controller continuously reconciles observed Pods to the desired count, restoring capacity after crashes without manual recreation.
CoreDNS will not recreate the Pod when the Service name is queried again—DNS resolves Services; it does not own replica controllers. The etcd compaction job does not automatically re-create crashed application Pods; compaction is storage maintenance. A ClusterIP Service alone will not spawn a replacement Pod for each failed endpoint; Services select endpoints, they do not create workload Pods.
Exam caveat: controllers heal running failures that still schedule; Pending due to lack of capacity is a different class of problem. Operational check: after a crash, kubectl get pods,rs for the website Deployment and confirm a new Pod appears and becomes Ready behind the Service. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.