Docker and docker-compose interview questions

depends_on only controls the startup and shutdown order of containers — the dependency starts first. It does not perform health or readiness checks, so web may start while db is still booting and not yet accepting connections. The claim that Compose waits until db is accepting connections on its exposed port would require a healthcheck combined with the long-form depends_on condition: service_healthy syntax. The claim that the web container starts before the db container reverses the order. The claim that the db container is built from its image before the web container image is pulled confuses build/pull ordering with runtime dependency ordering.

When no networks: key is specified, docker-compose automatically creates a default network named <project>_default and attaches every service to it. Containers on that network can resolve each other by their service name, so web can reach db at the hostname db. The services are not isolated, not on the host network, and no explicit network definition is required for basic inter-service communication.

When no networks: key is specified, Docker Compose automatically creates a single user-defined bridge network for the project and attaches every service to it. On a user-defined bridge network, Compose provides embedded DNS so each service is reachable by its service name — web can connect to db:5432 directly. Connecting to localhost:5432 is wrong because containers get their own network namespaces, not the host's. Connecting to db:5432 only if links: [db] is declared is wrong because links is a legacy feature and is not required for service-name DNS on a user-defined bridge network. Connecting to the db container's IP address directly is wrong because service-name DNS is a built-in feature of user-defined bridge networks — no overlay driver or manual network definition is needed.

depends_on makes Compose start each dependency before the service that declares it. cache cannot start until db is up, api cannot start until cache is up, and web cannot start until api is up. Because the chain is linear with no parallel branches, the full startup order is db → cache → api → web.

The condition key changes what Compose waits for (a healthy state or successful exit) but does not change the dependency-based startup order. migrator depends on postgres, and app depends on migrator, so Compose starts postgres first. It waits until postgres is service_healthy before starting migrator. It then waits until migrator exits with service_completed_successfully before starting app. The start sequence is therefore postgres → migrator → app.

The short-list form of depends_on (depends_on: [db]) only guarantees that the db container is created and started before web — it does not wait for db to be ready to accept connections. Even though a healthcheck is defined on db, the short syntax never references it for ordering. To make web wait until db is healthy, you must use the long-form syntax: depends_on: db: condition: service_healthy. Therefore the claim that the web container starts as soon as the db container has been created and is running is correct and the claim that the web container starts only after the db container's healthcheck reports a healthy status is wrong. The claim that depends_on only affects shutdown order, not startup order is wrong because depends_on does affect startup order (not just shutdown). The claim that Compose ignores the healthcheck entirely because no condition key is present on depends_on, and the web container starts before db is wrong because web does start after db, not before — the healthcheck is defined but simply not consulted for dependency ordering.

Docker Compose service discovery works per-network: two containers can resolve each other by service name only when they share at least one user-defined network. Here api shares frontend with web and backend with db, so api can resolve both. web and db share no network, so neither can resolve the other. When services explicitly declare custom networks, Compose does not also attach them to the implicit default network, and one container does not relay DNS for another.

With condition: service_healthy, Compose blocks the dependent service (api) from starting until the dependency (db) reports a healthy status from its healthcheck. If db exhausts all retries and transitions to unhealthy, the service_healthy condition is never satisfied, so api is never started and Compose surfaces an error indicating the dependency is unhealthy. The claim that condition: service_healthy only affects shutdown ordering, not startup is wrong because condition: service_healthy explicitly gates startup, not just shutdown order. The claim that after the healthcheck retries are exhausted Compose starts api anyway with a warning is wrong because Compose does not fall back to starting the dependent after healthcheck failure — the condition remains unsatisfied. The claim that condition is only honored when db also declares a restart policy is wrong because no restart policy is required for condition to be honored.

A common misconception is that the default network lacks DNS. Compose's auto-created default network IS a user-defined bridge, so DNS works. The real distinction is logical segmentation: custom networks let you control which services can discover each other by name, enabling multi-tier isolation (e.g., a front-end network and a back-end network) within the same compose project.

Docker DNS resolution is per-network: each user-defined network maintains its own DNS entries for member containers. A container on multiple networks is listed in each network's DNS namespace. Cross-network communication requires shared membership on at least one user-defined network — there is no transitive routing between networks via DNS.