KCNA Container Orchestration Practice Question
A Kubernetes cluster runs a critical application that must be highly available. The application consists of three pods managed by a Deployment. To ensure the application remains accessible during a node failure, which configuration should be applied?
⚠ Common exam trap
Many exam-takers confuse preferred anti-affinity or topology spread with ScheduleAnyway as sufficient for high availability; only hard requirements guarantee spreading.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Set podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution to enforce pods on different nodes.
To guarantee that pods are spread across different nodes, a hard pod anti-affinity rule is needed. requiredDuringSchedulingIgnoredDuringExecution enforces that no two pods with the specified labels can be on the same node. This ensures that a single node failure does not take down all replicas. Soft anti-affinity, topology spread with ScheduleAnyway, and node affinity do not provide the same hard guarantee.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Set podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution to enforce pods on different nodes.
Why this is correct
requiredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a hard rule. The scheduler will not place two pods with the matching labels on the same node. This ensures that the three pods are spread across at least three nodes, so a single node failure only affects one pod, maintaining availability. This is the strongest guarantee for spreading pods.
- ✗
Set nodeAffinity to require pods to run on specific nodes.
Why it's wrong here
nodeAffinity selects nodes based on labels, but it does not prevent multiple pods from being scheduled on the same node. Even with required node affinity, if three nodes share the same label, all pods could land on one node. This does not ensure distribution across nodes, so it fails to provide high availability.
- ✗
Set topologySpreadConstraints with maxSkew: 1 and whenUnsatisfiable: ScheduleAnyway.
Why it's wrong here
topologySpreadConstraints with maxSkew: 1 attempts to balance pods across topology domains, but whenUnsatisfiable: ScheduleAnyway means the scheduler will still place pods even if the skew cannot be satisfied. This does not guarantee that pods are on different nodes; they could be co-located if resources are tight, reducing high availability.
- ✗
Set podAntiAffinity to prefer scheduling pods on different nodes.
Why it's wrong here
preferredDuringSchedulingIgnoredDuringExecution is a soft requirement; the scheduler may still place multiple pods on the same node if resources are constrained. This does not guarantee high availability during a node failure. A hard requirement or topologySpreadConstraints would be more effective to enforce distribution across nodes.
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the KCNA exam.