Compose watch for development in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this Docker Compose watch command?

You run this command to watch file changes and restart the service automatically:

docker compose watch

What will you see in the terminal when a source code file changes?

A The container restarts but does not rebuild the image, showing only logs.

B The service ignores file changes and continues running without any output.

C The service rebuilds and restarts automatically, showing build logs and container logs.

D The command exits immediately with an error about missing watch flag.

💡 Hint

`docker compose watch` detects changes in the build context.

`docker compose watch` monitors the build context for changes, rebuilds the image if needed, recreates and restarts the container, showing build logs and container logs.

❓ Configuration

intermediate

Which docker-compose.yml snippet enables live code reload with volume mounting?

You want your container to reflect code changes immediately during development. Which volume configuration achieves this?

A

volumes:
  - ./app

B

volumes:
  - ./app:/app

C

volumes:
  - app:/app

D

volumes:
  - /app

💡 Hint

Mount your local folder into the container path.

Mounting ./app on the host to /app in the container syncs code changes immediately.

🔀 Workflow

advanced

What is the correct sequence to enable live reload with Docker Compose and nodemon?

You want to develop a Node.js app with live reload inside a container using nodemon. Which sequence of steps is correct?

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Think about installing tools before configuring and running.

First install nodemon, then mount code, set command to nodemon, then start container.

❓ Troubleshoot

advanced

Why does your container not reflect code changes despite volume mounting?

You mounted your local code folder into the container, but changes are not visible inside the container. What is the most likely cause?

A The container runs a built image that overwrites the mounted volume at startup

B The container has no network access

C Docker daemon is not running

D The volume path on the host is incorrect or empty

💡 Hint

Verify the host-side path first.

If the host path (e.g., ./app) is incorrect, doesn't exist, or is empty, the container won't see the expected files despite the volume mount.

✅ Best Practice

expert

Which approach best supports fast iterative development with Docker Compose?

You want to develop a Python web app with fast code reload and minimal container rebuilds. Which setup is best?

A Use volume mounts for source code, run the app with a file watcher like 'watchmedo', and rebuild images only when dependencies change

B Copy source code into image during build and restart container on every code change

C Run the app inside the container without volume mounts and rebuild image on every code change

D Use bind mounts only for dependencies folder and copy source code into image

💡 Hint

Minimize rebuilds and use live reload tools.

Mounting source code and using a watcher inside container avoids rebuilds and speeds development.

Practice

1. What is the main purpose of using docker-compose watch during development?

easy

A. To deploy the app to production servers

B. To build the Docker image only once

C. To automatically reload the application when code changes

D. To monitor container resource usage

Solution

1. Step 1: Understand the role of watch in development

   Watching means tracking file changes to trigger actions automatically.

2. Step 2: Connect watch with docker-compose usage

   Compose watch reloads the app inside the container when source code changes on the host.

3. Final Answer:

   To automatically reload the application when code changes -> Option C

4. Quick Check:

   Compose watch = auto reload on code change [OK]

Hint: Watch means auto reload on code change [OK]

Common Mistakes:

• Confusing watch with building images
• Thinking watch deploys to production
• Assuming watch monitors resource usage

2. Which of the following docker-compose.yml volume configurations correctly syncs your local source code to the container for live reload?

easy

A. volumes:\n - ./app:/app

B. volumes:\n - /app:/app

C. volumes:\n - ./app

D. volumes:\n - /app

Solution

1. Step 1: Understand volume syntax in docker-compose

   Volumes map host paths to container paths using host_path:container_path.

2. Step 2: Identify correct host to container mapping

   ./app:/app maps local folder app to container's /app for syncing code.

3. Final Answer:

   volumes:\n - ./app:/app -> Option A

4. Quick Check:

   Host path before colon, container path after [OK]

Hint: Volume syntax: host_path:container_path [OK]

Common Mistakes:

• Reversing host and container paths
• Omitting container path
• Using absolute container path as host path

3. Given this docker-compose.yml snippet and a Node.js app using nodemon:

services:
  web:
    volumes:
      - ./src:/usr/src/app
    command: nodemon index.js

What happens when you edit a file inside ./src on your host machine?

medium

A. Nothing happens until you rebuild the image

B. The container deletes the edited file

C. The container crashes due to volume conflict

D. The container restarts the Node.js app automatically

Solution

1. Step 1: Understand volume syncing

   The volume syncs ./src on host to /usr/src/app in container, so changes reflect inside container.

2. Step 2: Understand nodemon behavior

   nodemon watches files and restarts the app when files change.

3. Final Answer:

   The container restarts the Node.js app automatically -> Option D

4. Quick Check:

   Volume sync + nodemon = auto restart on code change [OK]

Hint: Nodemon restarts app on synced file changes [OK]

Common Mistakes:

• Thinking image rebuild is needed for code changes
• Assuming container crashes on volume use
• Believing files are deleted on sync

4. You set up docker-compose with volumes and watchmedo to reload a Python app, but changes don't trigger reload. What is the most likely cause?

medium

A. The volume path is incorrect or missing

B. The Dockerfile lacks a CMD instruction

C. The container has no network access

D. The image was not built with --no-cache

Solution

1. Step 1: Check volume configuration

   If volumes don't map host code to container, changes won't appear inside container.

2. Step 2: Understand watchmedo needs code inside container

   Without synced code, watchmedo cannot detect changes to reload app.

3. Final Answer:

   The volume path is incorrect or missing -> Option A

4. Quick Check:

   Missing volume = no code sync = no reload [OK]

Hint: Check volumes if reload doesn't work [OK]

Common Mistakes:

• Blaming CMD instead of volumes
• Assuming network affects file watching
• Thinking image cache affects reload

5. You want to set up a development environment with docker-compose that automatically reloads a React app on code changes. Which combination below is the best practice?

hard

A. Build image with source code baked in, run npm run build once

B. Use volumes to sync source code, run npm start with react-scripts watch mode inside container

C. Use volumes but disable hot reload to avoid conflicts

D. Run npm start on host and use container only for database

Solution

1. Step 1: Sync source code with volumes

   Volumes keep container code updated with host edits for live reload.

2. Step 2: Use React's built-in watch mode

   npm start with react-scripts runs dev server that reloads on changes.

3. Final Answer:

   Use volumes to sync source code, run npm start with react-scripts watch mode inside container -> Option B

4. Quick Check:

   Volumes + watch mode = best dev reload setup [OK]

Hint: Sync code + run dev server with watch mode [OK]

Common Mistakes:

• Baking code into image prevents live reload
• Disabling hot reload loses dev speed
• Running app only on host misses container benefits