CKAD Application Observability and Maintenance Practice Question
You have a Deployment called 'web-deploy' with 3 replicas. One of the pods is not receiving traffic, but it shows 'Running' and passes its liveness probe. The readiness probe is configured as a TCP socket check on port 8080. You verify that the application is listening on port 8080. What is a likely reason the pod is not receiving traffic?
⚠ Common exam trap
Watch out — candidates often assume a successful TCP socket check on the correct port guarantees the application is ready to serve traffic, overlooking that TCP only verifies the port is open, not that the application logic is functional.
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 readiness probe is succeeding even though the application is not truly ready, because TCP check only verifies the port is open
A TCP readiness probe only confirms that the TCP port is open and accepting connections, not that the application is fully ready to serve traffic. In this scenario, the application is listening on port 8080 (so the TCP check succeeds), but the pod may still be in a state where it cannot process requests (e.g., still initializing internal caches or waiting for dependencies). Since the readiness probe passes, the pod is added to the Service's endpoints, but traffic sent to it may be dropped or fail, causing the pod to not receive traffic effectively.
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 service is configured to use a different port
Why it's wrong here
A Service routes traffic to pods via label selectors and port mappings: `port` is the Service's listening port and `targetPort` directs traffic to the pod's actual port. If these do not match the containerized application's listening port, kube-proxy forwards requests to a closed port, producing connection refusals or timeouts for all clients. However, such a mismatch is a static configuration defect that exists independently of pod readiness; it would not cause a readiness probe to report success when the app is unready. The scenario's root cause is the probe's shallow check, not the Service's port configuration.
- ✗
The pod's node is cordoned
Why it's wrong here
Cordoning a node sets it as unschedulable, meaning the scheduler will not place any new Pods there and existing pods are allowed to continue running. It does not affect the health or readiness of a Pod that is already running on that node, nor does it change probe behavior. If the node were truly cordoned and the pod was subsequently evicted, the replacement would remain Pending, but the described pod is Running and passing probes, ruling out cordoning as the cause. Thus cordoning cannot explain why readiness succeeds while the application is not actually ready.
- ✗
The liveness probe is failing and restarting the container
Why it's wrong here
A liveness probe determines whether to restart a container by signaling the kubelet to kill and restart it upon repeated failures. If this probe were failing, the container would be in a restart loop or CrashLoopBackOff state, and the pod would not be `Running` and ready; instead it would show restarts and potentially `Running` but with failing liveness. The given situation explicitly indicates the liveness probe passes and the container is Running, so the fault is not liveness. This option is wrong because the symptom misrepresents the probe's role: liveness checks process health, while readiness checks serviceability, and the issue lies in a readiness check that is too lenient.
- ✓
The readiness probe is succeeding even though the application is not truly ready, because TCP check only verifies the port is open
Why this is correct
A TCP readiness probe only opens a raw socket connection to the specified port; it reports success if the TCP handshake completes, regardless of what the application does after that. For a web application, the server process may accept the connection and even return a 503 or a placeholder page while still initializing, causing the probe to pass prematurely. This makes the probe an insufficient indicator of true readiness; the pod is added to the Service's endpoints even though it cannot serve valid HTTP responses. Therefore the correct fix is to use an HTTP or exec probe that validates the application's own health endpoint.
Visual reference
Go deeper
Related to this question
Learn chapter
Pods and Basic Workload Management
Key term
Liveness Probes
A liveness probe is a Kubernetes health check that tells the system whether a container is running properly and should be kept alive or restarted.
Key term
Readiness Probes
A Kubernetes mechanism that checks if a container is ready to start accepting traffic and serve requests.
About these practice questions
Courseiva writes every CKAD question from scratch — 826 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 CKAD 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 CKAD exam.