KCNA Kubernetes Fundamentals Practice Question
A platform team runs a StatefulSet named `db` with three replicas in the `prod` namespace. An operator must connect directly to the third Pod's network identity for a manual data repair. Which stable DNS name resolves to that specific Pod?
⚠ Common exam trap
The trap here is assuming StatefulSet ordinals start at 1, which leads to picking the -3 name instead of the correct zero-based -2 record.
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
✓
db-2.db.prod.svc.cluster.local
StatefulSet members are addressed by stable, ordinal-based hostnames backed by a headless Service. A three-replica set produces ordinals 0 through 2, so the third Pod is db-2 under the Service and namespace. That per-Pod DNS record survives rescheduling, giving operators a dependable target for direct maintenance work.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
db-2.db.prod.svc.cluster.local
Why this is correct
StatefulSet Pods receive stable ordinal hostnames derived from the Pod name and the governing Service. With a headless Service named `db`, the third Pod (ordinal 2) is reachable at db-2.db.prod.svc.cluster.local. This identity persists across rescheduling, which is exactly why StatefulSets suit databases and other workloads needing stable per-Pod addressing.
- ✗
db.db.prod.svc.cluster.local
Why it's wrong here
That name resolves to the Service itself, not to an individual Pod. For a normal ClusterIP Service it load-balances across all ready endpoints; even with a headless Service it returns all Pod IPs rather than one member. It cannot single out the third replica, so it fails the operator's requirement to reach a specific Pod identity.
- ✗
db-3.db.prod.svc.cluster.local
Why it's wrong here
StatefulSet ordinals are zero-based, so a three-replica set contains ordinals 0, 1, and 2. The name ending in -3 would correspond to a fourth replica that does not exist, so it will not resolve to any running Pod. Choosing it reflects a common off-by-one error when reasoning about StatefulSet naming.
- ✗
db.prod.pod.cluster.local
Why it's wrong here
There is no per-Pod DNS zone named `pod` under the namespace in standard cluster DNS; that pattern is not how Kubernetes publishes Pod records. Pods get addressable names through a headless Service, not through a generic pod subdomain. This option invents a naming scheme that the cluster DNS will not answer.
Visual reference
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.