Civic payment Pods must receive Guaranteed QoS so they are last to be evicted under memory pressure. What resources configuration achieves that for every container?
Select an answer to reveal the explanation.
Short Explanation
Guaranteed is the matching-luggage rule: request and limit tags must say the same weight for CPU and memory on every container. PriorityClass can help scheduling preference, but it does not invent Guaranteed by itself.
Full Explanation
Civic payment Pods that must receive Guaranteed QoS so they are last to be evicted under memory pressure need CPU and memory requests set equal to their matching limits for every container. That configuration produces Guaranteed QoS, which the kubelet treats preferentially during memory-pressure eviction compared with Burstable and BestEffort. Payment paths in municipal clusters often require this posture for critical transactional workloads.
Setting only memory requests and leaving CPU unset so Guaranteed is inferred fails—Guaranteed requires CPU and memory requests and limits aligned for each container. Omitting all resources and adding a high priorityClassName instead fails because priority and QoS are distinct; omitting resources yields BestEffort, which is evicted earliest. Setting limits twice as high as requests on every container forces Burstable, not Guaranteed.
Exam caveat: a single container with mismatched CPU or memory fields can demote the whole Pod from Guaranteed; init containers count too. Operational check: set equal requests and limits for CPU and memory on each container, apply, verify status.qosClass is Guaranteed, and document why payment Pods use that class.