Volumes in Compose in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Volume Mount Behavior in Docker Compose

Given the following docker-compose.yml snippet, what will be the output of docker volume ls after running docker-compose up -d?

Docker

version: '3.8'
services:
  app:
    image: busybox
    volumes:
      - data-volume:/data
volumes:
  data-volume:

A

DRIVER    VOLUME NAME
local     data-volume

B

DRIVER    VOLUME NAME
local     project_data-volume

C

DRIVER    VOLUME NAME
local     app_data-volume

D No volumes listed

💡 Hint

Docker Compose prefixes volume names with the project directory name by default.

Docker Compose creates volumes with the project name prefix by default. So the volume named 'data-volume' in the compose file becomes 'project_data-volume' in Docker volume list.

❓ Configuration

intermediate

Correct Volume Syntax in Compose

Which option correctly defines a named volume and mounts it to /var/lib/data inside the container in a docker-compose.yml file?

A

volumes:
  - mydata:/var/lib/data
volumes:
  mydata: {}

B

volumes:
  - /var/lib/data:mydata
volumes:
  mydata:

C

volumes:
  - /var/lib/data:/mydata
volumes:
  mydata:

D

volumes:
  - mydata:/var/lib/data
volumes:
  mydata:

💡 Hint

Named volumes are declared under top-level volumes and referenced by name in services.

Option D correctly declares a named volume 'mydata' and mounts it to '/var/lib/data' inside the container. The volume is declared under top-level volumes without empty config, which is valid.

❓ Troubleshoot

advanced

Volume Mount Not Persisting Data

You have this docker-compose.yml: version: '3.8' services: db: image: postgres volumes: - ./dbdata:/var/lib/postgresql/data After restarting the container, your data is lost. What is the most likely cause?

A The host directory './dbdata' is empty and overwrites the container data directory.

B The volume is not declared under top-level volumes section.

C Postgres requires a named volume, bind mounts are not supported.

D The container image does not support volumes.

💡 Hint

Bind mounts use host directories which can overwrite container data if empty.

Using a bind mount to an empty host directory overwrites the container's data directory, causing data loss on restart.

🔀 Workflow

advanced

Volume Sharing Between Services

You want two services in your Compose file to share the same persistent data. Which volume configuration achieves this?

Docker

version: '3.8'
services:
  service1:
    image: alpine
    volumes:
      - shared-data:/data
  service2:
    image: alpine
    volumes:
      - shared-data:/data
volumes:
  shared-data:

A Use bind mounts with different host paths for each service.

B Each service uses a different named volume with the same path '/data'.

C Both services mount the same named volume 'shared-data' to '/data'.

D Declare volumes only under services, not top-level volumes.

💡 Hint

Named volumes can be shared by multiple services by referencing the same volume name.

Mounting the same named volume 'shared-data' in both services allows them to share persistent data at '/data'.

✅ Best Practice

expert

Best Practice for Volume Declaration in Compose

Which option follows the best practice for declaring and using volumes in a Docker Compose file for production environments?

A Declare named volumes under top-level volumes and mount them in services; avoid bind mounts for persistent data.

B Use bind mounts for all data to easily access files on the host system.

C Declare volumes only inside service definitions without top-level volumes section.

D Use anonymous volumes without names to keep configuration simple.

💡 Hint

Named volumes managed by Docker provide better portability and data safety than bind mounts.

Best practice is to declare named volumes under top-level volumes and mount them in services to ensure data persistence and portability.