A LimitRange in the reporting namespace sets max memory to 1Gi for containers. A developer submits a Pod requesting 4Gi of memory. What is the expected result?
Select an answer to reveal the explanation.
Short Explanation
LimitRange max is a per-container size check at the door. Ask for 4Gi when max is 1Gi and admission says no. The scheduler never gets a chance to “sort of” honor an oversized request.
Full Explanation
A LimitRange in the reporting namespace that sets max memory to 1Gi causes admission to reject a Pod requesting 4Gi of memory because the request exceeds the LimitRange maximum. The object never reaches the scheduler as an admitted Pod. Municipal reporting namespaces use max limits to stop a single oversized analytics job from monopolizing node memory through an unchecked request field.
Claiming the scheduler binds the Pod and kubelet silently caps memory at 1Gi fails—LimitRange max is enforced at admission time, not as a silent runtime cap after binding. Claiming ResourceQuota automatically raises the namespace max to fit the 4Gi request fails; quotas and LimitRanges do not auto-expand maxima to satisfy oversized specs. Claiming only ClusterRoles can enforce LimitRange maxima and that namespace LimitRanges are advisory fails—namespace LimitRanges are active admission controls.
Exam caveat: max, min, default, and defaultRequest are different LimitRange fields; exceeding max rejects, while missing fields may be defaulted instead. Operational check: submit the 4Gi Pod, confirm the admission rejection message, lower the request to at most 1Gi or adjust the LimitRange through platform governance, and re-apply successfully.