KCNA Container Orchestration Practice Question
A team deploys an application as a StatefulSet with three replicas. They need each Pod to have a stable network identity and its own persistent storage that survives Pod rescheduling. Which two features of StatefulSet satisfy these requirements?
⚠ Common exam trap
The trap here is assuming that any Service provides per-Pod DNS names, when only a headless Service does.
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
✓
Stable Pod names and a headless Service for network identity, plus volumeClaimTemplates for per-Pod storage
StatefulSets provide stable ordinal Pod names and, with a headless Service, stable DNS records for each Pod. volumeClaimTemplates dynamically creates a PersistentVolumeClaim per Pod, giving each replica its own persistent storage that follows the Pod across rescheduling. A Deployment with shared storage or a StatefulSet with emptyDir or hostPath does not meet these requirements.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A StatefulSet with a ClusterIP Service and hostPath volumes for each Pod
Why it's wrong here
A ClusterIP Service does not provide per-Pod DNS names; only a headless Service does. hostPath volumes bind data to a specific node's filesystem, so if the Pod is rescheduled to another node, the data is not available. This option fails both stable network identity and portable persistent storage.
- ✗
A Deployment with a headless Service and a shared PersistentVolume mounted by all replicas
Why it's wrong here
A Deployment provides random Pod names and no stable ordinal identity. A shared PersistentVolume mounted by all replicas causes data corruption risk and does not give each Pod its own storage. This combination fails to provide stable per-Pod identity and isolated persistent storage.
- ✗
A StatefulSet with podManagementPolicy: Parallel and an emptyDir volume per Pod
Why it's wrong here
emptyDir volumes are tied to the Pod lifecycle and are deleted when the Pod is removed, so data does not survive rescheduling. podManagementPolicy: Parallel only changes how Pods are created and deleted; it does not affect storage persistence. This option fails the persistent storage requirement.
- ✓
Stable Pod names and a headless Service for network identity, plus volumeClaimTemplates for per-Pod storage
Why this is correct
StatefulSet Pods receive stable ordinal names like app-0, app-1, and app-2, and a headless Service provides stable DNS names such as app-0.app.default.svc.cluster.local. volumeClaimTemplates creates a PersistentVolumeClaim for each Pod, ensuring each replica has dedicated storage that persists across rescheduling. Together these features meet both requirements.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.