Google ACE Practice Question: Check the CPU and memory utilization of all pods…

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 -n production`

  Why it's wrong here

  kubectl describe pods -n production prints a detailed manifest of each pod, including labels, annotations, container image, restart policy, and recent lifecycle events. It also reports resource requests and limits as configured, but it does not query the metrics-server for live CPU or memory consumption. The status section shows phase and conditions, not utilization numbers, so this command cannot answer a scheduling or capacity question about current pod resource pressure.

• ✓

  `kubectl top pods -n production`

  Why this is correct

  kubectl top pods -n production is the correct way to inspect actual resource consumption because it directly queries the metrics-server, which aggregates per-pod CPU and memory usage from each node's kubelet and cAdvisor. The command renders a table with columns for CPU (cores) and memory (MiB) along with the container breakdown, filtered to the production namespace. It provides a near-real-time snapshot of utilization, not just configured requests or limits, and is the standard CLI tool for verifying which pods are consuming the most resources.

• ✗

  `kubectl get pods -n production -o wide`

  Why it's wrong here

  kubectl get pods -n production -o wide extends the basic pod listing with extra columns: the node name, pod IP, and the host IP, and otherwise retains the same READY/STATUS/RESTARTS/AGE data. The -o wide output does not include any column for CPU, memory, or network utilization; it is purely a snapshot of scheduling and lifecycle state. To view historical or real-time resource metrics you must use a dedicated metrics command, not a get formatter.

• ✗

  `kubectl logs -n production --all-pods`

  Why it's wrong here

  kubectl logs -n production --all-pods captures the stdout/stderr output written by application processes inside container, which is essential for debugging application errors but unrelated to resource accounting. Logs contain application event traces, stack traces, or request logs, never kernel-level CPU time or memory page statistics. Even if the --all-pods flag were valid (it is not; you would use a selector or --all-containers), the command still retrieves log streams, not the metrics-server data needed for live utilization.

Go deeper

Related to this question