Why custom networks matter in Docker - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use custom Docker networks?

Which of the following is the main reason to create a custom Docker network instead of using the default bridge network?

A To isolate containers and control communication between them

B To increase container CPU usage automatically

C To enable containers to run without Docker installed

D To reduce the size of Docker images

💡 Hint

Think about how containers talk to each other and how you can control that.

Custom networks allow you to isolate containers and control which containers can communicate, improving security and organization.

💻 Command Output

intermediate

Output of listing Docker networks

What is the output of the command docker network ls after creating a custom network named my_custom_net?

Docker

docker network create my_custom_net
docker network ls

A

NETWORK ID   NAME           DRIVER    SCOPE
<id>         bridge         bridge    local
<id>         host           host      local
<id>         none           null      local
<id>         my_custom_net  bridge    local

B Error: network my_custom_net not found

C

NETWORK ID   NAME           DRIVER    SCOPE
<id>         bridge         overlay   local
<id>         my_custom_net  host      local

D No networks found

💡 Hint

Custom networks appear alongside default networks with the same driver unless specified otherwise.

When you create a custom network with the default bridge driver, it appears in the list along with default networks like bridge, host, and none.

🔀 Workflow

advanced

Connecting containers to a custom network

You have two containers: app and db. You want them to communicate securely using a custom network named secure_net. Which sequence of commands correctly sets this up?

A

docker network create secure_net
docker network connect secure_net app
docker network connect secure_net db

B

docker network create secure_net
docker run --network=secure_net app
docker run --network=secure_net db

C

docker network create secure_net
docker run app
docker run db

D

docker network create secure_net
docker network disconnect bridge app
docker network disconnect bridge db
docker network connect secure_net app
docker network connect secure_net db

💡 Hint

Think about how to start containers directly attached to a network.

Starting containers with --network=secure_net attaches them to the custom network immediately, enabling secure communication.

❓ Troubleshoot

advanced

Why can't containers communicate on default bridge network?

You started two containers on the default bridge network but they cannot ping each other by container name. What is the most likely reason?

A Docker daemon is not running

B Containers must be on the host network to communicate

C The default bridge network does not support automatic DNS resolution between containers

D Containers need to share the same image to communicate

💡 Hint

Think about how container names resolve to IP addresses on different networks.

The default bridge network does not provide automatic DNS resolution for container names, so containers cannot reach each other by name without custom networks.

✅ Best Practice

expert

Best practice for Docker network security

Which practice best improves security when using Docker networks in a multi-container application?

A Run all containers with host networking to improve performance

B Use the default bridge network for all containers to simplify setup

C Disable Docker networking to prevent all container communication

D Create separate custom networks for different application components and restrict container connections accordingly

💡 Hint

Think about isolating parts of your app to limit access.

Separating containers into custom networks limits communication to only what is necessary, reducing attack surface and improving security.