Application Deployment and Security →mediumMultiple Select

200-901 Application Deployment and Security Practice Question

A team is hardening a Kubernetes deployment that exposes a web API. They want to reduce the impact of a container compromise and enforce network segmentation. Which TWO configurations should they apply? (Choose two.)

⚠ Common exam trap

The trap here is treating general reliability or exposure settings such as resource limits or a LoadBalancer Service as security hardening controls.

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

✓

Define a NetworkPolicy that allows ingress only from the required client pods and denies all other traffic.

Reducing the impact of a compromise requires limiting the container's privileges and its ability to communicate laterally. Running as a non-root user removes a key privilege, while a default-deny NetworkPolicy with explicit allows enforces segmentation. Image pull policy, external exposure, and resource limits address other concerns and do not satisfy the stated security objectives.

Answer analysis

Option-by-option breakdown

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

✗
Expose the API through a Service of type `LoadBalancer` for external access.
Why it's wrong here
A `LoadBalancer` Service exposes the API externally, which increases the attack surface rather than reducing it. The scenario asks for limiting the impact of a compromise and enforcing segmentation; publishing the service broadly works against that goal. This option addresses reachability, not security posture.
✗
Set `imagePullPolicy: Always` on the container so the newest image is always used.
Why it's wrong here
`imagePullPolicy: Always` affects when the kubelet pulls an image; it does not restrict container privileges or network access. While it can help ensure updates are applied, it does not reduce the impact of a compromise or provide segmentation. It may even introduce risk by pulling an unexpected tag, but it is not a hardening control for this scenario.
✓
Define a NetworkPolicy that allows ingress only from the required client pods and denies all other traffic.
Why this is correct
A NetworkPolicy with a default-deny posture and explicit allow rules segments the network so a compromised pod cannot reach unrelated workloads. It is the native Kubernetes mechanism for pod-level network segmentation. Applying it to the API deployment restricts lateral movement, which is exactly the segmentation goal described in the scenario.
✓
Set `securityContext.runAsNonRoot: true` in the pod specification.
Why this is correct
Running as a non-root user limits what a compromised process can do inside the container and on mounted volumes. If the process escapes to the node, it does not have root privileges. This is a standard pod security control that reduces privilege escalation risk and aligns with the restricted Pod Security Standard, making it a correct hardening measure for the API deployment.
✗
Add resource requests and limits for CPU and memory to the container.
Why it's wrong here
Resource requests and limits protect node stability and can reduce the impact of resource exhaustion, but they do not restrict privileges or network paths. They are not a substitute for a non-root security context or network segmentation. This option is a reliability control, not the containment and segmentation controls the scenario requires.

Go deeper

200-901 Application Deployment and Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question