CKS Minimize Microservice Vulnerabilities Practice Question
You are reviewing a pod specification that mounts a hostPath volume to /var/run/docker.sock. Which security risk does this present, and what is the recommended mitigation?
⚠ Common exam trap
The trap here is thinking that a readOnly volume mount or disabling hostNetwork/hostPID mitigates the Docker socket risk, when the socket itself grants full daemon control regardless of those settings.
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
✓
It allows the container to control the Docker daemon, potentially leading to host compromise; mitigate by avoiding hostPath mounts to the Docker socket and using a least-privilege approach.
Mounting the Docker socket gives the container control over the Docker daemon, enabling container escapes and host compromise. The correct mitigation is to avoid such mounts and use least-privilege alternatives. Read-only flags, hostNetwork, and hostPID settings do not mitigate this specific risk.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
It allows the container to access the host's PID namespace; mitigate by setting hostPID: false.
Why it's wrong here
The Docker socket mount does not grant access to the host PID namespace. hostPID is a separate field that shares the host's process namespace. The socket mount allows interacting with the Docker daemon, which can be used to escape the container, but it is not the same as hostPID access. Setting hostPID: false does not address the socket mount risk.
- ✓
It allows the container to control the Docker daemon, potentially leading to host compromise; mitigate by avoiding hostPath mounts to the Docker socket and using a least-privilege approach.
Why this is correct
Mounting the Docker socket gives the container full control over the Docker daemon, which can be used to start privileged containers, access the host filesystem, and escalate to root on the node. The recommended mitigation is to avoid mounting the Docker socket and instead use a secure API or a dedicated sidecar with least privilege. This is a well-known container escape vector.
- ✗
It allows the container to read only the Docker logs; mitigate by setting readOnly: true on the volume mount.
Why it's wrong here
Mounting the Docker socket does not merely allow reading logs; it provides full API access to the Docker daemon. Setting readOnly: true on the volume mount does not prevent the container from sending write operations to the socket, because the socket is a special file and the read-only flag does not restrict the API calls. The risk is much greater than log reading.
- ✗
It exposes the host's network stack; mitigate by setting hostNetwork: false.
Why it's wrong here
Mounting the Docker socket does not expose the host network stack. hostNetwork is a separate field that shares the host's network namespace. The Docker socket grants control over the Docker daemon, which is a different and more severe risk. Setting hostNetwork: false does not mitigate the socket mount vulnerability.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This CKS practice question is part of Courseiva's free CNCF 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 CKS exam.