Technical Mid Level

How do you handle persistent data in Docker? Compare volumes, bind mounts, and tmpfs mounts, and explain when to use each.

Quick Tip

Match mount type to use case: "Named volumes for database data — portable and Docker-managed. Bind mounts for development — I see code changes instantly. tmpfs for secrets or scratch data that should never touch disk."

What good answers include

Volumes: managed by Docker, stored in /var/lib/docker/volumes/, portable, and the recommended approach for persistent data. Bind mounts: map a specific host path into the container — useful for development (live code reloading) but tied to the host filesystem structure. tmpfs: stored in memory only, never written to disk — good for sensitive data that should not persist. Key considerations: volumes survive container removal, bind mounts depend on host paths, and data in the container writable layer is lost when the container is removed. Strong candidates discuss: named volumes for databases, bind mounts for development workflows, volume drivers for cloud storage (EFS, Azure Files), and the importance of not storing application state in the container layer.

What interviewers are looking for

Tests data management understanding. Candidates who lose data because they did not mount a volume for their database have a fundamental gap. Those who understand the three mount types and their trade-offs handle stateful containers correctly.

← All Docker questions