Application Environment, Configuration and Security →hardMultiple ChoiceObjective-mapped

CKAD Practice Question: Application Environment, Configuration and Security

A Pod is configured with securityContext: { runAsUser: 1000, runAsGroup: 2000, fsGroup: 3000 }. The container's image runs a process that must listen on a TCP port below 1024 (e.g., port 80). The process is currently failing to start. What should you modify to allow the process to bind to a privileged port?

⚠ Common exam trap

Candidates often confuse allowPrivilegeEscalation with granting specific capabilities, or they incorrectly assume that dropping all capabilities is a safe default that still allows low-port binding, when in fact it removes the very capability needed.

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

✓

Add 'capabilities.add: [NET_BIND_SERVICE]' to the container's securityContext

The container process runs as a non-root user (UID 1000) and needs to bind to a privileged port (below 1024). Linux requires either root privileges or the CAP_NET_BIND_SERVICE capability to bind to ports below 1024. Adding this capability to the container's securityContext grants the process the necessary privilege without running as root, which is the correct and secure approach.

Answer analysis

Option-by-option breakdown

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

✗
Set 'allowPrivilegeEscalation: true'
Why it's wrong here
Setting allowPrivilegeEscalation: true does not confer the NET_BIND_SERVICE capability. This flag only permits a process to gain more privileges than its parent via mechanisms like setuid binaries or file capabilities; it does not add capabilities to the process's permitted or effective sets. Even with escalation allowed, a non-root user still lacks the specific capability required to bind to ports below 1024, so this option fails to solve the problem and unnecessarily increases security risk.
✗
Add 'capabilities.drop: [ALL]' to the container's securityContext
Why it's wrong here
Dropping all capabilities with capabilities.drop: [ALL] removes every Linux capability from the container's permitted and effective sets, including NET_BIND_SERVICE. Because the container runs as a non-root user (runAsUser: 1000) and has no capabilities, the kernel will reject any attempt to bind to a privileged port (<1024). This is the opposite of what is needed; it guarantees failure rather than enabling the required operation.
✓
Add 'capabilities.add: [NET_BIND_SERVICE]' to the container's securityContext
Why this is correct
Adding the NET_BIND_SERVICE capability to the container's securityContext grants the precise Linux capability that allows a non-root process to bind to Internet domain sockets with port numbers below 1024. This directly solves the port-binding problem while preserving the principle of least privilege, because the process continues to run as the unprivileged user 1000 and retains no other unnecessary capabilities. It is the correct, secure approach to exposing a service on a standard HTTP/HTTPS port.
✗
Set runAsUser: 0 to run as root
Why it's wrong here
Setting runAsUser: 0 makes the container execute as the root user, which by default has all capabilities including NET_BIND_SERVICE, so it could bind to low ports. However, this violates security best practices and common cluster policies: running as root increases the impact of container breakouts and is typically forbidden by Pod Security Admission (restricted profile) which requires runAsNonRoot and dropping ALL capabilities. Relying on root is a blunt, insecure workaround rather than a precise capability-based solution.

Go deeper

CKAD Practice Question: Application Environment, Configuration and Security

Why each option matters

Option-by-option breakdown

Related to this question