Confusing container filesystem with host filesystem
2. Which Docker command correctly mounts a host directory /data to a container directory /app/data to persist data?
easy
A. docker run --env /data:/app/data myimage
B. docker run -p /data:/app/data myimage
C. docker run --link /data:/app/data myimage
D. docker run -v /data:/app/data myimage
Solution
Step 1: Identify volume mount syntax
The correct syntax to mount a host directory is using -v host_path:container_path.
Step 2: Match the correct option
docker run -v /data:/app/data myimage uses -v /data:/app/data, which is the correct way to mount the host directory.
Final Answer:
docker run -v /data:/app/data myimage -> Option D
Quick Check:
Volume mount uses -v host:container [OK]
Hint: Use -v host_path:container_path to mount volumes [OK]
Common Mistakes:
Using -p instead of -v for volumes
Confusing --link or --env with volume mounts
Forgetting to specify both host and container paths
3. Consider this Dockerfile snippet:
FROM alpine
RUN echo "Hello" > /greeting.txt
CMD cat /greeting.txt
If you run this container, then modify /greeting.txt inside the running container to "Hi", then restart the container, what will cat /greeting.txt output?
medium
A. Hi
B. Hello
C. File not found error
D. Empty output
Solution
Step 1: Understand Dockerfile build vs container runtime
The file /greeting.txt is created during image build with content "Hello".
Step 2: Recognize ephemeral container filesystem
Changes made inside a running container (changing to "Hi") are lost after restart because the container filesystem resets.
Final Answer:
Hello -> Option B
Quick Check:
Container restart resets filesystem, original file restored [OK]
Hint: Changes inside container lost on restart; image files stay [OK]
Common Mistakes:
Assuming changes inside container persist after restart
Confusing image build files with runtime changes
Expecting file to be missing after restart
4. You ran a container and created a file inside it. After restarting, the file disappeared. You want to keep the file persistent. Which of these fixes the problem?
medium
A. Restart the container with --restart=always flag.
B. Increase container memory limit.
C. Use a Docker volume to store the file outside the container.
D. Run the container with --rm option.
Solution
Step 1: Identify cause of file loss
Files inside container are lost on restart because filesystem is ephemeral.
Step 2: Choose method to persist data
Using a Docker volume stores data outside container, preserving files across restarts.
Final Answer:
Use a Docker volume to store the file outside the container. -> Option C
Quick Check:
Volumes keep data persistent beyond container life [OK]
Hint: Persist files with volumes, not restart flags or memory [OK]
Common Mistakes:
Thinking restart flags keep files
Confusing memory limits with filesystem persistence
Using --rm removes container on exit, losing files
5. You want to run a container that writes logs to /var/log/app.log inside the container. You want these logs to persist even if the container is removed or recreated. Which Docker run command achieves this?
hard
A. docker run -v /host/logs/app.log:/var/log/app.log myapp
B. docker run --rm myapp
C. docker run -v /host/logs:/var/log/app.log myapp
D. docker run -v /host/logs/app.log:/var/log myapp
Solution
Step 1: Understand volume mount for specific file
To persist a single log file, mount the host file to the container file path.
Step 2: Analyze options
docker run -v /host/logs/app.log:/var/log/app.log myapp mounts /host/logs/app.log to /var/log/app.log inside container, persisting logs exactly.
Step 3: Why other options fail
docker run -v /host/logs/app.log:/var/log myapp tries to mount file to directory path (invalid). docker run -v /host/logs:/var/log/app.log myapp tries to mount directory to file path (invalid). docker run --rm myapp removes container on exit, losing logs.
Final Answer:
docker run -v /host/logs/app.log:/var/log/app.log myapp -> Option A
Quick Check:
Mount host file to container file for persistent logs [OK]
Hint: Mount host file to container file path to persist logs [OK]
Common Mistakes:
Mounting directory to file path (invalid)
Using --rm which deletes container and files
Mounting directory when only file persistence needed
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.