Application Observability and Maintenance →hardMultiple Choice

CKAD Application Observability and Maintenance Practice Question

Exhibit

Refer to the exhibit.

$ kubectl logs myapp-6b4d9f8c7d-abcde
Error: listening on :8080: bind: address already in use
$ kubectl describe pod myapp-6b4d9f8c7d-abcde | grep -A5 Last State
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Message:      listening on :8080: bind: address already in use

The Pod 'myapp' is in CrashLoopBackOff. Based on the exhibit, what is the most likely cause?

⚠ Common exam trap

Watch out — candidates often assume CrashLoopBackOff is always caused by a failing liveness probe (Option D), but they overlook that the container must actually start and run for the liveness probe to be checked; if the container crashes immediately on startup (e.g., due to port conflict), the liveness probe never even runs, and the root cause is a startup failure, not a probe failure.

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 is trying to bind to a port already used by a sidecar or previous instance.

The Pod is in CrashLoopBackOff, which indicates the container repeatedly crashes. The most likely cause is that the container is trying to bind to a port already in use by a sidecar or a previous instance of the same container that hasn't fully terminated. This is a common scenario when a sidecar container (e.g., a logging proxy) binds to the same port, or when the container's port is not released quickly enough after a restart, leading to an immediate crash on startup.

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 init container failed to complete.
Why it's wrong here
The init container failed to complete. Init containers run to completion sequentially before any main container starts, and their logs appear under a separate init container log, not the main container's. A failure in an init container would place the pod in an Init:Error or Init:CrashLoopBackOff state, but the log here shows a runtime bind() error from the main application process, which is unrelated to init container execution.
✗
The readiness probe is misconfigured.
Why it's wrong here
The readiness probe is misconfigured. Readiness probe failures only remove the pod from Service endpoints; the container itself continues running and does not crash. An 'address already in use' error occurs during the main process's socket bind at startup, which is a fundamental network conflict, not a misconfiguration of HTTP or TCP probe settings. Probes do not interact with port binding and cannot produce this kind of kernel-level error.
✓
The container is trying to bind to a port already used by a sidecar or previous instance.
Why this is correct
The container is trying to bind to a port already used by a sidecar or previous instance. The error 'address already in use' (EADDRINUSE) indicates that the application's listen() call failed because the port is already occupied in the shared network namespace. In a pod, containers share the same network namespace, so a sidecar bound to the same port would cause this conflict. Additionally, if a previous instance of the pod is still shutting down and holding the socket in TIME_WAIT, a rapid restart can trigger the same bind failure.
✗
The liveness probe is failing and restarting the container.
Why it's wrong here
The liveness probe is failing and restarting the container. A liveness probe failure causes the kubelet to kill the container and restart it, but the resulting logs show probe timeout, connection refused, or HTTP non-2xx responses, not an 'address already in use' bind error. This error happens during the initial socket creation, before the liveness probe ever runs, and it is a direct consequence of a port conflict, not a health check failure. Restarting due to a liveness probe would not produce this specific system call error.

Go deeper

CKAD Application Observability and Maintenance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question