KCNA Kubernetes Fundamentals Practice Question
Which TWO of the following are valid ways to view the logs of a pod named 'my-pod'?
⚠ Common exam trap
A common mix-up: candidates confuse `kubectl describe` (which shows pod events and status) with `kubectl logs` (which shows actual application output), or assume `kubectl attach` can retrieve past logs when it only connects to the live process stream.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
kubectl exec my-pod -- cat /var/log/app.log
Option B is correct because kubectl exec my-pod -- cat /var/log/app.log runs the cat command inside the container of the pod, directly reading the application log file at that path, which is a valid way to view logs when the app writes to a file rather than stdout. Option C is correct because kubectl logs my-pod retrieves the stdout/stderr output captured by the container runtime for the pod's (default) container, which is the standard Kubernetes logging mechanism. Option A is not a log-viewing method: kubectl describe pod my-pod shows metadata, status, events, and container specs, not the application's log stream. Option D is invalid syntax and semantics: kubectl run creates a new pod from an image and does not accept a 'logs' subcommand to read an existing pod's logs. Option E is wrong because kubectl attach my-pod attaches the terminal to a running container's process (stdin/stdout of PID 1), which is interactive and not a log-retrieval command.
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 describe pod my-pod
Why it's wrong here
kubectl describe pod reports metadata, events and container status, not the container's stdout/stderr log stream. Describe suits diagnosing scheduling, image-pull or restart failures; reading application output requires kubectl logs, which queries the kubelet's log endpoint.
- ✓
kubectl exec my-pod -- cat /var/log/app.log
Why this is correct
kubectl exec runs a command inside the container, so cat reads the application's log file directly from the container filesystem. This satisfies the stem's requirement for a valid way to view my-pod's logs, though it depends on the file path existing and the container including cat.
- ✓
kubectl logs my-pod
Why this is correct
kubectl logs retrieves stdout and stderr captured by the kubelet for the container in my-pod, which is the standard logging path. This satisfies the stem's requirement for a valid way to view my-pod's logs without executing anything inside the container.
- ✗
kubectl run my-pod -- logs
Why it's wrong here
kubectl run creates a new pod from an image; the trailing arguments become that container's command, so no existing pod's logs are read. Run suits launching throwaway workloads, whereas viewing an existing pod's output requires kubectl logs against 'my-pod'.
- ✗
kubectl attach my-pod
Why it's wrong here
kubectl attach connects to a running container's stdin/stdout for interactive input; it does not read the container log file. Attaching suits debugging a live process expecting terminal input, whereas log retrieval requires kubectl logs, which streams the container runtime's recorded output.
Go deeper
Related to this question
About these practice questions
One of 930 original KCNA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This KCNA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the KCNA exam.