CKAD Application Observability and Maintenance Practice Question
A DevOps engineer needs to set up resource monitoring for pods in a namespace. Which built-in Kubernetes resource provides CPU and memory metrics out-of-the-box?
⚠ Common exam trap
CNCF often tests the distinction between built-in Kubernetes components and third-party add-ons, so candidates may mistakenly choose Prometheus because it is a popular monitoring tool, but the question specifically asks for a built-in resource that provides metrics out-of-the-box.
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
✓
Metrics Server
The Metrics Server is the built-in Kubernetes resource that collects resource metrics (CPU and memory) from the kubelet on each node via the Summary API and exposes them through the metrics.k8s.io API. It provides these metrics out-of-the-box without requiring any additional configuration or external storage, making it the standard solution for horizontal pod autoscaling and kubectl top commands.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Metrics Server
Why this is correct
Metrics Server is the correct choice because it is a built-in cluster addon that aggregates resource usage metrics (CPU and memory) per node and pod from kubelet's Summary API via the Metrics API. It provides these lightweight, in-memory metrics to `kubectl top` and the Horizontal Pod Autoscaler (HPA) without needing external storage. Being cluster-native and automatically available on most managed Kubernetes distributions, it is the standard zero-configuration tool for basic resource monitoring.
- ✗
Prometheus
Why it's wrong here
Prometheus is incorrect for this context because it is not a built-in Kubernetes component; it requires separate deployment as a full monitoring stack. Its pull-based scraping model gathers metrics from exporters and service endpoints, offering rich time-series data, custom metrics, and alerting. However, it does not natively provide the curated resource metrics API that `kubectl top` uses by default, and it is far heavier than a lightweight addon, making it an overkill or custom monitoring solution rather than the standard built-in one.
- ✗
CoreDNS
Why it's wrong here
CoreDNS is incorrect because its sole purpose is to serve as the cluster's in-cluster DNS resolver, translating service names like `my-service.namespace` into cluster IP addresses. It does not collect or expose any node/pod resource usage data such as CPU or memory. Although it runs as a set of pods and has its own resource consumption, that is not what resource monitoring means here; metrics like request rates or latency are irrelevant to CoreDNS's DNS function.
- ✗
Kubernetes Dashboard
Why it's wrong here
Kubernetes Dashboard is incorrect because it is a web-based user interface for managing and viewing cluster resources, not a metrics provider. It can display resource usage charts only when it is pointed at an external metrics source like the Metrics Server, but it does not actively monitor or supply metrics itself. Therefore, while it may help a DevOps engineer visualize monitoring data, it cannot fulfill the role of a monitoring agent or backend.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD 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 CKAD 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 CKAD exam.