Docker Networking: Bridges, Ports u0026 DNS Quiz Quiz

Explore key concepts of Docker networking, including bridge networks, port mappings, and DNS resolution in container environments. This quiz helps solidify your understanding of container connectivity, network isolation, and service exposure in Docker.

1. Bridge Network Basics

   When a Docker container is attached to the default 'bridge' network, what is the primary purpose of this network mode?

   1. To assign a container a public IP address directly from the host's network interface
   2. To allow containers to communicate with each other on the same host while providing network isolation from the host machine
   3. To disable all forms of network access for the container
   4. To ensure containers only communicate with external networks, not with each other

   Explanation: The default 'bridge' network in Docker allows containers on the same bridge to interact with each other while keeping them isolated from the host machine’s network by default. Assigning a public IP address is the job of the 'host' or 'macvlan' driver, not the bridge mode. Bridge networks do not restrict containers only to external communication; instead, they foster inter-container communication. Disabling all network access would require the use of a 'none' network driver, not 'bridge'.

2. Container Port Mapping

   If you run a container with '-p 8080:80', which address and port should be used to access a web service running on port 80 in the container from the host?

   1. container_ip:8080
   2. localhost:80
   3. localhost:8080
   4. container_ip:443

   Explanation: The '-p 8080:80' option maps port 80 inside the container to port 8080 on the host. This means you should connect to 'localhost:8080' on the host to access the service. 'localhost:80' would try to reach the host’s own port 80, not the mapped container. 'container_ip:8080' would not work since 8080 is exposed on the host. Port 443 is unrelated, as it is commonly used for HTTPS services, not specified here.

3. DNS Resolution in Containers

   How do Docker containers typically resolve domain names by default when started without any custom DNS configuration?

   1. By using an offline local DNS cache without any internet queries
   2. By directly querying external DNS servers, bypassing the host settings
   3. By using the host’s DNS settings passed into an internal DNS server
   4. By randomly generating IP addresses for domain names

   Explanation: Docker starts an internal DNS server that containers use by default, which is configured based on the host’s DNS settings. The internal DNS resolves both container names and external domains. Containers do not bypass the host’s DNS settings nor query external DNS servers directly. Local DNS caching only is inaccurate as Docker still needs to resolve new domains over the network. Randomly generating IPs is never a correct DNS behavior.

4. Network Isolation Example

   If two containers are launched on separate custom user-defined bridge networks, can they communicate directly using container names by default?

   1. Yes, because Docker automatically enables cross-network communication
   2. No, because containers on different user-defined bridge networks are isolated
   3. No, unless the 'host' network driver is used for both containers
   4. Yes, but only if the containers have the same name

   Explanation: User-defined custom bridge networks provide network isolation between containers placed on different networks. By default, containers on separate bridge networks cannot communicate, even with name resolution. Cross-network communication requires explicit network connection or configuration. The container name does not affect connectivity between networks, and the 'host' driver disables network namespace isolation, which is a separate scenario.

5. Container Network Name Resolution

   Which of the following is true about service discovery using container names in Docker’s default bridge network compared to a user-defined bridge network?

   1. User-defined bridge networks support container name-based DNS resolution by default, while the default bridge does not
   2. Both networks prevent all forms of service discovery for security reasons
   3. Neither network type supports container name resolution unless an external DNS is configured
   4. The default bridge network supports container name resolution for all containers globally

   Explanation: On user-defined bridge networks, containers can resolve each other's names via built-in DNS, making service discovery straightforward. However, the default 'bridge' network only provides limited support, and typically does not resolve container names without additional configuration. Option two is incorrect because the default bridge does not resolve names globally. Option three is wrong as user-defined networks support name resolution inherently. The fourth option is also incorrect since service discovery is a key feature of user-defined networks.