A library-hours API container is running and healthy, but nothing on the host can reach it. EXPOSE 8080 is in the Dockerfile. What is the most likely gap?
Select an answer to reveal the explanation.
Short Explanation
EXPOSE is a sticky note saying “I listen on 8080.” Traffic still needs a real door—a run-time publish or map—or the app looks up but unreachable from outside.
Full Explanation
EXPOSE in the Dockerfile documents that the library-hours API intends to listen on a given port; it does not open host or cluster access by itself. When the container is healthy yet unreachable from the host, the most likely gap is missing run-time port mapping—such as a local publish flag or an equivalent Service port configuration in an orchestrator. The process can be listening correctly inside its network namespace while nothing forwards traffic from outside to that namespace.
EXPOSE alone does not always publish the port on every host interface. The process can listen without a Kubernetes Service of type LoadBalancer; LoadBalancer is only one later way to expose workloads in a cluster, not a prerequisite for binding a port inside the container. WORKDIR has no relationship to port numbers and does not cause incorrect binds when it “doesn’t match” a port.
Exam caveat: the application must also listen on the expected interface—binding only to localhost while you map a host port still looks unreachable from other machines or from the host’s non-local paths. Operational check: confirm the process listens inside the container on 0.0.0.0 or the intended address, add an explicit port publish or Service map, and retest connectivity from the host before changing application code.