CKS Monitoring, Logging and Runtime Security Practice Question
An admin runs 'crictl ps' on a node and sees multiple containers. Which command should they use to view the logs of a specific container?
⚠ Common exam trap
Many exam-takers confuse `crictl` with other container command-line tools, assuming `crictl exec` or `crictl inspect` can retrieve logs, when in fact only `crictl logs` provides that functionality, and `crictl ps -a` merely lists containers without log content.
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
✓
crictl logs <container-id>
`crictl logs` is the dedicated command to retrieve container logs from the container runtime interface (CRI), fetching stdout and stderr output from the specified container, which is essential for debugging and monitoring containerized workloads on a Kubernetes node.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
crictl logs <container-id>
Why this is correct
crictl logs <container-id> is the correct command because it directly retrieves the container's stdout/stderr log stream from the CRI-compatible runtime (containerd, CRI-O, etc.). The runtime stores these logs separately from the container's filesystem, and crictl logs queries that store, analogous to `docker logs`. You can further tailor it with flags like `--tail` or `--timestamps`, but the base command is what fetches the log output for a given container ID.
- ✗
crictl exec <container-id> logs
Why it's wrong here
crictl exec <container-id> logs is incorrect because the `exec` subcommand launches a new process inside the container's namespaces; it does not interact with the container's log path. Here, `logs` is interpreted as the command to execute within the container, so the runtime would try to find a binary named `logs` in the container's environment, which almost certainly does not exist or is not the intended log viewer. Even if such a binary existed, it would run inside the container, not read the container's captured stdout/stderr stream managed by the CRI runtime.
- ✗
crictl inspect <container-id>
Why it's wrong here
crictl inspect <container-id> shows the container's configuration, state, mounts, network settings, and metadata, but it does not display the actual log contents. A field like `log_path` might appear in the inspect output, but that only indicates the file path on the host where the runtime writes logs; you still need `crictl logs` or direct file access to read the log lines. Thus, inspecting is useful for troubleshooting container spec and status, not for reading logs.
- ✗
crictl ps -a <container-id>
Why it's wrong here
crictl ps -a <container-id> is invalid because `ps` lists containers and `-a` includes exited/stopped ones; it never outputs log data. Moreover, `ps` expects filtering options (e.g., `--label`, `--state`, `--name`) rather than a positional container ID, so passing a bare container ID is not a valid invocation. The command would either error out or, at best, show container runtime details (ID, image, name, state, status) in a table—never the logs themselves.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS 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 CKS 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 CKS exam.