Application Observability and Maintenance →hardMultiple Choice

CKAD Application Observability and Maintenance Practice Question

You deploy a pod with the following specification:

apiVersion: v1 kind: Pod metadata: name: probe-pod spec: containers: - name: app image: nginx livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 3

The application listens on port 80, not 8080. What will happen to the pod?

⚠ Common exam trap

Many exam-takers assume the pod will be terminated or stuck, but they forget that liveness probes cause container restarts (not pod deletion) and that the pod will still reach 'Running' state initially, only to be repeatedly restarted.

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 container will be restarted repeatedly due to liveness probe failure

The liveness probe is configured to perform an HTTP GET request on port 8080, but the application (nginx) listens on port 80. Since the probe will never receive a successful HTTP response (it will get a connection refused or timeout), it will fail. With a failureThreshold of 3, after three consecutive failures the kubelet will consider the container unhealthy and restart it. This cycle repeats indefinitely, causing the container to be restarted repeatedly.

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 pod will be terminated and not restarted
Why it's wrong here
A failing liveness probe does not terminate the entire pod; the kubelet kills the individual container and then consults the pod's restartPolicy. Since restartPolicy defaults to Always when omitted, the container is immediately scheduled for another start rather than leaving the pod terminated. Pod termination would require a node-level failure, eviction, or a restartPolicy of Never combined with container exit, none of which apply here.
✗
The pod will start and run normally
Why it's wrong here
The pod will not operate normally because the liveness probe targets TCP port 8080, which has no listener inside the container, so every probe attempt times out or returns a non-success response. Kubelet treats repeated failures as an unhealthy container and restarts it, producing a CrashLoopBackOff instead of a steady Running state. A normally running pod must have its liveness probe succeed (e.g., HTTP 200 or a successful TCP connection) once the process starts.
✓
The container will be restarted repeatedly due to liveness probe failure
Why this is correct
Correct. The liveness probe checks a health endpoint or TCP port on the container; when that probe fails continuously, the kubelet kills the container and restarts it according to restartPolicy (Always by default). Each subsequent restart is followed by another failing probe, so the container enters a restart loop with exponential backoff, visible as CrashLoopBackOff in container status. This matches the expected behavior for a misconfigured or broken liveness probe on port 8080.
✗
The pod will be stuck in 'Pending' state
Why it's wrong here
A Pod enters Pending only before any containers are created, typically due to unschedulable resources, taints, or image pull problems. The liveness probe is executed by the kubelet only after the container has been successfully created and started, so a failing probe cannot affect the Pending phase. Even if the probe fails immediately, the pod first moves to Running and then shows restarts, never reverting to Pending.

Go deeper

CKAD Application Observability and Maintenance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question