Why should you create a user-defined bridge network instead of using the default one?
On a user-defined bridge, containers resolve each other by name through Docker's built-in DNS, and you get better isolation. On the default bridge you must use IP addresses or legacy links.
Explain it simply
On the default bridge, containers are like people in a big hall with no phone directory: you need each other's number (IP), and numbers change when a container restarts. A user-defined network gives you a directory where you dial by name.
Docker runs an embedded DNS server for user-defined networks, so a container called db is reachable as db from other containers on that network. Containers can be attached or detached live, and only containers on the same network can talk, which gives you a simple way to separate frontends from databases. The default bridge network has no name resolution (apart from the legacy --link), and all containers share it.
Compose automatically creates a user-defined network per project, which is why services can call each other by service name.
Example
docker network create shop-net
docker run -d --name db --network shop-net postgres:16
docker run -d --name api --network shop-net myapi
docker exec api ping -c1 db # resolves by nameWhat to say in the interview
"A user-defined bridge has automatic DNS by container name, better isolation and live attach and detach. The default bridge lacks name resolution, so I always create my own network, which is also what Compose does."
Common mistakes
- Hard-coding container IPs, which change on restart.