Google ACE Practice Question: A team's GKE application is running out of memory…

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 events --field-selector=reason=OOMKilling

  Why it's wrong here

  `kubectl get events --field-selector=reason=OOMKilling` displays only past OOMKill events, which are ephemeral and typically retained for only about an hour, so earlier signs of the leak may already be gone. Even when events are present, they merely indicate that the kernel killed a process due to memory pressure, without showing the container's current live memory consumption or its growth trend. This command confirms the symptom of OOM kills but lacks the per-container, real-time utilization data needed to identify which container is actually leaking.

• ✓

  kubectl top pods --containers -n [NAMESPACE]

  Why this is correct

  `kubectl top pods --containers -n [NAMESPACE]` is the correct command because it queries the metrics-server API to show real-time CPU and memory utilization per individual container inside each Pod. This granularity is essential in GKE because a Pod often runs sidecars alongside the main application, and aggregating metrics at the Pod level can hide which container is consuming excessive memory. By comparing each container's usage to its requests and limits, you can pinpoint the leaking container and confirm the diagnosis before taking any remediation action.

• ✗

  kubectl delete pod [POD_NAME] -- force=true to clear the memory leak

  Why it's wrong here

  Force-deleting the Pod with `kubectl delete pod --force=true` immediately terminates the container and recreates it from the same manifest, which only provides temporary relief. This action does not identify which container in the Pod is leaking memory or whether the leak is caused by the application, a sidecar, or a runtime issue, so the OOMKill will recur. Moreover, `--force=true` bypasses the graceful termination grace period, potentially leaving orphaned volumes, IP addresses, or other resources inconsistent, making it a risky operational move rather than a diagnostic step.

• ✗

  gcloud container clusters describe [CLUSTER] --memory-usage

  Why it's wrong here

  `gcloud container clusters describe [CLUSTER] --memory-usage` is not a valid gcloud command because the `describe` subcommand has no `--memory-usage` flag; it returns static cluster configuration such as node pools, network settings, and control plane details, not runtime metrics. Even if you attempted to retrieve memory information from cluster-level monitoring, it would be far too coarse to distinguish which container in which Pod is leaking. Proper diagnostics require `kubectl top` or Cloud Monitoring per-container metrics, not cluster configuration outputs.

Go deeper

Related to this question