A public-health dashboard must survive losing a single worker node that hosted one of its Pods. Which design choice most directly improves that resilience?
Select an answer to reveal the explanation.
Short Explanation
One Pod on one node is a single point of failure—spread a few replicas and a node loss is a dent, not an outage. Leaving one lonely Pod with hostNetwork does not buy you high availability.
Full Explanation
A public-health dashboard that must survive losing a single worker node that hosted one of its Pods most directly improves resilience by running multiple replicas so remaining Pods on other nodes can keep serving traffic. Replica count plus spreading through scheduler defaults, anti-affinity, or topology spread means one node loss does not remove all dashboard capacity for clinicians and staff.
Setting restartPolicy to Never so failed Pods are preserved for forensics only reduces recovery rather than improving high availability. Using a single Pod with hostNetwork so the node IP becomes highly available still ties availability to one node and one Pod. Disabling readiness probes so crashed Pods stay in Service endpoints longer harms clients by sending them to bad backends.
Exam caveat: replicas alone help only if Pods can schedule on remaining nodes with capacity. Operational check: run multiple dashboard replicas, verify they land on different nodes when possible, cordon or drain a test node, and confirm the Service still has Ready endpoints. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.