CKAD Application Observability and Maintenance 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.

• ✓

  Readiness probe

  Why this is correct

  Readiness probes are a first-class probe type that tells the kubelet when a container is ready to begin accepting traffic. If the probe fails, the Pod's IP is removed from the endpoints of all Services, but the container is not terminated or restarted. This allows the container to remain running while it load-balances nothing, making it distinct from liveness probes which restart containers. The assignment of readiness is crucial for rolling updates to avoid sending requests to Pods still starting up.

• ✗

  HTTP probe

  Why it's wrong here

  An 'HTTP probe' is not a Kubernetes probe type at all; it is a handler type used to implement one of the three actual probe kinds (liveness, readiness, or startup). With an httpGet handler, the kubelet sends an HTTP GET request to the specified path and port, and a 2xx or 3xx status code indicates success. Because it is a mechanism rather than a goal, you cannot define an HTTP probe on its own — it must be nested inside a probe definition such as readinessProbe or livenessProbe.

• ✓

  Liveness probe

  Why this is correct

  Liveness probes answer whether the container is still alive; they are a core probe type in Kubernetes. If a liveness probe fails, the kubelet kills the container and restarts it according to the Pod's restartPolicy, which helps recover from deadlocks or memory leaks. Unlike readiness probes, liveness failures do not remove the Pod from Service endpoints — they trigger a restart instead. This is why distinguishing between liveness and readiness is a common source of misconfiguration.

• ✗

  Exec probe

  Why it's wrong here

  An 'Exec probe' is another handler, not a probe type, and is commonly confused with liveness or readiness. It configures the kubelet to run a command inside the container, and the probe succeeds only if the command exits with status 0. You would specify exec as the handler inside a livenessProbe, readinessProbe, or startupProbe, for example to check if a critical config file exists or a helper process is running. Exec probes are more flexible than HTTP or TCP handlers because they can inspect arbitrary conditions in the container environment.

• ✗

  TCP probe

  Why it's wrong here

  A TCP probe is also a handler type, not a probe type. It tells the kubelet to attempt opening a TCP connection to a specific port on the container; if the connection is established, the probe succeeds. Like the httpGet and exec handlers, a TCP probe must be configured inside one of the three real probe types, such as readinessProbe. It is useful when an application has no HTTP endpoint to check, but the wording 'probe' is misleading because the actual probe kind remains liveness, readiness, or startup.

Go deeper

Related to this question