CKA Troubleshooting 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 -l app=api --tail=50

  Why it's wrong here

  Using -l app=api targets every Pod that carries that label instead of a single named Pod. When multiple replicas match, kubectl logs cannot produce a clean linear stream for one particular Pod; it will try to aggregate or fetch logs from all matching Pods, and depending on the client/server version it may even return an error because a selector-based invocation must still resolve to exactly one Pod for some flags. To inspect one specific Pod, you must supply its name as the positional argument, as in the correct command, not a label selector.

• ✗

  kubectl logs api-pod --tail=50

  Why it's wrong here

  Omitting -c is only valid when the targeted Pod has exactly one container. If api-pod actually runs multiple containers, Kubernetes rejects the request with an error such as 'a container name must be specified' and returns no log output. Even if the Pod happens to have only one container, this command silently inherits that default but fails to match the explicit container selection in the correct syntax used by the desired Pod, making it a brittle and incomplete solution for the stated task.

• ✓

  kubectl logs api-pod -c api-container --tail=50

  Why this is correct

  This is correct because kubectl logs expects the Pod name as the first positional argument, then -c names a specific container within that Pod, and --tail=50 limits the output to the last 50 lines. The flag syntax --tail=N is valid; it tells the kubelet to read only the requested number of lines from the container's log file, which is far more efficient than streaming the entire log for a long-running Pod. This exactly satisfies the requirement to see the last 50 lines from the named Pod's api-container.

• ✗

  kubectl logs api-container -p api-pod --tail 50

  Why it's wrong here

  This command inverts the expected syntax: kubectl logs always takes the Pod name as the first positional argument, so here 'api-container' is incorrectly interpreted as the Pod name. Furthermore, -p (or --previous) is a boolean flag, not a value-taking option, so 'api-pod' after -p is treated as an extra positional argument, causing an 'expected a single argument' or 'too many arguments' error. To read logs from a previous container instance, the correct pattern is kubectl logs api-pod -c api-container --previous, not the ordering shown here.

Go deeper

Related to this question