CS0-003 Vulnerability Management Practice Question

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