CKA Troubleshooting Practice Question
You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. You check the logs with 'kubectl logs <pod> --previous' and see: 'Error: unable to connect to database at db-svc:5432 (connection refused)'. What is the most likely cause?
⚠ Common exam trap
The CKA exam often tests the distinction between application-level errors (like 'connection refused') and infrastructure-level errors (like OOM or image pull failures), so candidates must read the exact error message in the logs rather than assuming a generic pod failure cause.
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 database service is not running or is unreachable
The error message 'connection refused' indicates that the pod is attempting to connect to the database at 'db-svc:5432' but the target service is not accepting TCP connections on port 5432. This typically means the database pod or service is not running, or a network policy is blocking the connection. The 'CrashLoopBackOff' status confirms the application container repeatedly fails due to this startup dependency.
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 pod's liveness probe is misconfigured
Why it's wrong here
A misconfigured liveness probe does not directly cause a 'connection refused' error inside the application's logs. When a liveness probe fails, the kubelet restarts the container, which would eventually manifest as CrashLoopBackOff, but the visible symptom would be probe timeout or HTTP error from the kubelet, not a failed outbound database connection. You would also see probe-related events in 'kubectl describe pod', whereas a TCP connection error is an application-level startup dependency failure.
- ✗
The pod's container image is missing
Why it's wrong here
If the container image were truly missing, the container runtime would never start the process; the pod would remain in ImagePullBackOff or ErrImagePull state, with events about a manifest unknown or repository not found. In contrast, a pod in CrashLoopBackOff has executed the container at least once, meaning the image was successfully pulled and started. A missing image would prevent the application binary from running, so it could not produce a database connection attempt at all.
- ✓
The database service is not running or is unreachable
Why this is correct
A connection refused error—specifically ECONNREFUSED—indicates that the application's TCP handshake reached the target host but nothing was listening on that port, or the service endpoints are empty because the backing database pods are not ready. This commonly occurs when the database Deployment has zero ready replicas, the Service selector does not match any pods, or the pod is using an incorrect service name or port. The container's main process exits after failing to initialize its database connection, and the kubelet restarts it, cycling into CrashLoopBackOff.
- ✗
The pod has a memory limit that is too low
Why it's wrong here
If the container's memory limit were too low, the kernel's OOM killer would terminate the process abruptly, and 'kubectl get pod' would report OOMKilled in the last termination reason, not a connection refused message. Memory exhaustion also tends to happen after some runtime usage, whereas this failure appears during startup when the app tries to reach the database. The exit code and the specific network error in the logs are definitive evidence that resource limits are not the culprit.
Visual reference
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
Key term
Pod Failure Troubleshooting
Pod failure troubleshooting is the process of identifying and resolving issues that cause Kubernetes pods to crash, restart, or become unavailable.
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
About these practice questions
Courseiva writes every CKA question from scratch — 302 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 →
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.