KCNA Cloud Native Architecture Practice Question
A microservice logs errors when connecting to the database. The logs show 'connection refused'. Which troubleshooting step should be taken first?
⚠ Common exam trap
The trap here is that candidates often jump to restarting the pod or scaling the deployment, assuming the microservice itself is faulty, rather than recognizing that 'connection refused' is a network-level symptom pointing to the target (the database Service/Endpoints) not being available.
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
✓
Verify the database Service and Endpoints in Kubernetes
The 'connection refused' error indicates that the microservice is attempting to connect to a TCP port on the database endpoint, but no process is listening there. In Kubernetes, the first step is to verify that the database Service exists and that its Endpoints object contains the correct pod IPs and port. If the Endpoints are empty or missing, the Service is not routing traffic to any healthy database pod, which directly causes the refusal. This aligns with the Kubernetes troubleshooting hierarchy: always check the Service and Endpoints before assuming application-level issues.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Verify the database Service and Endpoints in Kubernetes
Why this is correct
'Connection refused' means the client reached a host but nothing accepted the connection, so the Service may have no matching Endpoints. Verifying the Service selector and its Endpoints confirms whether pods are actually registered before investigating DNS, network policy or the database itself.
- ✗
Scale up the microservice deployment
Why it's wrong here
Does not address connectivity.
- ✗
Restart the microservice pod
Why it's wrong here
Restarting the pod discards diagnostic state and, if the database or its Service is down, the replacement pod fails identically. Restarts suit recovering a crashed or hung container, not diagnosing a refused TCP connection, which requires confirming the target endpoint is listening.
- ✗
Check the logs of other microservices
Why it's wrong here
Other microservices' logs reveal nothing about this pod's refused connection to the database and delay diagnosis. Comparing peer logs suits detecting a fleet-wide configuration drift or shared dependency outage, not isolating a single client's failed TCP connect.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 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 KCNA 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 KCNA exam.