Sharing volumes between containers in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of volume sharing with named volume

What is the output of the following commands when sharing a named volume between two containers?

Docker

docker volume create shared_data

docker run -d --name writer -v shared_data:/data busybox sh -c "echo 'hello' > /data/greeting.txt && sleep 300"

docker run --rm -v shared_data:/data busybox cat /data/greeting.txt

A

Error: volume shared_data not found

B

cat: /data/greeting.txt: No such file or directory

C hello (without newline)

D

hello

💡 Hint

Think about how named volumes persist data and are shared between containers.

The named volume 'shared_data' is created and mounted in both containers. The first container writes 'hello' with a newline to /data/greeting.txt. The second container reads the file and outputs 'hello' with a newline.

❓ Configuration

intermediate

Correct docker-compose volume sharing syntax

Which docker-compose.yml snippet correctly shares a volume named 'shared_data' between two services 'app1' and 'app2'?

A

version: '3'
services:
  app1:
    image: busybox
    volumes:
      - ./shared_data:/data
  app2:
    image: busybox
    volumes:
      - ./shared_data:/data

B

version: '3'
services:
  app1:
    image: busybox
    volumes:
      - /data/shared_data:/data
  app2:
    image: busybox
    volumes:
      - /data/shared_data:/data

C

version: '3'
services:
  app1:
    image: busybox
    volumes:
      - shared_data:/data
  app2:
    image: busybox
    volumes:
      - shared_data:/data
volumes:
  shared_data: {}

D

version: '3'
services:
  app1:
    image: busybox
    volumes:
      - shared_data
  app2:
    image: busybox
    volumes:
      - shared_data
volumes:
  shared_data: {}

💡 Hint

Named volumes are declared under 'volumes' and referenced with 'volume_name:container_path'.

Option C correctly declares a named volume 'shared_data' and mounts it at /data in both services. Option C uses a host path which is not a named volume. Option C misses the container path. Option C uses a relative host path, not a named volume.

❓ Troubleshoot

advanced

Why data is missing when sharing host directory volume

You mounted a host directory as a volume in two containers to share data. Container A writes a file, but Container B cannot see it. What is the most likely cause?

A The host directory was mounted as read-only in Container B

B The containers are on different Docker networks

C The volume was declared as a named volume instead of a bind mount

D Container A did not have write permissions on the host directory

💡 Hint

Check the mount options for the volume in Container B.

If Container B mounts the host directory as read-only, it cannot see new files written by Container A if they are not synced properly or permissions prevent visibility. Network differences do not affect volume sharing. Named volumes and bind mounts behave differently but here a host directory is used. Write permissions on Container A affect writing but not visibility in Container B if files exist.

🔀 Workflow

advanced

Steps to share data between containers using volumes

What is the correct order of steps to share data between two running containers using a named volume?

A 2,1,3,4

B 1,2,3,4

C 1,3,2,4

D 2,3,1,4

💡 Hint

Think about creating the volume before using it in containers.

You must first create the named volume, then start the first container mounting it, write data inside, and finally start the second container mounting the same volume to access the data.

✅ Best Practice

expert

Best practice for sharing sensitive data between containers

Which is the best practice for securely sharing sensitive configuration files between multiple containers?

A Use Docker secrets or a dedicated secrets management tool

B Use a Docker named volume with encrypted filesystem on the host

C Use environment variables to pass sensitive data to each container

D Mount a host directory with sensitive files as a bind mount in all containers

💡 Hint

Consider security and access control for sensitive data.

Docker secrets or dedicated secrets management tools provide secure storage and controlled access to sensitive data. Named volumes or bind mounts do not encrypt or restrict access by default. Environment variables can leak sensitive data in logs or process lists.