Bird
Raised Fist0
Microservicessystem_design~20 mins

Container networking in Microservices - Practice Problems & Coding Challenges

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Challenge - 5 Problems
🎖️
Container Networking Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
🧠 Conceptual
intermediate
2:00remaining
Understanding Container Network Isolation
Which option best describes how container network isolation is typically achieved in Docker?
AEach container gets its own network namespace, isolating its network stack from others.
BContainers share the host's network stack without any isolation.
CContainers use a shared IP address but different ports without network namespaces.
DContainers communicate only through shared volumes, not networks.
Attempts:
2 left
💡 Hint
Think about how containers keep their network traffic separate.
Architecture
intermediate
2:00remaining
Choosing a Container Network Model
You need to design a microservices system where containers on different hosts must communicate securely and efficiently. Which container network model is best suited?
AHost network model, where containers share the host's network stack.
BBridge network model, where containers communicate only on the same host.
COverlay network model, which allows containers across hosts to communicate securely.
DNone, containers cannot communicate across hosts.
Attempts:
2 left
💡 Hint
Consider multi-host communication with security.
scaling
advanced
2:00remaining
Scaling Container Networking for High Traffic
Your containerized application experiences high traffic and you want to scale networking without bottlenecks. Which approach best supports scalable container networking?
AUse a single bridge network for all containers to simplify routing.
BAssign static IPs to containers and manually configure routing tables.
CDisable container networking and use host networking for all containers.
DImplement a distributed service mesh to manage container communication and load balancing.
Attempts:
2 left
💡 Hint
Think about dynamic routing and load balancing at scale.
tradeoff
advanced
2:00remaining
Tradeoffs Between Host and Overlay Networking
What is a key tradeoff when choosing host networking over overlay networking for containers?
AHost networking provides better performance but less network isolation compared to overlay.
BOverlay networking has no encryption, while host networking encrypts all traffic.
CHost networking offers better isolation but worse performance than overlay.
DOverlay networking requires containers to share the host's IP address.
Attempts:
2 left
💡 Hint
Consider isolation versus performance.
estimation
expert
2:00remaining
Estimating Network Capacity for Containerized Microservices
You run 1000 containers, each sending 1 Mbps traffic continuously. What is the minimum network bandwidth your container host cluster must support to avoid bottlenecks?
A100 Gbps
B10 Gbps
C100 Mbps
D1 Gbps
Attempts:
2 left
💡 Hint
Multiply containers by their traffic and convert units.

Practice

(1/5)
1. What is the main purpose of container networking in microservices?
easy
A. To allow containers to communicate with each other
B. To store container data persistently
C. To build user interfaces for containers
D. To monitor container CPU usage

Solution

  1. Step 1: Understand container networking role

    Container networking connects containers so they can send data and messages to each other.
  2. Step 2: Compare with other options

    Storing data, building interfaces, and monitoring CPU are not related to networking.
  3. Final Answer:

    To allow containers to communicate with each other -> Option A
  4. Quick Check:

    Container networking = communication [OK]
Hint: Networking means communication between containers [OK]
Common Mistakes:
  • Confusing networking with storage
  • Thinking networking builds UI
  • Mixing monitoring with networking
2. Which Docker command creates a user-defined network named mynet?
easy
A. docker create network mynet
B. docker network create mynet
C. docker network new mynet
D. docker net create mynet

Solution

  1. Step 1: Recall Docker network creation syntax

    The correct command is docker network create <name>.
  2. Step 2: Match options with syntax

    Only docker network create mynet matches the correct syntax exactly.
  3. Final Answer:

    docker network create mynet -> Option B
  4. Quick Check:

    docker network create = correct syntax [OK]
Hint: Remember: 'docker network create' is the right command [OK]
Common Mistakes:
  • Swapping 'create' and 'network' order
  • Using 'new' instead of 'create'
  • Shortening 'network' to 'net' incorrectly
3. Given two containers web and db connected on a user-defined network mynet, what happens when web tries to ping db by container name?
medium
A. Ping succeeds because containers can resolve names on the same user-defined network
B. Ping fails because container names are not resolvable
C. Ping succeeds only if IP addresses are used, not names
D. Ping fails because containers cannot communicate on user-defined networks

Solution

  1. Step 1: Understand user-defined network DNS resolution

    User-defined Docker networks provide automatic DNS resolution of container names.
  2. Step 2: Apply to ping scenario

    Since both containers are on mynet, web can ping db by name successfully.
  3. Final Answer:

    Ping succeeds because containers can resolve names on the same user-defined network -> Option A
  4. Quick Check:

    User-defined network = name resolution works [OK]
Hint: User-defined networks enable container name resolution [OK]
Common Mistakes:
  • Assuming container names are never resolvable
  • Thinking IP addresses are always required
  • Believing user-defined networks block communication
4. You created two containers on the default bridge network but they cannot communicate by container name. What is the likely cause?
medium
A. Container names must be IP addresses on default bridge
B. Containers must be on different networks to communicate
C. Default bridge network does not support automatic container name resolution
D. Docker daemon is not running

Solution

  1. Step 1: Recall default bridge network limitations

    The default bridge network does not provide automatic DNS for container names.
  2. Step 2: Analyze communication failure

    Without name resolution, containers cannot reach each other by name on default bridge.
  3. Final Answer:

    Default bridge network does not support automatic container name resolution -> Option C
  4. Quick Check:

    Default bridge = no name resolution [OK]
Hint: Default bridge lacks container name DNS [OK]
Common Mistakes:
  • Thinking containers must be on different networks to communicate
  • Confusing container names with IP addresses
  • Assuming Docker daemon is stopped without checking
5. You want to isolate microservices into separate networks for security but allow only the api service to communicate with db. Which design best achieves this?
hard
A. Create separate networks but connect all containers to all networks.
B. Connect all services to a single network and use firewall rules inside containers.
C. Use the default bridge network for all containers and rely on container names.
D. Create two networks: api-net and db-net. Connect api to both networks, db only to db-net.

Solution

  1. Step 1: Understand network isolation and selective communication

    Separating services into different networks isolates traffic. Connecting api to both networks allows it to talk to db while others cannot.
  2. Step 2: Evaluate options for security and communication

    Create two networks: api-net and db-net. Connect api to both networks, db only to db-net. isolates db and allows only api access. Other options either lack isolation or allow unwanted access.
  3. Final Answer:

    Create two networks: api-net and db-net. Connect api to both networks, db only to db-net. -> Option D
  4. Quick Check:

    Separate networks + selective connection = secure communication [OK]
Hint: Use multiple networks and connect only needed containers [OK]
Common Mistakes:
  • Putting all containers on one network without isolation
  • Connecting all containers to all networks
  • Relying on default bridge network for security