Volume vs bind mount decision in Docker - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Choosing between Docker volume and bind mount for persistent data

You want to store database data persistently in Docker. Which option best explains when to use a Docker volume instead of a bind mount?

A Use a Docker volume when you want Docker to manage the data storage location and ensure portability across different hosts.

B Use a Docker volume only if you want to directly edit files on the host machine from inside the container.

C Use a bind mount when you want Docker to manage the data storage and isolate it from the host filesystem.

D Use a bind mount when you want Docker to automatically backup the data to the cloud.

💡 Hint

Think about who controls the data location and portability.

Docker volumes are managed by Docker and stored in a Docker-controlled location, making them portable and easier to backup. Bind mounts link directly to host directories, which can be less portable and more dependent on host paths.

💻 Command Output

intermediate

Output of Docker volume inspect command

What is the output type of the command docker volume inspect my_volume?

Docker

docker volume inspect my_volume

A An error message saying the volume does not exist, even if it does.

B A JSON array with detailed information about the volume, including mountpoint and driver.

C A plain text list of files inside the volume.

D A simple string showing only the volume name.

💡 Hint

Think about what 'inspect' commands usually return in Docker.

The docker volume inspect command returns detailed information about the volume in JSON format, including its mountpoint and driver details.

🔀 Workflow

advanced

Correct order to create and use a Docker volume in a container

Arrange the steps in the correct order to create a Docker volume and use it in a container.

A 1,3,2,4

B 3,1,2,4

C 1,2,3,4

D 3,2,1,4

💡 Hint

Think about listing volumes before and after creation, and when to remove.

First, create the volume, then list volumes to see it, run the container using it, and finally remove the volume when no longer needed.

❓ Troubleshoot

advanced

Troubleshooting permission issues with bind mounts

You mounted a host directory into a container using a bind mount, but the container process cannot write to the directory. What is the most likely cause?

A Docker volumes never have permission issues, so the problem is with the container image.

B The container must be restarted twice to apply bind mount permissions.

C Bind mounts automatically change permissions to allow container writes.

D The host directory permissions do not allow the container user to write to it.

💡 Hint

Consider how host filesystem permissions affect bind mounts.

Bind mounts use the host directory directly, so if the host directory permissions do not allow writing by the container user, the container cannot write to it.

✅ Best Practice

expert

Best practice for sharing configuration files between host and container

You want to share configuration files between your host and a Docker container, allowing live edits on the host to reflect immediately inside the container. Which is the best approach?

A Bake the configuration files into the container image and rebuild the image on every change.

B Use a Docker volume to store the configuration files and copy them manually when changed.

C Use a bind mount to link the host configuration directory to the container path.

D Use a Docker secret to store configuration files for live editing.

💡 Hint

Think about live updates and direct file access.

Bind mounts allow the container to access the exact files on the host, so changes on the host are immediately visible inside the container without rebuilding or copying.

Practice

1. Which Docker storage option should you use if you want Docker to manage persistent data independently of the host system?

easy

A. Use a temporary container filesystem

B. Use a bind mount

C. Use a network file share

D. Use a Docker volume

Solution

1. Step 1: Understand Docker volume purpose

   Docker volumes are designed to store persistent data managed by Docker itself, independent of the host's file system structure.

2. Step 2: Compare with bind mounts

   Bind mounts link host files or folders directly, so Docker does not manage the data lifecycle.

3. Final Answer:

   Use a Docker volume -> Option D

4. Quick Check:

   Docker manages data = Use volume [OK]

Hint: Docker manages data? Choose volume. Host controls? Choose bind mount. [OK]

Common Mistakes:

• Confusing bind mounts as Docker-managed storage
• Using temporary container filesystem for persistent data
• Assuming network file share is a Docker volume

2. Which of the following is the correct syntax to create a Docker container with a bind mount from host folder /home/user/data to container folder /app/data?

easy

A. docker run -v /home/user/data:/app/data myimage

B. docker run --mount type=bind,source=/app/data,target=/home/user/data myimage

C. docker run --bind /home/user/data:/app/data myimage

D. docker run -v /app/data:/home/user/data myimage

Solution

1. Step 1: Recall bind mount syntax with -v

   The correct syntax for bind mounts with -v is -v host_path:container_path. So -v /home/user/data:/app/data is correct.

2. Step 2: Check other options for errors

   docker run --mount type=bind,source=/app/data,target=/home/user/data myimage reverses source and target paths and uses --mount incorrectly. docker run --bind /home/user/data:/app/data myimage uses invalid flag --bind. docker run -v /app/data:/home/user/data myimage reverses host and container paths.

3. Final Answer:

   docker run -v /home/user/data:/app/data myimage -> Option A

4. Quick Check:

   Bind mount syntax = -v host:container [OK]

Hint: Bind mount syntax: -v host_path:container_path [OK]

Common Mistakes:

• Reversing host and container paths
• Using invalid flags like --bind
• Confusing --mount syntax parameters

3. Given the command docker run -v mydata:/data busybox ls /data, what will be the output if mydata volume is empty?

medium

A. Lists files from host /data directory

B. Shows an empty list (no files)

C. Throws an error: volume not found

D. Lists files from busybox image /data directory

Solution

1. Step 1: Understand volume behavior

   The volume mydata is mounted at /data inside the container. If the volume is empty, the container sees an empty directory at /data.

2. Step 2: Check command output

   The ls /data command lists files in the mounted volume. Since it is empty, the output is empty (no files listed).

3. Final Answer:

   Shows an empty list (no files) -> Option B

4. Quick Check:

   Empty volume = empty directory inside container [OK]

Hint: Empty volume means empty folder inside container [OK]

Common Mistakes:

• Assuming volume auto-fills with image files
• Expecting error if volume is empty
• Confusing volume with bind mount behavior

4. You want to edit source code files live on your host and see changes immediately inside the container. You tried docker run -v /app/src busybox but it fails. What is the error and how to fix it?

medium

A. Error: permission denied; fix by running as root

B. Error: volume not found; fix by creating volume first

C. Error: missing container path; fix by adding host:container in -v

D. Error: invalid image; fix by using correct image name

Solution

1. Step 1: Identify syntax error in -v flag

   The command -v /app/src is incomplete. Docker expects -v host_path:container_path or volume_name:container_path.

2. Step 2: Fix by specifying both paths

   To bind mount host folder /app/src into container, use -v /app/src:/app/src or similar.

3. Final Answer:

   Error: missing container path; fix by adding host:container in -v -> Option C

4. Quick Check:

   -v requires host:container paths [OK]

Hint: -v must have host and container paths separated by colon [OK]

Common Mistakes:

• Using only one path in -v flag
• Confusing volume creation with bind mount syntax
• Ignoring error messages about syntax

5. You want to share a configuration file /etc/config.yaml from your host with multiple containers, and you want Docker to manage the data lifecycle. Which approach is best?

hard

A. Create a Docker volume, copy the file into it, then mount the volume in containers

B. Use a bind mount directly from /etc/config.yaml to containers

C. Copy the file into each container image manually

D. Use a network file share mounted inside containers

Solution

1. Step 1: Understand requirement for Docker-managed data

   You want Docker to manage the data lifecycle, so bind mounts (host-managed) are not ideal.

2. Step 2: Use volume and copy file

   Create a Docker volume, copy /etc/config.yaml into it once, then mount this volume into all containers. This centralizes management.

3. Final Answer:

   Create a Docker volume, copy the file into it, then mount the volume in containers -> Option A

4. Quick Check:

   Docker manages data = use volume + copy file [OK]

Hint: For Docker-managed shared data, use volume with copied files [OK]

Common Mistakes:

• Using bind mounts when Docker management is needed
• Copying files into images instead of using volumes
• Assuming network shares are Docker volumes