Google ACE Deploying and Implementing a Cloud Solution 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 list pods

  Why it's wrong here

  kubectl does not have a 'list' subcommand; the CLI uses a verb-noun syntax where 'get' retrieves resources, not 'list'. Running 'kubectl list pods' produces an error like 'unknown command "list"' and never contacts the API server, so it cannot return any pods. To list pods you must use the supported verb 'get'.

• ✗

  kubectl describe pods

  Why it's wrong here

  'kubectl describe pods' is a valid command, but it is designed for troubleshooting, not listing. For every pod it prints a lengthy block that includes metadata, labels, annotations, container details, volume mounts, conditions, and event history, making the output verbose and not a simple table. In contrast, 'kubectl get pods' prints a concise, one-line-per-pod summary suitable for listing.

• ✓

  kubectl get pods

  Why this is correct

  'kubectl get pods' is the canonical command to list pods in the current namespace. It queries the Kubernetes API and returns a table with columns such as NAME, READY, STATUS, RESTARTS, and AGE, one row per pod. This is the expected answer because the question asks for a command that lists pods, and 'get' is the standard verb for retrieving resource lists.

• ✗

  kubectl get all

  Why it's wrong here

  'kubectl get all' lists multiple resource types (e.g., pods, services, deployments, replicasets) in one combined view, not only pods. While pods appear in that output, the command is broad and also includes other workload and service resources, so it does not answer the specific request to 'list all pods'. Furthermore, 'get all' does not necessarily include every resource type (such as secrets or configmaps), making it misleading for complete enumeration.

Go deeper

Related to this question