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 get pod --namespace=production -o wide

  Why it's wrong here

  kubectl get pod --namespace=production -o wide displays a wide table of pod metadata, including the pod's IP address, nominated node, and labels, but it never queries the kubelet for runtime metrics such as resident memory. This command only reports static scheduling and spec information, so it cannot satisfy the requirement to check memory usage. The -o wide flag merely changes the output columns, not the underlying data source.

• ✗

  kubectl describe pod --namespace=production

  Why it's wrong here

  kubectl describe pod --namespace=production shows a detailed object manifest-style summary, including container images, volumes, events, and resource requests/limits if they are declared in the spec. However, that 'requests/limits' section is a declaration of what the pod is allowed to use, not a live measurement of actual memory consumption. The describe command does not connect to cAdvisor or the metrics-server, so it gives a static spec view and cannot answer the question of current memory usage.

• ✗

  kubectl top node

  Why it's wrong here

  kubectl top node outputs the CPU and memory utilization aggregated at the node level, showing the total usage across all pods running on that particular worker, but it does not present a per-pod breakdown. If you run it against a production cluster, you cannot determine which specific pod is consuming memory; the data is summed and only displays node-scoped totals, missing the namespace/name granularity requested. This is a different scope problem from per-pod commands and therefore does not fulfill the requirement.

• ✓

  kubectl top pod --namespace=production

  Why this is correct

  kubectl top pod --namespace=production is the correct kubectl command because it directly queries the metrics-server, which receives its data from kubelet cAdvisor, and returns the current CPU and memory usage for every pod in the production namespace. This is the only option among the four that actually measures live runtime memory consumption per pod, exactly satisfying the requirement. It produces a table with columns for NAME, CPU(cores), and MEMORY(bytes); note that without an explicit --namespace flag, kubectl top pod would default to the current namespace, so specifying production is essential.

Go deeper

Related to this question