200-901 Application Deployment and Security Practice Question
A development team is using Docker Compose to run a multi-container application. They need to ensure that the web service can resolve the hostname 'db' to the database container's IP address. Which network configuration in the docker-compose.yml file achieves this?
⚠ Common exam trap
The trap here is thinking that the legacy 'links' directive is required for service name resolution, when modern Docker Compose uses shared networks and embedded DNS instead.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Define both services under the same custom network.
Docker Compose automatically creates a default network for the application, and all services join it unless configured otherwise. On a user-defined bridge network, Docker provides automatic DNS resolution so that service names become valid hostnames. Therefore, ensuring both the web and db services are on the same custom network allows the web service to connect to 'db' by its service name, which is the cleanest and most reliable method.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the 'links' directive to link the web service to the db service.
Why it's wrong here
The 'links' directive is a legacy feature that creates an alias and environment variables, but it only works in the default bridge network and is not supported in user-defined networks. It also does not provide automatic DNS resolution for service names in the same way. Modern Compose files should avoid 'links' in favor of shared networks.
- ✗
Publish the database port on the host and use 'host.docker.internal' as the hostname.
Why it's wrong here
Publishing the database port exposes it on the host, and using 'host.docker.internal' would make the web service connect to the database via the host's network, which is inefficient and may not work in all environments. It also bypasses Docker's internal DNS and adds unnecessary network hops. This approach is not the standard way to enable inter-service communication in Compose.
- ✓
Define both services under the same custom network.
Why this is correct
When services are attached to the same user-defined bridge network in Docker Compose, Docker's embedded DNS server automatically resolves service names to their container IPs. This allows the web service to connect to 'db' by hostname without manual linking or IP management. It is the recommended and simplest approach for service discovery in Compose.
- ✗
Set the 'network_mode' of the web service to 'service:db'.
Why it's wrong here
Setting network_mode to 'service:db' makes the web service share the network namespace of the db container, meaning they share the same IP and port space. This is not appropriate for typical client-server communication because it prevents the web service from having its own network identity and can cause port conflicts. It does not provide hostname resolution in the intended way.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 975 original 200-901 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.