Files
rootnode-academy/content/root/root-04-containers-and-docker/m05-container-storage/03-knowledge-check.md
T
ced4568andClaude Sonnet 5 682ef2de47 feat(root04): author Containers & Docker
Adds all 8 ROOT 04 modules (why containers exist, images & containers, Docker CLI, container
networking, container storage, Dockerfile & image build, Docker Compose, containers →
Kubernetes) — 43 activities, using the nested Docker Engine Phase 6D built and tested. Modules
1, 2, and 8 are conceptual (no lab by design) — the honest bridge module (M8) explicitly names
what Kubernetes adds beyond what this course already taught, without re-teaching Kubernetes
itself.

Adds 5 new hands-on Docker scenarios plus 2 MCQs, all against the real nested Docker Engine:
docker-cli-basics (run/exec/inspect a real container), docker-container-networking (a genuine
"works internally, unreachable from host" port-publishing failure, diagnosed and fixed by
recreating the container with the correct `-p` flag), docker-container-storage (a real
destroy/recreate cycle proving named-volume persistence, not just described), docker-build-image
(a real Dockerfile, a real build, a real custom image run), and docker-compose-multiservice (a
real two-service Compose application with a real published port). All tested end-to-end via the
real scenario-validation API, including negative tests.

Wires rootnode-containers-assessment (2 required + 4 random-draw scenarios) using the existing
Phase 3B assessment engine.

This completes the entire ROOT_ Foundations sequence (ROOT 01-04) — see
docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 17:08:14 -05:00

40 lines
1.3 KiB
Markdown

# Knowledge Check: Container Storage
---
**1. By default, what happens to data written inside a running container when that container is
destroyed?**
*Answer:* It's lost permanently — a container's writable layer is disposable by default; nothing
persists unless a volume or bind mount was explicitly configured.
---
**2. What's the actual difference between a bind mount and a named volume?**
*Answer:* A bind mount connects a specific HOST filesystem path directly into the container
(tightly coupled to that host's exact layout). A named volume is storage Docker manages
independently of any specific host path, making it more portable and the production-appropriate
choice.
---
**3. Does `docker stop` (without removing) test whether a container's data actually persists?**
*Answer:* No — stopping doesn't touch the writable layer at all. Only fully removing
(`docker rm`) and recreating the container is a real test of persistence.
---
**4. What Kubernetes concept is this module's volume idea the direct foundation for?**
*Answer:* PersistentVolume/PersistentVolumeClaim — the same persistence concept, generalized
across an entire cluster instead of one machine.
## Instructor Notes
**Facilitation:** Question 3 is worth emphasizing — it's a genuine, common mistake in verifying
persistence claims.
**Approximate timing:** 5 minutes.