Concept questionMedium~7 minContainers & Runtime Essentials / 7 of 15

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I define which flows are allowed: ingress to the API, API to database or broker, and any egress to external services. Service discovery should return healthy endpoints and tolerate instance replacement. DNS caching, connection pooling, and long-lived connections need to handle address changes. I trace failures from application name resolution through network policy and load balancer health rather than treating every connection refusal as a Docker issue. Metrics distinguish DNS, connect, TLS, timeout, and application failures.

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.

Red flagsCandidateSigns the container design is fragileSignals that an interviewer may treat as risky.Open details

Details

The app binds only to 127.0.0.1.
Production configuration uses a local Docker host alias.
Network policy allows unrestricted lateral traffic.
Address changes break long-lived clients permanently.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What does localhost mean inside a container?
Why bind ASP.NET Core to 0.0.0.0?
How should a client handle changing service endpoints?

Continue the section

Next in Containers & Runtime Essentials: Container health probes

Step 8 of 15

Readiness, liveness, and startup probes for a .NET service

Opening drill

Concept questionMedium~7 minContainers & Runtime Essentials / 7 of 15

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I define which flows are allowed: ingress to the API, API to database or broker, and any egress to external services. Service discovery should return healthy endpoints and tolerate instance replacement. DNS caching, connection pooling, and long-lived connections need to handle address changes. I trace failures from application name resolution through network policy and load balancer health rather than treating every connection refusal as a Docker issue. Metrics distinguish DNS, connect, TLS, timeout, and application failures.

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.

Red flagsCandidateSigns the container design is fragileSignals that an interviewer may treat as risky.Open details

Details

The app binds only to 127.0.0.1.
Production configuration uses a local Docker host alias.
Network policy allows unrestricted lateral traffic.
Address changes break long-lived clients permanently.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What does localhost mean inside a container?
Why bind ASP.NET Core to 0.0.0.0?
How should a client handle changing service endpoints?

Continue the section

Next in Containers & Runtime Essentials: Container health probes

Step 8 of 15

Readiness, liveness, and startup probes for a .NET service

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

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