CS0-003 Vulnerability Management Practice Question
A security analyst is performing a vulnerability assessment and needs to identify potential misconfigurations in a Kubernetes cluster. Which TWO of the following are common Kubernetes misconfigurations that should be checked? (Select TWO.)
⚠ Common exam trap
CS0-004 often tests whether candidates can distinguish between secure configurations (network policies, non-root users, ConfigMaps for non-sensitive data) and actual misconfigurations (privileged containers, hostPath mounts), so candidates must know which options represent risks rather than best practices.
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
✓
Privileged containers
Option A (Privileged containers) is correct because running a container with securityContext.privileged: true grants it nearly all capabilities of the host, effectively removing container isolation and allowing access to host devices and kernel features, which is a classic Kubernetes misconfiguration flagged by tools like kube-bench and CIS benchmarks. Option C (hostPath mounts) is correct because mounting a host directory or file into a pod (volumes.hostPath) exposes the node's filesystem to the container, enabling privilege escalation, persistence, or node compromise if an attacker gains code execution. Option B (Using network policies) is not a misconfiguration — network policies are a security best practice that restrict pod-to-pod traffic, and their absence would be the issue, not their use. Option D (Running containers as non-root user) is not a misconfiguration — setting runAsNonRoot: true or a non-zero runAsUser is a hardening measure that reduces risk. Option E (Using ConfigMaps for non-sensitive data) is not a misconfiguration — ConfigMaps are the intended mechanism for non-confidential configuration data, whereas Secrets should be used for sensitive values.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Privileged containers
Why this is correct
Privileged containers run with all Linux capabilities and disable isolation mechanisms such as seccomp, AppArmor, or SELinux, effectively granting the process root-equivalent access to the host kernel and devices. This means a malicious or compromised workload inside the container can directly attempt to escape the container and compromise the underlying node. Thus, enabling privileged mode is a critical misconfiguration that should be avoided in standard deployments.
- ✗
Using network policies
Why it's wrong here
Applying network policies is a security-enhancing practice that uses rules to restrict inter-pod communication and enforce segmentation within a cluster. Since they reduce the potential for lateral movement, they are a recommendation rather than a vulnerability. Misconfigurations here might involve overly permissive policies, but the act of using them is not itself a flaw and does not introduce risk.
- ✓
hostPath mounts
Why this is correct
hostPath mounts map a host directory or file into a container, giving the container persistent, often high-privileged, access to the underlying node's filesystem. If the container is compromised, an attacker can read sensitive host files, tamper with system components, or plant malicious binaries, potentially leading to node or cluster compromise. Unless the hostPath is strictly scoped and the container is trusted, this poses a significant security risk and is a common misconfiguration.
- ✗
Running containers as non-root user
Why it's wrong here
Running containers as a non-root user is a fundamental defense-in-depth measure because it limits the container's privileges on the host and inside the container itself, reducing the impact of container breakout errors. It is explicitly recommended by Kubernetes hardening guides and is not a misconfiguration; instead, failing to do so (especially with a root user and default capabilities) would be the vulnerability.
- ✗
Using ConfigMaps for non-sensitive data
Why it's wrong here
Using ConfigMaps for non-sensitive configuration data such as application settings, feature flags, or connection strings for non-secret values is an accepted and appropriate pattern in Kubernetes. It only becomes a problem if developers mistakenly place secrets, like passwords or API keys, inside a ConfigMap instead of a Secret object. As described, this option is not a misconfiguration and poses no additional security risk.
Go deeper
Related to this question
Learn chapter
Network Forensics: Packet Capture Analysis
Key term
Privilege escalation
Privilege escalation is when a user or attacker gains more access or control over a system than they are supposed to have.
Key term
Vulnerability assessment
A vulnerability assessment is a systematic review of security weaknesses in an information system, evaluating if the system is susceptible to any known vulnerabilities, assigning severity levels, and recommending remediation or mitigation.
About these practice questions
Courseiva writes every CS0-004 question from scratch — 701 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CS0-004 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 CS0-004 exam.