CKAD Practice Question: Application Environment, Configuration and Security

Answer analysis

Option-by-option breakdown

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

• ✗

  The node will not evict pods if limits are set

  Why it's wrong here

  Setting memory limits does not exempt a pod from node-level eviction. The kubelet continuously monitors the node's memory pressure—driven by the sum of all container usage relative to the node's allocatable capacity—and when pressure exceeds a threshold, it selects pods for eviction in a QoS-based order, regardless of whether limits are configured. Limits only affect the pod's QoS class (via the ratio of requests to limits) and the kernel's OOM score, not the eviction decision itself.

• ✗

  This pod will be evicted first because it has a memory limit

  Why it's wrong here

  Having a memory limit makes this pod Burstable (since requests are set but do not equal limits), and the eviction order places BestEffort pods—those with no requests or limits—first. A Burstable pod is never evicted 'first' simply because a limit exists; instead, it is evicted only after all BestEffort pods are removed, and before Guaranteed pods. The presence of a limit actually marks the pod as higher quality than BestEffort, so it is protected somewhat, not preferentially evicted.

• ✓

  BestEffort pods first, then this Burstable pod, then Guaranteed pods last

  Why this is correct

  Under node memory pressure, the kubelet selects eviction victims by QoS class: it first targets BestEffort pods (no requests/limits), then Burstable pods (requests set, limits may differ), and finally Guaranteed pods (requests equal limits). Because this deployment sets only a memory request, it is Burstable, so it will be evicted after every BestEffort pod on the node has been reclaimed and before any Guaranteed pod is touched. This ordering is a core part of the Kubernetes eviction mechanism and helps protect the most critical workloads during resource shortages.

• ✗

  All pods are evicted simultaneously

  Why it's wrong here

  Eviction under memory pressure is a graduated, ordered process, not a simultaneous cleanup. The kubelet computes a list of candidate pods sorted by QoS class—BestEffort, then Burstable, then Guaranteed—and evicts pods one by one, stopping once the node returns to an acceptable memory level. If pressure persists, it continues down the list; but pods are removed sequentially, and Guaranteed pods are always the last to be touched, so all pods never disappear at the same moment.

Go deeper

Related to this question