Study Hub / Docker Certified Associate (DCA) / Domain 6.0
Docker Certified Associate (DCA) Domain 6.0: Storage and Volumes — Explained
Domain 6.0 is the smallest DCA domain and pure concept: where container data lives, what survives what, and which storage option fits which need. Short, sweet, and very testable.
The persistence problem
Containers are ephemeral by design: the writable layer exists only while the container does. Anything worth keeping must live outside the container's lifecycle:
- Volumes — Docker-managed storage in /var/lib/docker/volumes. Created explicitly or anonymously, shared between containers, backed up and migrated by Docker tooling. The production answer.
- Bind mounts — map any host path into the container. Maximum flexibility, zero portability: the container now depends on that host's filesystem layout.
- tmpfs mounts — RAM-only storage, never touches disk. For sensitive temporary data (decrypted secrets in use) and high-speed scratch.
Volume lifecycle and sharing
- Named vs. anonymous volumes — named volumes (
db-data) are deliberate and reusable; anonymous volumes (random hex names) are usually accidents of Dockerfiles — they accumulate and confuse. Name your volumes. - Sharing — multiple containers mount the same volume: the classic sidecar pattern (app writes logs, shipper reads them). Concurrent writes from multiple containers need application-level coordination — Docker won't serialize for you.
- Drivers — volume drivers extend storage beyond local disk: NFS, cloud block storage, Ceph.
docker volume create --driver— the data can live anywhere the driver reaches. - Backup and migration — back up volumes (not containers): run a throwaway container mounting the volume and archive it, or use driver-level snapshots. The volume is the data.
- Pruning —
docker volume pruneremoves unused volumes. Anonymous volumes from dead containers are the usual disk-eaters — another reason to name volumes.
The must-memorize table: storage options compared
One table for the whole domain.
| Option | Lives | Survives container deletion? | Portable? |
|---|---|---|---|
| Named volume | Docker-managed area | Yes | Yes — moves with Docker tooling/drivers |
| Anonymous volume | Docker-managed area | Yes (until pruned) | Poorly — random names confuse |
| Bind mount | Arbitrary host path | Yes (host file) | No — tied to host layout |
| tmpfs | Host RAM | No | N/A — ephemeral by design |
| Writable layer | Storage driver | No | No |
Try it: 4 sample questions
Sample questions to check your understanding of this domain. Answers and full reasoning are tucked under each one.
1. A container writes processed files to its writable layer. The container is removed during an upgrade. What happens to the files?
- A. A. They persist in the image
- B. B. They are lost — the writable layer dies with the container
- C. C. They move to a volume automatically
- D. D. They are backed up by the daemon
Show answer & reasoning
B. The writable layer's lifetime is the container's. Nothing migrates it, nothing backs it up — it simply ceases to exist. Data that matters must be written to a volume (or bind mount) from the start. "Written inside the container, container deleted" → gone.
2. Two containers need to share a set of TLS certificates, read-only, without baking them into images. What is the cleanest approach?
- A. A. COPY the certs into each image
- B. B. A named volume (or bind mount) with the certs, mounted read-only into both containers
- C. C. Pass the certs as ENV variables
- D. D. Use tmpfs so they never touch disk
Show answer & reasoning
B. Shared read-only storage decouples the certs from the images: rotate the files once, both containers see the update, no rebuilds. Baking into images (A) means rebuilding to rotate; ENV (C) exposes secrets in inspectable config; tmpfs (D) evaporates on restart.
3. An admin runs `docker volume prune` on a host with many stopped containers that used anonymous volumes. What happens?
- A. A. Nothing — prune only affects images
- B. B. Unused anonymous volumes are deleted, reclaiming their disk space
- C. C. Running containers lose their volumes
- D. D. Named volumes are deleted too
Show answer & reasoning
B. Prune removes unused volumes — anonymous volumes from long-dead containers are the classic reclaim. Running containers' volumes are in use and untouched (C); named-but-unused volumes are also removed, which is why the command asks for confirmation. Anonymous volumes: name them or lose track of them.
4. A container processes credit-card data in memory and must guarantee no trace touches the disk, even in swap or crash dumps. Which mount fits?
- A. A. A named volume with encryption
- B. B. tmpfs — RAM-only, never written to disk
- C. C. A bind mount to /tmp
- D. D. The writable layer
Show answer & reasoning
B. tmpfs lives purely in RAM: nothing is written to disk, so disk forensics finds nothing. (Disable swap or use encrypted swap for the full guarantee — tmpfs can be swapped.) Volumes (A) and bind mounts (C) are disk-backed by definition; the writable layer (D) is disk-backed too.
This was one domain. The simulator drills all 6.
This free preview covered Storage & Volumes (Domain 6.0, 10%). Not covered here: Orchestration (Domain 1.0, 25%); Security (Domain 5.0, 15%). Swarm orchestration and Docker security — the most scenario-heavy DCA material — stay in the paid guide and practice bank. The ByteBar Practice Exam Simulator drills every domain with 1,000 exam-style questions — $9.99 one-time unlocks all 28 exams. Prefer to read? The full DCA Study Guide is in the ByteBar shop on Etsy.
Practice Exam Simulator — $9.99 one-time, all 28 exams Full Study Guides on Etsy