A team wants to omit memory limits on a bursty reporting container so it can use spare node memory. What risk must they accept?
Select an answer to reveal the explanation.
Short Explanation
No memory limit is an open bar—great until one guest drains the keg. The app can burst into spare RAM, but it can also starve neighbors or trigger node OOM. Know that tradeoff before you skip limits.
Full Explanation
A team that wants to omit memory limits on a bursty reporting container so it can use spare node memory must accept that without a memory limit the container can consume unbounded memory and create noisy-neighbor pressure or OOM conditions on the node. Spare capacity is useful for seasonal civic reporting, but unprotected burst can starve co-located workloads or contribute to node-level memory failure.
Claiming omitting limits automatically converts the Pod to Guaranteed QoS and pins it to a single CPU fails—Guaranteed requires equal requests and limits, and omitting memory limits does not pin CPUs. Claiming the kubelet will refuse to start any container that lacks a memory limit in every namespace overstates universal behavior, even though some namespaces enforce limits via LimitRange. Claiming Services will stop load-balancing to Pods that have requests but no limits invents a Service rule that does not exist.
Exam caveat: a LimitRange or policy controller may still require memory limits in that namespace even if the team prefers to omit them. Operational check: if omitting memory limits, set a meaningful memory request, monitor node memory closely, and prefer a high-but-finite limit for production reporting rather than unbounded growth.