Courseiva

CKAD Application Observability and Maintenance Practice Question

A Pod is running but not responding to requests. The liveness probe is a TCP check on port 8080. What is the most likely issue?

⚠ Common exam trap

Candidates often assume a successful TCP probe means the application is healthy, but Kubernetes only checks port availability, not application responsiveness, leading to a false sense of health.

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 listening on port 8080 but not processing requests correctly.

A is correct because a TCP liveness probe only checks if the port is open and accepting connections, not whether the application is actually processing requests. If the application is listening on port 8080 but is stuck or not handling HTTP traffic correctly, the TCP probe will still succeed, and Kubernetes will not restart the container. This is a common scenario where the application is 'alive' at the socket level but not 'healthy' at the application layer.

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 listening on port 8080 but not processing requests correctly.

    Why this is correct

    This is the correct answer because a TCP liveness probe only checks whether the TCP port accepts a connection; even if the application is deadlocked, hung, or failing to process requests, the kernel will still complete the handshake, and the probe will report success. In this scenario, the pod is running but not responding to requests, meaning the application has an application-level failure that is invisible to a socket-connect check. As a result, Kubernetes sees the container as healthy and does not restart it, so the unresponsive state persists indefinitely. An HTTP GET probe — which verifies an actual HTTP response with the expected status code — would catch this failure.

  • ✗

    The container is being throttled due to CPU limits.

    Why it's wrong here

    CPU throttling, whether caused by the container's CPU limit or the node's cpu manager, only limits CPU time and does not prevent the process from binding to a socket or accepting connections at the TCP layer. Even when a container is heavily throttled, the kernel keeps the port open, so a liveness probe that merely opens a TCP connection to port 8080 will still succeed — the probe will connect, even though actual request processing is slow or stalled. Therefore, throttling cannot explain a pod that is 'running but not responding to requests' when the liveness probe is a TCP check; it would only cause application-level timeouts if the probe were HTTP-based.

  • ✗

    The probe's initial delay is too short.

    Why it's wrong here

    A liveness probe's initialDelaySeconds controls how long Kubernetes waits after the container starts before the probe is performed. Setting this value too short will cause the kubelet to probe while the application is still initializing, and if the probe fails, the container will be restarted — leading to a crash loop, not a stable 'running' state. The symptom described — a pod that stays running but doesn't respond — is inconsistent with an overly short initial delay, because that would trigger frequent restarts and likely show a CrashLoopBackOff status, rather than a persistent but unresponsive container.

  • ✗

    The liveness probe is misconfigured and should be an HTTP GET.

    Why it's wrong here

    A TCP liveness probe is a valid and common Kubernetes probe type; it is not misconfigured merely by being TCP. The probe checks whether a connection can be established to the container's port, which is often sufficient for simple services, but it does not make any assessment of the application's status after handshake. Although an HTTP GET probe would be a more effective way to detect this particular failure (by expecting a 200 response within a timeout), the use of a TCP probe is a design choice — not a misconfiguration — and the correct description is that the probe is 'insufficient' rather than 'wrongly set.'

Visual reference

Client Server SYN (seq=100) SYN-ACK (seq=200, ack=101) ACK (ack=201) Connection established — data transfer begins

About these practice questions

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