Google ACE Practice Question: A deployment pipeline runs `kubectl logs` to…

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 api-pod --terminated

  Why it's wrong here

  `--terminated` is not a recognized flag for `kubectl logs`; invoking it causes kubectl to fail with an invalid flag error. The correct way to fetch logs from a container that previously ran and then stopped is `--previous` (or shorthand `-p`), which targets the last terminated container instance. Other valid flags like `--tail`, `--since`, and `--all-containers` do not replace the need to specify the prior instance.

• ✓

  kubectl logs api-pod --previous

  Why this is correct

  The `--previous` flag (or `-p`) instructs kubectl to fetch the log output of the last, now-terminated container instance in the pod, rather than the current (possibly restarting) one. This is precisely the right tool when a container crashes before it can be readied, because its startup error output is preserved in the terminated instance's logs. For pods with multiple containers, combine it with `-c <container-name>` to isolate the right container, and it works for both regular and init containers.

• ✗

  kubectl logs api-pod --all-containers --since-crash

  Why it's wrong here

  `--since-crash` is not a valid kubectl logs flag — kubectl offers time-based filtering via `--since` or `--since-time` (e.g., `--since=10m`), not a crash-relative window. Additionally, `--all-containers` explicitly requests logs from every current container in the pod, which would miss the terminated instance entirely unless `--previous` is also used. Therefore this command is doubly incorrect: it fails validation and, even if it ran, wouldn't show the crashed container's prior logs.

• ✗

  kubectl describe pod api-pod | grep -A 50 'Last State'

  Why it's wrong here

  The `kubectl describe pod` command surfaces pod metadata, status conditions, and the container state machine — including 'Last State: Terminated' with a reason, exit code, and timestamps. However, it never exposes the captured stdout/stderr from the crashed container; those log lines live in the kubelet-managed log file and are only retrievable via `kubectl logs`. Using `grep -A 50` just widens that status snapshot, so it cannot tell you what the application printed before failing.

Go deeper

Related to this question