CKS Monitoring, Logging and Runtime Security 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.

• ✗

  crictl ps

  Why it's wrong here

  crictl ps lists containers managed by a CRI-compatible runtime, displaying metadata such as container IDs, image names, and running states. This command gives you a snapshot of what containers exist and their status, but it does not expose the actual log output that those containers have emitted. You might use `crictl ps` to identify the right container ID before running `crictl logs`, but by itself it cannot fulfill the need to view a specific container's logs.

• ✗

  crictl exec

  Why it's wrong here

  crictl exec is used to run a new process inside an already-running container, effectively attaching to the container's namespaces to start a command such as a shell or diagnostic utility. It does not retrieve the container's standard output or standard error streams that were produced during the container's lifetime, so it cannot show you the past log entries. While exec can be handy for live troubleshooting, it is not the command you would use to view historical or ongoing container logs.

• ✓

  crictl logs

  Why this is correct

  crictl logs is the correct command because it directly fetches and prints the stdout/stderr output of a specified container, identified by its container ID or name. This command is the CRI equivalent of `docker logs` and is what you would use to inspect application or runtime output for debugging. It supports additional flags such as `-f` to follow logs in real time and `--previous` to view logs from a terminated container, making it the definitive tool for accessing container logs with crictl.

• ✗

  crictl inspect

  Why it's wrong here

  crictl inspect displays detailed JSON metadata about a container, including its configuration, mounts, environment variables, and current runtime status. This command is designed to give you a deep, structural view of the container's specification and state, similar to `docker inspect`. It does not retrieve the container's console output or log streams, so while it can help you understand how the container is configured, it cannot show you the actual log messages you would need for debugging runtime behavior.

Go deeper

Related to this question