mediumMultiple Choice
XK0-006 Practice Question: A sysadmin wants to run a containerized web…
A sysadmin wants to run a containerized web application using Podman. The container needs to persist data across restarts. Which approach ensures data persistence?
⚠ Common exam trap
Test-takers frequently confuse container restart policies (like `--restart always`) with data persistence, assuming that keeping the container running automatically preserves its data, when in fact the container's writable layer is ephemeral and lost on removal.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Mount a host directory as a volume using -v.
Mounting a host directory as a volume using the `-v` flag (e.g., `podman run -v /host/path:/container/path ...`) ensures that data written inside the container is stored on the host filesystem. This data persists independently of the container's lifecycle, surviving container restarts, stops, or even removal. Podman, like Docker, treats volumes as external storage that outlives the container.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run the container with --restart always.
Why it's wrong here
--restart always only controls whether Podman restarts a stopped container; it does not decouple storage from the container's writable layer, so data still vanishes when the container is removed or recreated. Restart policies suit keeping long-running services alive, not persisting state; a named volume mounted into the container is required here.
- ✓
Mount a host directory as a volume using -v.
Why this is correct
Binding a host directory with -v maps storage outside the container's writable layer, so data survives container restarts and recreation. The writable layer is ephemeral and is destroyed with the container, whereas the bind mount persists on the host filesystem, satisfying the persistence constraint.
- ✗
Include the data using COPY in the Dockerfile.
Why it's wrong here
COPY bakes data into an image layer at build time, so runtime writes land in the container's ephemeral writable layer and are lost on recreation. COPY suits shipping static configuration or seed files into an image, not persisting dynamic application data; a named volume mounted at runtime is needed instead.
- ✗
Use docker commit to save changes.
Why it's wrong here
docker commit captures a container's writable layer into a new image, but that image is not referenced by the running container's configuration, so a recreated container still starts from the original image without the changes. Committing suits snapshotting a container for debugging or image building, not runtime persistence; a mounted volume is required.
Go deeper
Related to this question
About these practice questions
One of 781 original XK0-006 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This XK0-006 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the XK0-006 exam.