A containerized API cannot reach its database and is not reachable from the host. How would you reason about container networking?

Container networking, ports, DNS, and service discovery

Explains bind addresses, published ports, internal DNS, service identity, and why localhost changes meaning across container boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I first separate the application listen port from the host or platform port. The ASP.NET Core process might listen on 0.0.0.0:8080, while Docker or an ingress publishes another external port. For dependencies on the same network, I use the service DNS name and internal port. host.docker.internal can be useful for local host access on supported platforms, but it is not a portable production service-discovery strategy.

Full answer below

Practice focus

Bind addresses, localhost, container ports, published ports, bridge networks, DNS, service discovery, proxies, and connection configuration.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Inside a container, localhost refers to that container. The API must bind to an address reachable through its container network, and dependencies are addressed by their service identity rather than the host's loopback address.
I first separate the application listen port from the host or platform port. The ASP.NET Core process might listen on 0.0.0.0:8080, while Docker or an ingress publishes another external port. For dependencies on the same network, I use the service DNS name and internal port. host.docker.internal can be useful for local host access on supported platforms, but it is not a portable production service-discovery strategy.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I check DNS resolution, routes, network membership, security policies, and whether the target process binds beyond loopback. A startup-order setting does not prove the database is ready; connection retry and readiness need bounded behavior. Behind a reverse proxy, forwarded headers and trusted proxy configuration determine the public scheme and client address. I avoid hardcoding container IPs because instances are replaceable.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using localhost for another container.
Hardcoding a container IP address.
Confusing the container listen port with the published host port.
Assuming startup order means dependency readiness.

A containerized API cannot reach its database and is not reachable from the host. How would you reason about container networking?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement