CKA Troubleshooting Practice Question
A pod is in CrashLoopBackOff. You check the logs with 'kubectl logs my-pod --previous' and see 'Error: cannot connect to database at 10.0.0.1:3306'. The database service is named 'mysql' and runs on port 3306. What is the most likely cause?
⚠ Common exam trap
Watch out — candidates often assume the error is due to network connectivity or the database being down, but the specific mention of a hardcoded IP (10.0.0.1) in the logs points directly to an application configuration issue with the hostname, not a cluster-level network or service problem.
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 application is configured with an incorrect database hostname
The error message 'cannot connect to database at 10.0.0.1:3306' indicates the application is trying to connect to a hardcoded IP address (10.0.0.1) instead of the Kubernetes service name 'mysql'. In Kubernetes, services are accessed via DNS names (e.g., 'mysql.default.svc.cluster.local'), not static IPs, which are ephemeral and can change. This misconfiguration causes the connection failure, leading to the CrashLoopBackOff as the app repeatedly fails to start.
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 application is configured with an incorrect database hostname
Why this is correct
The application's logs clearly show an attempt to establish a database connection to the hardcoded IP address "10.0.0.1". In a Kubernetes environment, applications should typically connect to services using their DNS-resolvable service names (e.g., 'mysql' or 'mysql.default.svc.cluster.local') rather than static cluster IPs, which are ephemeral and subject to change. This misconfiguration prevents the application from correctly resolving and connecting to the intended 'mysql' service, leading to the CrashLoopBackOff.
- ✗
The pod does not have network access to the mysql service
Why it's wrong here
While a lack of network access could cause connection failures, the specific error message typically seen in such scenarios would be a 'connection timeout' or 'no route to host.' The problem here is that the application is attempting to connect to an incorrect, hardcoded IP address ("10.0.0.1") instead of the 'mysql' service's cluster IP, which is dynamically resolved via DNS. The issue is one of incorrect addressing within the application's configuration, not a fundamental network connectivity blockade between the pods.
- ✗
The mysql service is not exposed on port 3306
Why it's wrong here
The application's log output explicitly indicates it is attempting to connect to port 3306, which is the standard and expected port for MySQL databases. If the service were not exposed on this port, the connection attempt itself might fail differently or target a different port. The error message points to a connection *refused* or *timeout* from a specific IP, implying the port is being targeted correctly but the destination is wrong or unreachable at that address.
- ✗
The database pod is not running
Why it's wrong here
While the database pod might not be running, the error message specifically shows the application is trying to connect to a hardcoded IP (10.0.0.1) instead of the service name. Even if the database pod is running, the connection would still fail because the application is using the wrong address. Therefore, the database pod status is less likely the cause.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
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
One of 302 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.