CKA Troubleshooting Practice Question

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 readinessProbe is interfering with the livenessProbe

  Why it's wrong here

  Kubernetes probes operate independently: the readinessProbe only decides whether the Pod's IP is added to Service Endpoints, while the livenessProbe decides whether kubelet should restart the container. A failing readinessProbe never triggers a restart, so it cannot interfere with or mask liveness decisions. Each probe executes its own HTTP request on its own configured port and path, so liveness restarts are solely driven by livenessProbe responses.

• ✗

  The application has a memory leak

  Why it's wrong here

  A memory leak in the application generally causes the container to exceed its memory limit and be killed by the OOM killer, resulting in an OOMKilled status and a restart for reasons unrelated to HTTP probes. Liveness probe failures, by contrast, occur when the configured HTTP endpoint returns a non-2xx status or when the connection times out, meaning the app is alive but not responding correctly to that endpoint. If the process is still running and responsive on the correct port, a liveness probe on that port will pass regardless of memory pressure.

• ✗

  The kubelet on the node is misconfigured

  Why it's wrong here

  The kubelet is the agent that actually runs liveness probes, so a kubelet-level malfunction would typically produce probe errors or missed checks across all Pods on the node, not a single Pod being restarted. A per-Pod liveness failure with other Pods running normally points to an issue inside that Pod's specification, such as a wrong port or path, rather than a node-level configuration error. Kubelet's probe settings are cluster-wide and cannot selectively alter only one Deployment's probe behavior.

• ✓

  The livenessProbe is configured with the wrong port

  Why this is correct

  The livenessProbe is explicitly configured to send an HTTP request to a specific containerPort, so if that port does not match the port the application is actually listening on, kubelet will receive a connection refused error (or non-2xx response). Kubernetes treats any non-2xx response or connection error as a probe failure; after the failureThreshold is reached, kubelet kills and restarts the container. This produces exactly the observed symptom: the container starts, becomes ready for a moment, then repeatedly restarts while the application itself is healthy on its real port.

Go deeper

Related to this question