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.

Practice

1. What is the main purpose of using volumes in a Docker Compose file?

easy

A. To limit container CPU usage

B. To speed up container startup time

C. To automatically update container images

D. To keep data safe outside containers so it persists

Solution

1. Step 1: Understand volume role in Docker

   Volumes store data outside the container's writable layer, so data is not lost when containers stop or are removed.

2. Step 2: Compare options

   Options B, C, and D relate to performance or resource limits, not data persistence.

3. Final Answer:

   To keep data safe outside containers so it persists -> Option D

4. Quick Check:

   Volumes = Data persistence [OK]

Hint: Volumes = persistent data storage outside containers [OK]

Common Mistakes:

• Thinking volumes speed up container startup
• Confusing volumes with resource limits
• Assuming volumes update images automatically

2. Which of the following is the correct syntax to define a named volume in a Docker Compose file?

easy

A. services:
volumes:
- mydata:/app/data

B. volumes:
- mydata:/app/data

C. volumes:
mydata:
driver: local

D. volumes:
mydata: /app/data

Solution

1. Step 1: Identify volume declaration section

   Named volumes are declared under the top-level 'volumes:' key with a name and optional driver.

2. Step 2: Check syntax correctness

   volumes: mydata: driver: local correctly defines a named volume 'mydata' with driver 'local'. Options A, B, and D mix service and volume syntax incorrectly or have invalid mapping syntax.

3. Final Answer:

   volumes: mydata: driver: local -> Option C

4. Quick Check:

   Named volume syntax = volumes: mydata: driver: local [OK]

Hint: Define named volumes under top-level 'volumes:' with name and driver [OK]

Common Mistakes:

• Defining volumes under services instead of top-level
• Using list syntax for volume declaration
• Incorrect mapping format for volumes

3. Given this snippet in a Docker Compose file:

services:
  web:
    image: nginx
    volumes:
      - mydata:/usr/share/nginx/html
volumes:
  mydata:

What happens to the data inside /usr/share/nginx/html when the container restarts?

medium

A. Data persists because 'mydata' is a named volume

B. Data is shared with the host folder automatically

C. Data is reset to the image default every restart

D. Data is lost because volumes do not persist

Solution

1. Step 1: Understand named volume behavior

   Named volumes like 'mydata' store data outside the container and keep it between restarts.

2. Step 2: Analyze the mount point

   The volume is mounted to '/usr/share/nginx/html', so data written there is saved in 'mydata' volume.

3. Final Answer:

   Data persists because 'mydata' is a named volume -> Option A

4. Quick Check:

   Named volume mount = data persistence [OK]

Hint: Named volumes keep data safe across container restarts [OK]

Common Mistakes:

• Assuming data resets to image default
• Confusing named volumes with bind mounts
• Thinking volumes do not persist data

4. You wrote this in your Docker Compose file but get an error:

services:
  app:
    image: myapp
    volumes:
      - ./data:/app/data
volumes:
  ./data:

What is the problem?

medium

A. You cannot use relative paths under 'volumes:' top-level key

B. The image name 'myapp' is invalid

C. Bind mounts must be declared under 'volumes:' top-level key

D. The service name 'app' is reserved

Solution

1. Step 1: Understand volume declaration rules

   Top-level 'volumes:' is for named volumes only, not for bind mounts with paths.

2. Step 2: Identify misuse of relative path

   Using './data:' under 'volumes:' top-level is invalid syntax; relative paths belong only in service volume mounts.

3. Final Answer:

   You cannot use relative paths under 'volumes:' top-level key -> Option A

4. Quick Check:

   Relative paths only in service volumes [OK]

Hint: Declare bind mounts only under service volumes, not top-level [OK]

Common Mistakes:

• Putting bind mount paths under top-level volumes
• Assuming image name causes this error
• Thinking service names are restricted

5. You want to share a local folder ./config with a container's /etc/config path and also keep a database's data persistent using a named volume dbdata. Which is the correct Docker Compose snippet?

hard

A. services:
app:
image: myapp
volumes:
- dbdata:/etc/config
db:
image: postgres
volumes:
- ./config:/var/lib/postgresql/data
volumes:
dbdata:

B. services:
app:
image: myapp
volumes:
- ./config:/etc/config
db:
image: postgres
volumes:
- dbdata:/var/lib/postgresql/data
volumes:
dbdata:

C. services:
app:
image: myapp
volumes:
- /etc/config:./config
db:
image: postgres
volumes:
- /var/lib/postgresql/data:dbdata
volumes:
dbdata:

D. services:
app:
image: myapp
volumes:
- ./config:/etc/config
db:
image: postgres
volumes:
- ./dbdata:/var/lib/postgresql/data
volumes:
dbdata:

Solution

1. Step 1: Identify bind mount for local folder sharing

   Bind mounts use local paths like './config:/etc/config' under service volumes.

2. Step 2: Identify named volume for database persistence

   Named volumes like 'dbdata' are declared top-level and mounted as 'dbdata:/var/lib/postgresql/data'.

3. Step 3: Check options for correct syntax

   services: app: image: myapp volumes: - ./config:/etc/config db: image: postgres volumes: - dbdata:/var/lib/postgresql/data volumes: dbdata: correctly uses bind mount for app and named volume for db. Options B and C swap paths incorrectly. services: app: image: myapp volumes: - ./config:/etc/config db: image: postgres volumes: - ./dbdata:/var/lib/postgresql/data volumes: dbdata: uses a bind mount for dbdata instead of named volume.

4. Final Answer:

   services: app: image: myapp volumes: - ./config:/etc/config db: image: postgres volumes: - dbdata:/var/lib/postgresql/data volumes: dbdata: -> Option B

5. Quick Check:

   Bind mount + named volume = services: app: image: myapp volumes: - ./config:/etc/config db: image: postgres volumes: - dbdata:/var/lib/postgresql/data volumes: dbdata: [OK]

Hint: Use bind mounts for local folders, named volumes for persistent data [OK]

Common Mistakes:

• Swapping source and target paths
• Using bind mounts instead of named volumes for DB data
• Declaring bind mounts under top-level volumes