Volumes and Persistent Storage Usage in Docker Compose Quiz

Explore key concepts in Docker Compose related to managing volumes and persistent storage. This quiz helps assess your understanding of data persistence, configuration, and common practices for storage in orchestrated container environments.

1. Defining Named Volumes

   Which statement best describes how to define a named volume in a Docker Compose file for persisting a database’s data directory across container restarts?

   1. Include a 'volumes' section at the root and reference it under the service's 'volumes' key.
   2. Mount the host directory directly to the container using an absolute host path.
   3. Specify the volume under the service's 'environment' key.
   4. Add the volume name directly after the container image name.

   Explanation: The correct way is to define the volume in the root-level 'volumes' section and reference it under the service to ensure data persists outside the container lifecycle. Mounting host directories directly works but is not the same as a named volume and can introduce portability issues. Placing the volume under the 'environment' key is incorrect; that section is for environment variables. Adding the volume after the image name is not valid syntax for specifying volumes.

2. Bind Mount vs. Named Volume

   Imagine you want changes made in a local project directory to reflect immediately within your running container. Which type of volume should you use in your Docker Compose configuration?

   1. Bind mount
   2. Named volume
   3. Network alias
   4. Config map

   Explanation: Bind mounts synchronize local files with the container, so changes in your directory appear instantly inside the container, which is especially useful during development. Named volumes do not track changes in the source directory—they are managed by the orchestrator and independent of your file system. Network alias is for networking, not storage, and a config map is not a recognized compose storage type.

3. Volume Path Persistence

   If you define a named volume called 'user-data' and mount it to '/data' in your service, what happens to the files in '/data' after the container is removed and recreated?

   1. The files remain intact and are preserved.
   2. The files are deleted automatically on removal.
   3. The files are moved to a backup folder.
   4. The files are replaced with new files from the container image.

   Explanation: Named volumes preserve their contents even after the associated container is removed or recreated, ensuring persistent storage. Volumes are not deleted unless explicitly removed, so the files are not automatically erased. There is no default behavior to move files to a backup folder, and contents are not replaced with files from the initial image unless the volume is brand new.

4. Syntax Error Recognition

   Which of the following volume entries in a Docker Compose 'volumes' list is syntactically incorrect and would cause an error?

   1. /host/path:/container/path:ro
   2. data-volume:/container/data
   3. ./data:/container/path
   4. /container/data:data-volume

   Explanation: The correct syntax places the source (host path or volume name) before the colon, followed by the target path in the container and optional flags. '/container/data:data-volume' reverses this order, leading to an error. The other options all follow valid patterns: host path to container path, named volume to container path, or relative path to container path.

5. Use Case Suitability

   For storing and sharing persistent log data generated by multiple containers in a compose project, which strategy is most appropriate?

   1. Use a named volume mounted at the same path in each container
   2. Assign random unique bind mounts for each container
   3. Set a different environment variable for each container log path
   4. Use a temporary storage driver

   Explanation: A named volume ensures that multiple containers accessing the same path share persistent data, ideal for logs or shared files. Assigning unique bind mounts isolates data rather than sharing it. Adjusting environment variables only changes configuration, not where data is physically stored. Temporary storage drivers do not persist data, making them unsuitable for persistent log sharing.