Application Deployment and Security →mediumMultiple Select

200-901 Application Deployment and Security Practice Question

A security review of a containerized application finds that the running process has far more privileges than it needs. Which TWO changes reduce the attack surface of the container at runtime? (Choose two.)

⚠ Common exam trap

Many candidates confuse isolation features with privilege reduction, so flags like --privileged or a mounted Docker socket feel like convenience features when they actually expand the attack surface.

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

✓

Run the application process as a non-root user inside the container.

Least privilege for containers is enforced along two axes: the identity the process runs under and the kernel capabilities it retains. Running as a non-root user removes root-owned access inside the container, while dropping unneeded capabilities prevents privileged kernel operations even if the process is compromised. Options that grant daemon access, full privileges, or broader network exposure all move in the opposite direction.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Add the --privileged flag so the container can access all devices directly.
Why it's wrong here
The privileged flag disables most container isolation and grants the container nearly all host capabilities and device access. It is the opposite of least privilege and would make the review's findings worse. Any compromise under this setting can lead directly to full host control.
✓
Run the application process as a non-root user inside the container.
Why this is correct
By default many images run as root, so a compromised process would hold root privileges inside the container namespace and could exploit any kernel or mount weakness. Specifying a non-root user in the image or at run time removes that privilege. It directly reduces what an attacker can do after a successful compromise, which is exactly the goal of the review.
✗
Publish the container's port to the host with the -p 0.0.0.0:8080:8080 mapping.
Why it's wrong here
Binding to all host interfaces exposes the service to every network that can reach the host, which widens exposure rather than narrowing privileges. Port mapping controls reachability, not the capabilities or identity of the process. It does nothing to address the excessive privileges identified in the review.
✓
Drop unnecessary Linux capabilities with --cap-drop and add back only those required.
Why this is correct
Containers receive a default set of Linux capabilities that include operations the application may never need. Dropping them and selectively re-adding only the required ones follows least privilege at the kernel level. If the process is exploited, the missing capabilities block actions such as raw socket creation or filesystem mounting, shrinking the blast radius.
✗
Mount the host's Docker socket into the container so it can manage sibling containers.
Why it's wrong here
Mounting the Docker socket gives the container control over the Docker daemon, which effectively grants root-equivalent access to the host. An attacker who compromises the application could start privileged containers or read host files. This dramatically increases the attack surface rather than reducing it.

Go deeper

200-901 Application Deployment and Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question