mediumMultiple ChoiceObjective-mapped
XK0-006 Practice Question: Refer to the exhibit
Exhibit
Mar 10 08:15:22 host dockerd[1234]: Time=2025-03-10T08:15:22.123Z Level=error msg="failed to mount local volume: mount :/var/lib/docker/volumes/vol1/_data:/data, flags: 0x1000: permission denied" Mar 10 08:15:22 host dockerd[1234]: Time=2025-03-10T08:15:22.124Z Level=error msg="error while mounting volume: permission denied"
Refer to the exhibit. A Docker container using a bind mount fails to start with a permission error. What is the most likely cause?
⚠ Common exam trap
CompTIA often tests the distinction between filesystem permission errors (e.g., user ID mismatch) and SELinux denials, where candidates mistakenly choose 'privileged mode' or 'daemon not root' because they overlook SELinux as the underlying cause in a bind mount context.
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
✓
SELinux is blocking the mount.
When a Docker container uses a bind mount and fails with a permission error, SELinux is a common cause because it enforces mandatory access controls that can block container processes from accessing host files. By default, SELinux labels container processes with a confined domain (e.g., container_t), and if the bind-mounted host directory lacks the proper SELinux context (e.g., container_file_t), the mount is denied. This is resolved by adding the `:Z` or `:z` flag to the bind mount in the Docker run command to relabel the host directory appropriately.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The container is running in privileged mode.
Why it's wrong here
Privileged mode would bypass permissions, not cause them.
- ✗
The Docker daemon is not running as root.
Why it's wrong here
Docker daemon always runs as root on Linux; this is unlikely.
- ✓
SELinux is blocking the mount.
Why this is correct
SELinux policies can restrict bind mounts, resulting in permission denied errors.
- ✗
The volume path on the host does not exist.
Why it's wrong here
A non-existent path causes a different error, not permission denied.
Visual reference
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
Courseiva writes every XK0-006 question from scratch — 979 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.