Courseiva
Troubleshooting →easyMultiple Choice

CKA kubelet logs Practice Question

You need to check the logs of a kubelet on a node. Which command should you run on the node?

⚠ Common exam trap

CKA often tests whether candidates know that kubelet is a systemd unit and its logs live in the journal, not in a flat file like /var/log/kubelet.log or in the container runtime's logs.

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

✓

journalctl -u kubelet

The kubelet is a systemd-managed service on most Kubernetes nodes (installed as kubelet.service), so its logs are captured by the systemd journal. Running `journalctl -u kubelet` queries the journal for entries tagged with the kubelet unit, showing startup messages, pod sync errors, certificate issues, and container runtime interactions. This is the canonical way to inspect kubelet behavior on a node for CKA troubleshooting tasks.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    journalctl -u docker

    Why it's wrong here

    The `journalctl -u docker` command reads logs from the systemd unit named `docker.service`, which is the Docker daemon (or dockerd), not the kubelet. Kubelet runs as its own separate systemd unit, typically called `kubelet.service`, so querying the docker unit only exposes container runtime events. On clusters using containerd or CRI-O as the runtime, a `docker.service` unit may not even exist, making this command fail or return empty output.

  • ✗

    dmesg

    Why it's wrong here

    `dmesg` prints the kernel ring buffer, which contains messages from the kernel itself, device drivers, and hardware — it is not a log of userspace daemons like kubelet. While severe kubelet crashes might cause kernel-level messages to appear (for example, OOM killer reports), normal kubelet warnings, configuration errors, or API calls are never written there. The kubelet communicates through logging mechanisms tracked by systemd/journald, making `dmesg` an indirect and unreliable source.

  • ✗

    tail -f /var/log/apache2/access.log

    Why it's wrong here

    This command tails `/var/log/apache2/access.log`, which records HTTP requests served by an Apache web server. Kubelet does not write to Apache access logs; instead, on most systemd-based distributions it emits log entries to the journal, accessible via `journalctl`. On some non-systemd systems, kubelet output may be redirected to a file like `/var/log/kubelet.log`, but never to an Apache-specific path.

  • ✓

    journalctl -u kubelet

    Why this is correct

    `journalctl -u kubelet` is the correct approach because kubelet is registered as a systemd service under the unit name `kubelet.service` on essentially all managed Kubernetes distributions. This command displays all journal entries associated with that unit, preserving timestamps, priorities, and source metadata. It is the standard first step for diagnosing kubelet failures, and can be combined with flags like `-f`, `-n 100`, or `--since` for targeted live troubleshooting.

About these practice questions

Courseiva writes every CKA question from scratch — 726 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official CNCF exam blueprint

This CKA 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 CKA exam.