A county app occasionally leaks memory and risks starving other workloads on the same node. Which container setting caps that usage?
Select an answer to reveal the explanation.
Short Explanation
Requests help the scheduler reserve a seat; limits are the hard ceiling. If a leaky app blows past its memory limit, the runtime can OOM-kill it so neighbors survive.
Full Explanation
A county app that occasionally leaks memory and risks starving other workloads on the same node should set limits.memory, which caps consumption and can OOM-kill the container if exceeded. Memory limits are the hard cap enforced by the runtime and cgroup; exceeding them risks OOMKill. That protects neighboring civic workloads on the node from an unbounded leak in one container while still allowing the app to run within a defined envelope.
requests.memory alone is used for scheduling capacity reservation and QoS; it does not by itself hard-kill at the request value the way a limit does. A readiness probe path that doubles as a memory quota is not a memory cap. The Service sessionAffinity field set to ClientIP affects session stickiness, not memory isolation between neighbors.
Exam caveat: requests versus limits define QoS classes and eviction behavior under node pressure. Operational check: set memory limits on the leaky county container, reproduce pressure carefully in a non-prod namespace, and confirm cgroup enforcement while neighbors remain protected. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.