CKA Troubleshooting Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  kubectl describe pods

  Why it's wrong here

  kubectl describe pods retrieves a wealth of static pod metadata from the API server—labels, annotations, container images, restart counts, status conditions, and event history—but it never queries the kubelet/cAdvisor metrics endpoint. Any resource numbers displayed are just the configured requests and limits from the pod spec, not live CPU or memory utilization. As a result, it cannot answer a question about current resource usage.

• ✗

  kubectl logs pods

  Why it's wrong here

  kubectl logs pods simply follows or dumps the stdout/stderr streams captured by the container runtime (containerd or CRI-O) for application troubleshooting. Log lines are unstructured text and contain no fixed schema for CPU or memory readings, so the command cannot aggregate or display resource consumption. It is invaluable for debugging a crashing pod, but it is not a metrics tool.

• ✓

  kubectl top pods

  Why this is correct

  kubectl top pods is the direct client for the metrics.k8s.io API, which is normally served by metrics-server after it scrapes each node's Summary API from kubelet/cAdvisor. The command shows per-pod CPU usage in cores or millicores and memory usage in MiB, making it the standard way to view live resource consumption from the command line. This is precisely the resource-usage view the user is asking for.

• ✗

  kubectl get pods -o wide

  Why it's wrong here

  kubectl get pods -o wide extends the default table with extra information such as the pod IP and the worker node on which the pod is scheduled, but it still only renders fields already stored in the pod object in etcd. It does not contact the metrics API or kubelet at all, so no CPU or memory values are added. It is useful for network or scheduling debugging, not for utilization.

Go deeper

Related to this question