KCNA Cloud Native Observability Practice Question
A team runs a Kubernetes cluster with Prometheus scraping application metrics. They want Prometheus to automatically discover new pods and scrape their metrics endpoints as pods are created and destroyed. Which Kubernetes resource should they configure Prometheus to use for this dynamic discovery?
⚠ Common exam trap
The trap here is assuming that any Kubernetes resource can be watched by Prometheus for discovery, when only specific service discovery mechanisms like kubernetes_sd_configs are designed for that purpose.
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
✓
Kubernetes API server via Prometheus's kubernetes_sd_configs
Prometheus can dynamically discover targets in Kubernetes by integrating with the Kubernetes API server through kubernetes_sd_configs. This allows it to watch for pod creation and deletion events and automatically add or remove scrape targets. Static configurations or ConfigMaps require manual intervention and do not adapt to the dynamic nature of Kubernetes workloads, so they are unsuitable for this use case.
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 kubelet's embedded cAdvisor endpoint on each node
Why it's wrong here
The kubelet's cAdvisor endpoint provides container-level resource metrics, but it does not discover application-specific metrics endpoints. While useful for node and container metrics, it does not solve the problem of discovering custom application metrics. The team needs to discover pods exposing application metrics, not just node-level telemetry.
- ✗
A static list of pod IPs in the Prometheus configuration file
Why it's wrong here
Maintaining a static list of pod IPs is impractical in Kubernetes because pod IPs change frequently as pods are rescheduled. This approach would require manual updates and would not scale. Prometheus's Kubernetes service discovery is designed to handle dynamic environments automatically, so a static list defeats the purpose of running in Kubernetes.
- ✓
Kubernetes API server via Prometheus's kubernetes_sd_configs
Why this is correct
Prometheus's kubernetes_sd_configs allows it to query the Kubernetes API server to discover targets such as pods, services, and endpoints. This enables automatic scraping of new pods as they appear, without manual configuration. It is the standard method for dynamic service discovery in Kubernetes environments, making it the correct choice for this scenario.
- ✗
A ConfigMap that lists all pod names and namespaces
Why it's wrong here
A ConfigMap containing pod names still requires manual updates whenever pods change, which is not dynamic. Prometheus cannot automatically watch a ConfigMap for changes to trigger scraping; it relies on service discovery mechanisms. This approach would lead to stale targets and missed metrics, failing to meet the requirement for automatic discovery.
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.