09 / 11

How do you handle persistent storage for databases?

Use Docker volumes. Define a named volume in the Compose file and mount it to the container's data directory. This ensures data survives container restarts or removal. You can also use bind mounts for development to sync live code changes

Difficulty: 5/10
Topics: Docker volumes, Data persistence, Stateful containers

Scenario Questions

0-2 years experience
  1. 1

    You need to run a MySQL container locally and keep the data after you stop and remove the container. How would you set that up?

  2. 2

    What happens to the database files if you start a PostgreSQL container without any volume configuration and then delete the container?

  3. 3

    How would you inspect where Docker is storing the data for a container that uses a bind mount?

2-5 years experience
  1. 1

    Our service uses a Redis container for caching, but we also need the cache to survive container restarts during a rolling deployment. What options would you consider and why?

  2. 2

    We noticed that after a Docker Compose down, the data in our MongoDB container is gone. Walk me through how you would modify the compose file to fix this.

  3. 3

    During a CI pipeline, a test suite spins up a PostgreSQL container, writes data, and then the container is removed. The next test run fails because the schema is missing. How would you adjust the setup to ensure a clean but persistent environment?

5-8 years experience
  1. 1

    Design a strategy for persisting data for a stateful MySQL cluster running in Docker Swarm, considering node failures and volume portability.

  2. 2

    Our production environment runs PostgreSQL in Docker on AWS EC2 instances with EBS volumes. We need to ensure zero data loss during instance replacement. What architecture would you propose?

  3. 3

    Explain the trade‑offs between using Docker named volumes, host bind mounts, and external storage plugins for a high‑throughput database in a microservices platform.

8+ years experience
  1. 1

    We are migrating a legacy monolithic app with an embedded SQLite DB to a containerized architecture across multiple data centers. How would you plan the data persistence strategy to support multi‑region failover and incremental migration?

  2. 2

    Across several teams, some services use Docker for stateless workloads while others need durable storage. How would you establish organization‑wide guidelines for volume management, backup, and disaster recovery?

  3. 3

    Our company wants to move from on‑prem Docker hosts to a Kubernetes‑based platform but keep the same database persistence guarantees. What architectural changes and migration steps would you recommend?

Follow-up Questions

  • Can you show the exact docker‑compose snippet you would use?
  • What failure scenarios did you consider with that storage choice?
  • How would you handle backups and restores for the persisted data?