KCNA Cloud Native Observability Practice Question
A developer wants to monitor the health of a Kubernetes deployment by checking if the number of ready replicas matches the desired replicas. Which metric from kube-state-metrics should they query?
⚠ Common exam trap
The trap here is that candidates might confuse metrics that show pod state (like `kube_pod_container_status_running`) with Deployment-level readiness, not realizing that a pod can be running but not ready, and that the correct metric must reflect the Deployment's own status field.
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
✓
kube_deployment_status_replicas_ready
`kube_deployment_status_replicas_ready` directly exposes the number of ready replicas for a Deployment, which can be compared against `kube_deployment_spec_replicas` to determine if the desired state matches the actual healthy state. This metric is emitted by kube-state-metrics, which generates Prometheus-compatible metrics from Kubernetes API objects, making it the standard choice for monitoring Deployment health.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
kube_deployment_status_replicas_ready
Why this is correct
`kube_deployment_status_replicas_ready` exposes the count of ready replicas directly from the Deployment's status, satisfying the requirement to compare ready against desired replicas. Pairing it with `kube_deployment_spec_replicas` gives the desired count, enabling an alert when readiness diverges from the specification.
- ✗
kube_deployment_spec_replicas
Why it's wrong here
kube_deployment_spec_replicas gives only the desired replica count, not the ready count, so no comparison is possible. It is tempting because it is deployment-scoped and mentions replicas. The ready counterpart, kube_deployment_status_replicas_ready, supplies the actual figure needed to detect a shortfall.
- ✗
kube_node_status_condition
Why it's wrong here
kube_node_status_condition reports node-level conditions such as Ready, MemoryPressure or DiskPressure, not deployment replica counts, so it cannot compare ready against desired replicas. It is tempting because node health monitoring is a genuine kube-state-metrics use case, and it would be correct when diagnosing whether a node hosting pods is unhealthy.
- ✗
kube_pod_container_status_running
Why it's wrong here
kube_pod_container_status_running counts running containers, not deployment replica readiness, so it cannot compare ready against desired replicas. It is tempting because it sounds like a health indicator. kube_deployment_status_replicas_ready reports ready replicas, which is compared with the spec value.
Go deeper
Related to this question
Learn chapter
Observability: Monitoring, Logging, and Tracing
Key term
ReplicaSet and Replication
A ReplicaSet ensures a specified number of identical pod instances are running at all times in Kubernetes, using replication to maintain availability and stability.
Key term
Kubernetes API Primitives
Kubernetes API Primitives are the basic building blocks that the Kubernetes API uses to represent and manage the state of a cluster, such as Pods, Services, Deployments, and Namespaces.
About these practice questions
One of 930 original KCNA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.