KCNA Cloud Native Architecture Practice Question
Exhibit
Refer to the exhibit.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
app: frontend
template:
metadata:
labels:
app: frontend
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 3
periodSeconds: 5
```The exhibit shows a Deployment manifest for a frontend service. After deployment, the pods are running but the service reports that no endpoints are available. What is the most likely cause?
⚠ Common exam trap
CNCF often tests the distinction between readiness and liveness probes: candidates confuse a failing liveness probe (which restarts pods) with a failing readiness probe (which removes traffic but keeps the pod running).
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
✓
The readiness probe is checking /ready which is not returning a 200 OK response.
The service reports no endpoints because the readiness probe is failing. A readiness probe determines whether a pod should receive traffic; if it does not return a 200 OK on the configured path (/ready), the pod is removed from the service’s endpoint list. Since the pods are running (liveness probe passes), the most likely cause is that the /ready endpoint is not serving a successful response.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The readiness probe periodSeconds is too short, causing the probe to overload the container.
Why it's wrong here
A short readiness periodSeconds merely probes more frequently; it does not overload the container or strip it from endpoints, and the pods are reported running. It is tempting when tuning probe timing, but the real cause is a readiness probe that never succeeds, leaving the pod NotReady.
- ✓
The readiness probe is checking /ready which is not returning a 200 OK response.
Why this is correct
Kubernetes only adds a pod to a Service's Endpoints when its readiness probe succeeds. If /ready returns anything other than 200 OK, the pod stays NotReady, so the Service has no endpoints despite the containers running.
- ✗
The container image nginx:1.21 does not have the /healthz endpoint.
Why it's wrong here
Missing /healthz probes would cause restarts, not zero endpoints; endpoints come from the Service selector matching pod labels and targetPort. It is tempting because readiness probes do gate endpoint membership, but only when configured — the manifest's selector mismatch is the actual cause here.
- ✗
The liveness probe is failing, causing the pod to be restarted.
Why it's wrong here
A failing liveness probe restarts the container; it does not remove the pod from Service endpoints, so it cannot explain the empty endpoint list. It is tempting because probe failures are common, but readiness probes, not liveness probes, govern endpoint membership, and the stem shows pods still running.
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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.