Courseiva
← CKS
Full test
hardMultiple ChoiceObjective-mapped

CKS Practice Question: A pod is failing with status 'CrashLoopBackOff'

A pod is failing with status 'CrashLoopBackOff'. The pod manifest includes a liveness probe that runs every 10 seconds. You suspect the probe is causing the crash. Which command would you use to verify the liveness probe configuration?

⚠ Common exam trap

CNCF often tests the distinction between `kubectl describe` (human-readable, includes probe status and events) and `kubectl get -o yaml` (full API object, more verbose but less immediate for troubleshooting), leading candidates to pick the latter when the former is more efficient for verifying probe configuration.

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 describe pod <pod>

`kubectl describe pod <pod>` displays the pod's full configuration, including the liveness probe's exact parameters (e.g., initialDelaySeconds, periodSeconds, failureThreshold, and the probe action like HTTP GET, TCP socket, or exec command). This allows you to verify if the probe is misconfigured (e.g., too aggressive or pointing to a non-existent endpoint) and causing the CrashLoopBackOff.

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 logs <pod>

    Why it's wrong here

    kubectl logs <pode> captures the container's stdout/stderr, which can reveal application-level errors, but a CrashLoopBackOff caused by a failing liveness probe often leaves no log output because the container starts, passes its startup routine, and is then killed by kubelet based on probe results. Even if logs are available, they will not show the probe's command, initial delay, period, or threshold settings, so this command cannot identify misconfigured probes that lead to repeated restarts. For a probe-induced crash loop, you need to inspect the pod's specification and event history, not just application output.

  • ✗

    kubectl exec <pod> -- cat /etc/kubernetes/manifests/pod.yaml

    Why it's wrong here

    kubectl exec <pod> -- cat /etc/kubernetes/manifests/pod.yaml is invalid for diagnosing a regular (non-static) pod because that path is only used for static pods defined on the kubelet's host filesystem; most pods are created through the API server and their manifests are not stored as files inside the container or on that path. Even if the pod were static, the container file system does not typically mount the host's /etc/kubernetes/manifests directory, so the file would not be accessible. Additionally, if the container is in CrashLoopBackOff, exec may fail because the container is restarting or not running, preventing command execution altogether.

  • ✓

    kubectl describe pod <pod>

    Why this is correct

    kubectl describe pod <pode> is the correct troubleshooting command because it consolidates the pod's live configuration, status, and recent events in a human-readable format. Under the Containers section, it explicitly shows the livenessProbe block, including exec command, initialDelaySeconds, periodSeconds, timeoutSeconds, and failureThreshold, along with the container's current state and restart count. It also surfaces events such as 'Unhealthy' or 'Killing' with timestamps, making it easy to see whether the probe is causing the CrashLoopBackOff and what specific probe parameters are misconfigured.

  • ✗

    kubectl get pod <pod> -o yaml

    Why it's wrong here

    kubectl get pod <pode> -o yaml does expose the livenessProbe configuration under spec.containers, but it outputs the entire pod manifest in YAML format, which is overly verbose for quick troubleshooting—you must scroll through many unrelated fields to find the probe settings. More importantly, this command does not include the recent events or the concise status summary that describe provides; the events that explain why the container was killed (e.g., probe failure) are only available via kubectl describe or kubectl get events. For a focused, efficient diagnosis, describe is the preferred choice, even though YAML is technically valid.

About these practice questions

This CKS question is part of Courseiva's 114-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.