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 logs my-pod

  Why this is correct

  The `kubectl logs my-pod` command retrieves the logs of the primary container running inside the specified pod by reading the container's stdout/stderr streams. This is the direct, native Kubernetes approach for accessing application log output, and if the pod has multiple containers, you must append `-c <container>` to select a specific one. It does not require shell access or any extra tooling, making it the correct command for viewing logs.

• ✗

  kubectl exec my-pod -- logs

  Why it's wrong here

  This command attempts to execute a program named `logs` inside the container using `kubectl exec`, which is meant for running arbitrary scripts or binaries like `sh` for interactive troubleshooting. The word 'logs' is not a standard Linux command or container entrypoint, so the execution would typically fail with 'executable file not found' unless the application image happens to contain a rare executable named `logs`. Even if it existed, it would not necessarily output Kubernetes-managed logs, as `kubectl exec` bypasses the log-retrieval API and directly spawns a process in the container's filesystem namespace.

• ✗

  kubectl get pod my-pod

  Why it's wrong here

  The `kubectl get pod my-pod` command outputs the pod's Kubernetes object metadata, including its name, namespace, phase, and IP address, in either table, YAML, or JSON format. It does not fetch runtime log output from the container; it shows the pod's desired state and current status as tracked by the control plane. You might see a `RESTARTS` count or container states, but never the application's stdout/stderr logs, so it cannot fulfill the task of viewing logs.

• ✗

  kubectl describe pod my-pod

  Why it's wrong here

  While `kubectl describe pod my-pod` provides a rich summary containing the pod's recent lifecycle events, container image names, mount points, and any error messages from the kubelet, it does not expose the container's actual log lines. It aggregates information from the pod's status and events, which may include a short tail of the last terminated container's logs if a `lastState` is present, but it is not a substitute for streaming or reading the full logs from the container runtime. The describe output focuses on configuration and state, not on the output generated by the application itself.

Go deeper

Related to this question