Courseiva
Troubleshooting →mediumMultiple Choice

CKA Troubleshooting Practice Question

You run 'kubectl get pods' and see a pod named 'db' in CrashLoopBackOff. 'kubectl logs db' shows nothing. 'kubectl logs db --previous' shows 'Error: database connection failed'. What is the most likely cause?

⚠ Common exam trap

A common trap is that candidates may assume CrashLoopBackOff always indicates a probe or resource problem, ignoring the diagnostic value of 'kubectl logs --previous' which reveals application-level errors.

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

✓

The environment variable for database host is incorrect

The 'kubectl logs db --previous' output shows 'Error: database connection failed', which indicates the application inside the container is failing to connect to a database. Since the current logs are empty (the container restarted), the previous logs reveal the root cause: a configuration issue, most likely an incorrect database host environment variable. This is a classic application-level startup failure, not a resource or probe issue.

Answer analysis

Option-by-option breakdown

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

  • ✗

    The node is out of memory

    Why it's wrong here

    If the underlying Kubernetes node were out of memory, the operating system's OOM killer would terminate processes, and the pod status would typically show OOMKilled (Exit Code 137) in the kubectl describe pod output. Because the container logs specifically indicate a connection error rather than an abrupt termination due to resource exhaustion, a node-level memory deficit is not the root cause of this crash loop.

  • ✓

    The environment variable for database host is incorrect

    Why this is correct

    The application inside the container is crashing because it cannot establish a network connection to its dependency, which is a classic symptom of a misconfigured database host environment variable. When the application attempts to resolve or connect to an invalid hostname or IP address specified in its configuration, it throws an unhandled connection exception and terminates, causing Kubernetes to place the pod in a CrashLoopBackOff state.

  • ✗

    The pod's liveness probe is misconfigured

    Why it's wrong here

    A misconfigured liveness probe would cause Kubernetes to actively restart an otherwise running container if the probe fails to respond correctly. This behavior would be clearly documented in the pod's event log as a Liveness probe failed warning, and the container's exit code would reflect a SIGTERM or SIGKILL signal rather than an internal application-level connection crash.

  • ✗

    The container image is missing

    Why it's wrong here

    If the specified container image were missing from the registry or misspelled in the pod manifest, the pod would never transition to a running state to execute application code. Instead, the pod status would immediately show ErrImagePull or ImagePullBackOff during the container creation phase, preventing any application logs or connection errors from being generated in the first place.

About these practice questions

This CKA question is part of Courseiva's 726-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 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.