Bind mounts for development in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Bind mount behavior with file changes

You run a Docker container with this command:

docker run -it -v /host/app:/container/app ubuntu bash

If you edit a file inside /host/app on your host machine, what happens inside the container's /container/app directory?

A The container deletes the file automatically when the host file changes.

B The file inside the container does not change until the container is restarted.

C The container creates a copy of the file and changes do not sync back to the host.

D The file inside the container updates immediately to match the host file changes.

💡 Hint

Think about what a bind mount does: it links host and container directories directly.

A bind mount links the host directory to the container directory directly. Any changes on the host are immediately visible inside the container and vice versa.

❓ Configuration

intermediate

Correct bind mount syntax in docker-compose

Which docker-compose service configuration correctly sets a bind mount from the host ./src directory to the container /app directory?

A

volumes:
  - /app:./src

B

volumes:
  - /src:/app

C

volumes:
  - ./src:/app

D

volumes:
  - app:/src

💡 Hint

Remember the format is host_path:container_path.

In docker-compose, bind mounts use the format host_path:container_path. So ./src:/app mounts the local src folder to /app inside the container.

❓ Troubleshoot

advanced

Why are file changes not visible inside container?

You set up a bind mount with:

docker run -v /home/user/project:/app myimage

But when you edit files in /home/user/project on the host, the container does not see the changes. What is the most likely cause?

A The bind mount path on the host is incorrect or does not exist.

B The container's /app directory is read-only and cannot update.

C Docker does not support bind mounts on Linux hosts.

D The container is using a cached image and needs to be rebuilt.

💡 Hint

Check the exact path on your host machine carefully.

If the host path does not exist or is mistyped, Docker creates an empty directory inside the container, so changes on the host won't appear.

🔀 Workflow

advanced

Using bind mounts for live code development

You want to develop a Node.js app inside a Docker container and see code changes immediately without rebuilding the image. Which workflow is best?

A Build the image once, then use a bind mount to link your local code folder to the container's app folder.

B Rebuild the Docker image every time you change code, then restart the container.

C Copy code into the container at runtime using docker cp after each change.

D Use a Docker volume instead of a bind mount for live code syncing.

💡 Hint

Think about how to avoid rebuilding the image for every code change.

Bind mounts let the container use your local code directly, so changes appear immediately without rebuilding or copying files.

✅ Best Practice

expert

Security considerations with bind mounts

Which is the safest practice when using bind mounts in Docker for development?

A Bind mount the entire host root directory to the container for full access.

B Bind mount only the specific project directory needed by the container.

C Avoid using bind mounts and copy files into the container instead.

D Run the container as root user to avoid permission issues with bind mounts.

💡 Hint

Think about limiting access to only what is necessary.

Binding only the needed project directory limits the container's access to host files, reducing security risks.

Practice

1. What is the main purpose of using bind mounts in Docker during development?

easy

A. To automatically update Docker itself

B. To link files or folders from the host machine directly into the container for live editing

C. To isolate the container completely from the host file system

D. To create a new Docker image from a container

Solution

1. Step 1: Understand bind mounts concept

   Bind mounts connect a folder or file on your computer (host) directly into the container, so changes on the host reflect immediately inside the container.

2. Step 2: Identify the purpose in development

   This allows developers to edit code on their computer and see the changes live inside the container without rebuilding the image.

3. Final Answer:

   To link files or folders from the host machine directly into the container for live editing -> Option B

4. Quick Check:

   Bind mounts = live code sync [OK]

Hint: Bind mounts sync host files live inside containers [OK]

Common Mistakes:

• Confusing bind mounts with Docker image creation
• Thinking bind mounts isolate container from host
• Assuming bind mounts update Docker software

2. Which of the following is the correct syntax to create a bind mount in Docker CLI?

easy

A. docker run --mount /host/path:/container/path image_name

B. docker run -mount bind:/host/path:/container/path image_name

C. docker run -bind /host/path:/container/path image_name

D. docker run -v /host/path:/container/path image_name

Solution

1. Step 1: Recall Docker bind mount syntax

   The correct way to specify a bind mount is using the -v or --volume flag with the format host_path:container_path.

2. Step 2: Check each option

   docker run -v /host/path:/container/path image_name uses -v /host/path:/container/path which is correct. Options A, C, and D use incorrect flags or syntax.

3. Final Answer:

   docker run -v /host/path:/container/path image_name -> Option D

4. Quick Check:

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

Hint: Use -v host_path:container_path for bind mounts [OK]

Common Mistakes:

• Using --mount without correct syntax
• Using non-existent flags like -bind
• Mixing mount types incorrectly

3. Given the command:
docker run -it -v /home/user/app:/app ubuntu bash
What will happen if you edit a file inside /home/user/app on the host while the container is running?

medium

A. The changes will appear immediately inside the container's /app directory

B. The container will crash due to file conflicts

C. The changes will not reflect inside the container until it is restarted

D. The container will create a copy of the file and ignore host changes

Solution

1. Step 1: Understand bind mount behavior

   The -v /home/user/app:/app option mounts the host folder directly into the container, so files are shared live.

2. Step 2: Effect of editing host files

   Editing files on the host folder /home/user/app will immediately reflect inside the container at /app because of the live bind mount.

3. Final Answer:

   The changes will appear immediately inside the container's /app directory -> Option A

4. Quick Check:

   Host edits = instant container updates [OK]

Hint: Host file edits show instantly inside container [OK]

Common Mistakes:

• Thinking container needs restart to see changes
• Assuming container crashes on file edits
• Believing container copies files instead of sharing

4. You run this command but changes on your host folder are NOT visible inside the container:
docker run -v app:/app ubuntu
What is the most likely problem?

medium

A. You used a named volume instead of a bind mount with an absolute host path

B. The container image ubuntu does not support volumes

C. You forgot to add the -it flags

D. The container is missing the /app directory

Solution

1. Step 1: Analyze the volume syntax

   The command uses -v app:/app which creates a named volume called 'app', not a bind mount from the host.

2. Step 2: Understand bind mount requirement

   Bind mounts require an absolute host path like /home/user/app. Using just 'app' creates a Docker-managed volume, so host folder changes won't reflect.

3. Final Answer:

   You used a named volume instead of a bind mount with an absolute host path -> Option A

4. Quick Check:

   Bind mounts need absolute host paths [OK]

Hint: Use absolute host path for bind mounts, not volume names [OK]

Common Mistakes:

• Confusing named volumes with bind mounts
• Forgetting absolute path on host
• Assuming all volumes sync host files

5. You want to develop a Node.js app inside Docker using bind mounts. Your host code is in /home/dev/myapp. Which command correctly sets up the container so that:
- The host code is live inside /usr/src/app in the container
- The container runs npm start
- You can edit code on host and see changes immediately

Choose the best command:

hard

A. docker run -v /home/dev/myapp:/usr/src/app node npm start

B. docker run -v /home/dev/myapp node npm start

C. docker run -v /home/dev/myapp:/usr/src/app -w /usr/src/app node npm start

D. docker run -v /usr/src/app:/home/dev/myapp node npm start

Solution

1. Step 1: Check bind mount and working directory

   docker run -v /home/dev/myapp:/usr/src/app -w /usr/src/app node npm start uses -v /home/dev/myapp:/usr/src/app to bind mount the host folder to the container path, and -w /usr/src/app to set the working directory inside the container.

2. Step 2: Confirm command and live editing

   Running npm start inside the container's working directory ensures the app runs with live code from the host. docker run -v /home/dev/myapp:/usr/src/app node npm start misses the working directory, docker run -v /home/dev/myapp node npm start has incorrect volume syntax (missing container path), and docker run -v /usr/src/app:/home/dev/myapp node npm start reverses paths incorrectly.

3. Final Answer:

   docker run -v /home/dev/myapp:/usr/src/app -w /usr/src/app node npm start -> Option C

4. Quick Check:

   Bind mount + correct workdir + command = docker run -v /home/dev/myapp:/usr/src/app -w /usr/src/app node npm start [OK]

Hint: Set -v host:container and -w container for live dev [OK]

Common Mistakes:

• Omitting working directory (-w) for commands
• Reversing host and container paths
• Not specifying full host path for bind mount