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.

• ✗

  Setting resource limits on containers

  Why it's wrong here

  Setting resource limits on containers constrains CPU, memory, and I/O usage, ensuring that a single compromised or misbehaving container cannot starve the host or neighboring containers of resources. This is a proactive hardening measure that mitigates denial-of-service and resource-exhaustion attacks. Far from being a vulnerability, it is a required security control in multi-tenant container environments.

• ✗

  Configuring network policies to restrict traffic

  Why it's wrong here

  Configuring network policies to restrict traffic enforces a least-privilege model by defining which containers or pods can communicate with each other and with external endpoints. Without such policies, all inter-container traffic is typically allowed, expanding the blast radius of a compromise. Because this reduces the attack surface and limits lateral movement, it is a security best practice, not a risk.

• ✓

  Running containers in privileged mode

  Why this is correct

  Running containers in privileged mode grants them every Linux capability, disables seccomp and AppArmor/SELinux confinement, and exposes all host devices, effectively removing isolation between the container and the host kernel. An attacker who exploits a vulnerability in a privileged container can trivially escalate to full host control, making it one of the most dangerous container misconfigurations. During a vulnerability assessment, this should immediately be flagged as a critical finding.

• ✗

  Using read-only root filesystems

  Why it's wrong here

  Using read-only root filesystems prevents any process inside the container from writing to the container image's root filesystem layer, which stops attackers from dropping malware or modifying critical executables and configuration files. It forces any required writes to be done through explicit ephemeral volumes, maintaining filesystem integrity. This is a well-known defensive hardening technique that reduces the impact of a compromised container, so it is not a vulnerability.

• ✓

  Using hostPath mounts

  Why this is correct

  Using hostPath mounts allows a container to directly access a directory on the host's filesystem, bypassing the container's filesystem isolation. If the mounted path is broad or sensitive (e.g., /, /etc, or /var/run/docker.sock), a compromised container can read or tamper with host files, leading to host takeover. This is a high-risk configuration that should be carefully audited and scoped to read-only, least-privilege paths during vulnerability assessment.

Go deeper

Related to this question