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.

• ✗

  systemctl

  Why it's wrong here

  systemctl is the command-line control interface for the systemd init system, not for container runtimes. Although systemd can be used to launch and supervise container processes (e.g., via systemd-nspawn or as a service running a container engine), systemctl itself provides no direct commands to inspect images, exec into containers, or interact with a runtime's API. It manages units and services at the host level, so it cannot perform the container-level operations that ctr or crictl enable.

• ✗

  kubectl

  Why it's wrong here

  kubectl is the Kubernetes control-plane client; it communicates with the kube-apiserver via HTTP, not with the container runtime on a node. All operations such as kubectl exec, logs, and attach are relayed through the API server to the kubelet, which then uses the CRI (Container Runtime Interface) to talk to the runtime. Thus kubectl operates on Kubernetes abstractions like pods and services, and it has no direct visibility or control over containers in the runtime's own namespace.

• ✓

  ctr

  Why this is correct

  ctr is the native CLI for containerd, speaking directly to containerd's gRPC API over its Unix socket (e.g., /run/containerd/containerd.sock). It can list, create, and exec into containers, manage images, snapshots, and tasks without going through Kubernetes or the kubelet. Because it bypasses the CRI layer, it is an invaluable debugging and forensics tool for containerd-based nodes, though it only works when the runtime is containerd and is not suitable for managing CRI-only abstractions like pods.

• ✗

  docker

  Why it's wrong here

  docker CLI talks to the Docker Engine daemon through its own socket (/var/run/docker.sock), not to the container runtime interface used by Kubernetes. Even in the days when Docker was the runtime, the kubelet used dockershim (later CRI-Docker) to translate CRI calls into Docker API calls, so docker commands were indirect and not representative of the actual CRI operations. Modern Kubernetes nodes typically use containerd or CRI-O, on which docker is not installed and cannot function as a runtime client.

• ✓

  crictl

  Why this is correct

  crictl is a dedicated CLI for CRI-compatible container runtimes, designed by the Kubernetes community for debugging and inspecting runtimes on node. It connects directly to the same CRI Unix socket that the kubelet uses, such as /run/containerd/containerd.sock, and can manage pods, containers, images, and even exec commands via the CRI API. This makes it an ideal direct interaction tool because it works with any runtime that implements the CRI, regardless of whether that runtime is containerd, CRI-O, or another conformant implementation.

Go deeper

Related to this question