Bridge network default behavior in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Default IP assignment in Docker bridge network

When you create a container attached to the default Docker bridge network, how is its IP address assigned?

A The container receives an IP address dynamically assigned from the bridge network's subnet by Docker's internal DHCP.

B The container receives a static IP address defined in the Dockerfile.

C The container shares the host machine's IP address directly without any separate IP.

D The container does not get any IP address unless manually configured.

💡 Hint

Think about how Docker manages networking for containers by default.

Docker's default bridge network uses an internal DHCP mechanism to assign IP addresses dynamically to containers from its subnet.

💻 Command Output

intermediate

Inspecting bridge network IP range

What is the output of the following command snippet that inspects the default bridge network's subnet?

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

A 172.17.0.0/16

B 192.168.1.0/24

C 10.0.0.0/8

D No output, command fails

💡 Hint

The default Docker bridge network usually uses a private IP range starting with 172.

The default Docker bridge network typically uses the subnet 172.17.0.0/16 unless customized.

❓ Troubleshoot

advanced

Container cannot reach host on default bridge network

A container connected to the default bridge network cannot ping the host machine's IP address. What is the most likely reason?

A The container's IP address conflicts with the host's IP address.

B Docker disables inter-container communication by default on the bridge network.

C The host's firewall blocks traffic from the Docker bridge subnet.

D Containers on the default bridge network do not get DNS resolution.

💡 Hint

Consider network security settings on the host machine.

Host firewalls often block traffic from Docker bridge subnet IPs, preventing containers from reaching the host IP.

🔀 Workflow

advanced

Connecting two containers on default bridge network

You want two containers on the default bridge network to communicate by name. What must you do?

A Restart Docker daemon to enable container name resolution on the default bridge network.

B Manually edit /etc/hosts inside each container to add the other container's name and IP.

C Use the container's IP address directly because DNS is not supported on the default bridge network.

D Create a user-defined bridge network instead, which supports automatic DNS resolution by container name.

💡 Hint

Think about Docker's networking features for name resolution.

The default bridge network does not support automatic DNS resolution by container name. User-defined bridge networks do.

✅ Best Practice

expert

Securing default bridge network communication

What is the best practice to restrict container communication on the default Docker bridge network?

A Use Docker's --icc=false option to disable inter-container communication on the default bridge network.

B All of the above combined provide the best security.

C Configure iptables rules on the host to block unwanted container traffic on the default bridge network.

D Disable the default bridge network and create isolated user-defined bridge networks with specific rules.

💡 Hint

Consider multiple layers of network security controls.

Combining disabling inter-container communication, using isolated networks, and host firewall rules provides strong security.

Practice

1. What is the default behavior of Docker's bridge network regarding container communication?

easy

A. Containers can communicate by container name without extra setup.

B. Containers cannot communicate with each other at all.

C. Containers can communicate with each other by IP address only.

D. Containers share the host network directly.

Solution

1. Step 1: Understand bridge network basics

   The default bridge network connects containers on the same Docker host and allows communication by IP address.

2. Step 2: Analyze name resolution behavior

   By default, containers on the bridge network cannot resolve each other's names without a custom network.

3. Final Answer:

   Containers can communicate with each other by IP address only. -> Option C

4. Quick Check:

   Bridge network communication = IP only [OK]

Hint: Default bridge allows IP communication, not name resolution [OK]

Common Mistakes:

• Assuming container names resolve by default
• Thinking containers share host network directly
• Believing containers cannot communicate at all

2. Which Docker command shows the default bridge network details?

easy

A. docker info bridge

B. docker network ls

C. docker container ls

D. docker network inspect bridge

Solution

1. Step 1: Identify command to inspect networks

   To see details of a specific network, use docker network inspect <network-name>.

2. Step 2: Apply to default bridge network

   The default bridge network is named "bridge", so the command is docker network inspect bridge.

3. Final Answer:

   docker network inspect bridge -> Option D

4. Quick Check:

   Inspect bridge network = docker network inspect bridge [OK]

Hint: Inspect networks with 'docker network inspect <name>' [OK]

Common Mistakes:

• Using 'docker container ls' to see networks
• Trying 'docker info bridge' which is invalid
• Confusing 'docker network ls' with inspect

3. Given two containers on the default bridge network, what happens if you try to ping one container by its name from the other?

medium

A. Ping fails because default bridge does not support container name resolution.

B. Ping fails unless containers are on a custom network.

C. Ping succeeds only if containers share the same image.

D. Ping succeeds because default bridge supports name resolution.

Solution

1. Step 1: Recall default bridge network name resolution

   The default bridge network does not provide automatic DNS resolution for container names.

2. Step 2: Understand ping behavior by name

   Trying to ping by container name will fail because the name cannot be resolved to an IP address.

3. Final Answer:

   Ping fails because default bridge does not support container name resolution. -> Option A

4. Quick Check:

   Default bridge name resolution = no [OK]

Hint: Default bridge lacks DNS for container names [OK]

Common Mistakes:

• Assuming ping by name works by default
• Confusing image sharing with network name resolution
• Thinking custom networks are not needed

4. You created two containers on the default bridge network and tried to connect them by name, but it failed. What is the likely cause?

medium

A. The containers are not running.

B. You forgot to create a user-defined bridge network.

C. The Docker daemon is not started.

D. You used the wrong container names.

Solution

1. Step 1: Understand default bridge limitations

   Default bridge network does not support container name resolution for communication.

2. Step 2: Identify solution for name-based communication

   Creating a user-defined bridge network enables automatic DNS resolution of container names.

3. Final Answer:

   You forgot to create a user-defined bridge network. -> Option B

4. Quick Check:

   Name resolution needs user-defined bridge [OK]

Hint: Use user-defined bridge for name resolution [OK]

Common Mistakes:

• Blaming container state without checking network
• Assuming Docker daemon is stopped without evidence
• Ignoring network type for name resolution

5. You want two containers to communicate by name and also access the internet. Which approach using Docker's networking should you take?

hard

A. Connect both containers to a user-defined bridge network which supports name resolution and NAT for internet access.

B. Use the default bridge network and manually edit /etc/hosts in each container.

C. Connect containers to the host network to share internet and name resolution.

D. Create a macvlan network to enable name resolution and internet access.

Solution

1. Step 1: Identify network supporting name resolution and NAT

   User-defined bridge networks provide automatic DNS for container names and NAT for internet access.

2. Step 2: Evaluate other options

   Default bridge lacks name resolution; host network shares host IP but no DNS; macvlan isolates containers and does not provide NAT by default.

3. Final Answer:

   Connect both containers to a user-defined bridge network which supports name resolution and NAT for internet access. -> Option A

4. Quick Check:

   User-defined bridge = name resolution + NAT [OK]

Hint: User-defined bridge = name resolution + internet [OK]

Common Mistakes:

• Editing /etc/hosts manually is error-prone
• Assuming host network provides container DNS
• Using macvlan without NAT causes no internet