CKAD Practice Question: Application Environment, Configuration and Security

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's resource limits are too low

  Why it's wrong here

  Resource limits that are too low manifest as OOMKilled (container killed by cgroup OOM) or severe CPU throttling, not as an application-level bind failure. A CrashLoopBackOff alone does not identify the cause; kubectl logs shows an EADDRINUSE error, which is a networking-level condition. Lowering or raising memory limits would not change the fact that the port is already bound, so this option cannot explain the observed error.

• ✓

  The container's application is attempting to use a port that is already occupied

  Why this is correct

  The logs for the container show an error such as 'listen tcp :8080: bind: address already in use' (or EADDRINUSE), which means the application process could not bind to its configured port because another process on the same network namespace already holds that port. Each pod shares one network namespace among its containers, so either another container in the pod, a host process at the node layer, or a previous instance still in the namespace is occupying the socket. This prevents the application from starting and causes the container to exit, leading Kubernetes to restart it with an exponential backoff, producing CrashLoopBackOff.

• ✗

  The pod's ServiceAccount token is not mounted

  Why it's wrong here

  The ServiceAccount token is a projected volume mounted at /var/run/secrets/kubernetes.io/serviceaccount/token and is used for API server authentication, not for socket binding. If it were missing, the application would fail only when making an authenticated call to the Kubernetes API, typically with an HTTP 403 or error loading config, not with a bind error. The pod still gets a token by default (unless automountServiceAccountToken is false and no explicit injection exists), but its absence has no relation to listening on a port.

• ✗

  The pod is using a readOnlyRootFilesystem

  Why it's wrong here

  A readOnlyRootFilesystem makes the container's root filesystem immutable, so any attempt to write to a non-volume path fails with EROFS (read-only file system) and the application may crash during startup if it writes cache or PID files. This is a filesystem permission issue, completely separate from socket creation and binding. While it can also cause CrashLoopBackOff, it would show a write-related message (e.g., 'open /tmp/cache: read-only file system'), not a bind error like 'address already in use'. Thus, it cannot be the explanation for the port conflict seen in `kubectl logs mypod`.

Go deeper

Related to this question