How do you persist notebooks and artifacts in Docker?

WHAT THIS TESTS: This tests whether you understand that containers are ephemeral by design and that persisting state requires explicit Docker storage primitives. The interviewer cares if you can choose the right mount type for different ML assets such as code, data, and models. They also want to see that you know why committing containers or relying on the writable container layer is an anti-pattern for iterative development.

A GOOD ANSWER COVERS: First, state clearly that any file written inside a container without a mount lives in the writable container layer and disappears when the container is removed. Second, recommend bind mounts for active notebook development so edits on the host are immediately reflected in JupyterLab and vice versa, typically mounting a host project directory into the container notebook workspace. Third, recommend named Docker volumes for datasets and model artifacts because they are portable, easier to back up, and avoid host path dependencies; mention commands like docker volume create and the -v or --mount syntax. Fourth, discuss permission mapping since Jupyter images often run as a non-root user, so the host UID and GID may need alignment or you need to pass user flags. Fifth, optionally mention that large read-only datasets can be mounted read-only to prevent accidental modification.

COMMON WRONG ANSWERS: A major red flag is suggesting docker commit to save the container state as a new image because this bloats the image with data and breaks reproducibility. Another is proposing COPY or ADD in the Dockerfile to persist notebooks, which requires rebuilding the image on every change and conflates code with data. Saying you will simply never stop the container is also unacceptable for production reliability. Finally, using bind mounts for everything without acknowledging their host path dependency and permission issues shows shallow understanding.

LIKELY FOLLOW-UPS: The interviewer may ask how you would share a volume across multiple containers or data scientists. They might probe on how to handle multi-gigabyte datasets that should not live inside the image or be copied to the writable layer. Expect questions about UID and GID mapping when host file ownership appears as root or unknown users inside the container. They may also ask about volume drivers or cloud storage mounts for distributed training environments.

ONE CONCRETE EXAMPLE: A solid command is docker run -p 8888:8888 -v $(pwd)/notebooks:/home/jovyan/work -v jupyter-data:/home/jovyan/data -v model-artifacts:/home/jovyan/models jupyter/datascience-notebook. Here the bind mount lets you edit notebooks in your IDE on the host, the named volume jupyter-data persists datasets across container restarts, and model-artifacts stores trained weights independently of the container lifecycle.