Application Deployment and Security →mediumMultiple Select

200-901 Application Deployment and Security Practice Question

A platform team is hardening a containerized application before production. They want to reduce the attack surface of the running containers themselves. Which two practices directly reduce the privileges available to a compromised container process? (Choose two.)

⚠ Common exam trap

The trap here is conflating general hardening measures like read-only filesystems or slim base images with actual privilege reduction.

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 container process as a non-root user via the USER instruction or --user flag

Privilege reduction focuses on what the process is allowed to do at runtime. Running as a non-root user removes the broad powers of uid 0, and dropping Linux capabilities strips specific kernel-level abilities even from processes that retain elevated identity. Read-only filesystems, smaller images, and health checks improve other properties such as immutability, vulnerability count, and availability, but none of them lower the privilege ceiling of a compromised process.

Answer analysis

Option-by-option breakdown

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

✓
Run the container process as a non-root user via the USER instruction or --user flag
Why this is correct
Running as an unprivileged user means a process that escapes the application cannot perform root-only operations such as binding low ports, modifying system files, or loading kernel modules. This is one of the most effective single mitigations because most container escapes assume root inside the namespace. It directly limits the capabilities available after compromise.
✓
Drop unnecessary Linux capabilities with --cap-drop and add back only what is required
Why this is correct
Docker grants a default set of capabilities even to non-root processes in some configurations. Dropping all and adding back only required ones, such as NET_BIND_SERVICE for a privileged port, removes abilities like raw socket creation or filesystem mounting. This shrinks what a compromised process can do within the kernel, directly reducing effective privilege.
✗
Set the read-only flag on the container filesystem with --read-only
Why it's wrong here
A read-only root filesystem prevents persistent modification of the image layers, which limits some post-exploitation techniques, but it does not reduce the privileges the process holds. A root process on a read-only filesystem can still read secrets, make network calls, and exploit kernel interfaces. It constrains writability rather than privilege level, so it is not one of the two privilege-reducing practices.
✗
Add a HEALTHCHECK instruction to the Dockerfile so the orchestrator can restart unhealthy containers
Why it's wrong here
Health checks improve availability by detecting and restarting failed processes, but they do not restrict what those processes are permitted to do. A compromised container that still passes its health check continues running with unchanged privileges. Availability monitoring is orthogonal to privilege reduction, so this does not meet the requirement.
✗
Use a smaller base image such as alpine to reduce the image size
Why it's wrong here
A smaller base image reduces the number of installed packages and therefore potential vulnerabilities, but it does not change the runtime privileges of the container process. A root process in an alpine image is still root. Image size and privilege level are separate concerns, so this does not satisfy the stated goal of limiting process privileges.

Go deeper

200-901 Application Deployment and Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question