A municipal app is 'not healthy': some Pods never leave Pending while others CrashLoopBackOff. What should the admin conclude about self-healing controllers?
Select an answer to reveal the explanation.
Short Explanation
Self-healing replaces Pods that die after they were placed—it cannot invent CPU or untaint a node for something stuck Pending. Pending and CrashLoop are different problems; treat them differently.
Full Explanation
When a municipal app is not healthy with some Pods never leaving Pending while others CrashLoopBackOff, the admin should conclude that controllers can recreate failed running Pods, but they cannot fix Pods that never schedule successfully. ReplicaSet and Deployment self-healing replaces crashed Pods that had scheduled, but Pending usually means scheduling constraints, resource shortage, taints, or PVC issues—problems the replica controller cannot invent nodes or capacity to solve.
ReplicaSets do not automatically add Nodes whenever any Pod is Pending. CrashLoopBackOff and Pending are not identical failures fixed by the same readiness probe. Pending Pods are not healed by raising the Deployment's revision history limit.
Exam caveat: split troubleshooting—logs and events for CrashLoopBackOff versus describe and scheduler messages for Pending. Operational check: kubectl describe pending Pods for FailedScheduling reasons, fix capacity, selectors, taints, or PVCs, and separately fix crash causes for looping Pods. 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.