Bind mounts versus named volumes

WHAT THIS TESTS It checks whether you understand Docker's two main persistence mechanisms and can match each to a realistic scenario.

A GOOD ANSWER COVERS A bind mount maps an exact host path into the container; the host owns the data and any change on either side is instantly reflected. It is tied to the host's directory structure, which makes it less portable and subject to host permissions. A named volume is created and managed by Docker in its own storage area, referenced by name rather than host path; it is portable across hosts, easier to back up via Docker, and Docker controls its lifecycle. The classic split: in development, bind-mount your source directory into the web container so code edits hot-reload without rebuilding. For the database, use a named volume mounted at the data directory so the data is durable, managed, and not entangled with a developer's local folder layout.

COMMON WRONG ANSWERS Treating them as interchangeable. Using a bind mount for production database files, coupling data to a fragile host path and risking permission issues. Forgetting bind mounts can shadow image contents. Assuming named volumes live at an obvious host path you should edit directly.

LIKELY FOLLOW-UPS Why are named volumes preferred for databases? What permission pitfalls do bind mounts have? What is a tmpfs mount, and how does anonymous differ from named?

ONE CONCRETE EXAMPLE The web service in dev mounts ./src:/app as a bind mount so saving a file triggers hot reload. The db service mounts a named volume pgdata:/var/lib/postgresql/data so the database persists and is managed by Docker, independent of where the project folder lives on any developer's machine.