Challenge 1: Explain Why a Service Name Resolves — Possible Solution
====================================================================

In a Compose project, Docker Compose AUTOMATICALLY creates a custom,
user-defined bridge network for that project and attaches every
service in the file to it — this happens by default, without any
explicit networks: configuration required. Because it's a CUSTOM
bridge network (not the default one), Docker's embedded DNS server
provides automatic name resolution: any container on that network can
resolve another container by its SERVICE NAME (e.g. "db") directly to
its current IP address. That's why mysql://db:3306 works inside the
api container — "db" resolves via DNS to whatever IP the db container
currently has.

Two containers started with plain `docker run` (with no explicit
--network flag) land on the DEFAULT bridge network instead — and the
default bridge network does NOT provide automatic name-based DNS
resolution, only IP-based reachability. A connection string using the
literal name "db" would fail to resolve at all in that setup, because
there's no DNS mechanism translating that name into an IP on the
default bridge — the containers would need to communicate by raw IP
address instead, which is exactly the limitation this chapter flagged
as the key difference between the default bridge and a custom one.