A developer creates a Pod in a namespace that has a LimitRange defining default CPU and memory limits. The Pod template omitted resources entirely. After admission, what typically appears on the container?
Select an answer to reveal the explanation.
Short Explanation
LimitRange is the form that fills in blank resource fields with house defaults. Leave requests and limits empty and those defaults get stamped on. It is not the same thing as the namespace’s total ResourceQuota budget.
Full Explanation
A developer creates a Pod in a namespace that has a LimitRange defining default CPU and memory limits, and the Pod template omitted resources entirely. After admission, LimitRange default limits—and often default requests—are applied to the container spec, so the stored object shows resource fields the developer did not type. Civic namespaces use this mechanism to reduce accidental BestEffort Pods when teams forget to author resources blocks.
Claiming the Pod is rejected because omitting resources is always forbidden when any LimitRange exists fails—default and defaultRequest exist specifically to fill omissions, while min and max may still reject extreme values. Claiming only ResourceQuota can inject defaults and that LimitRange only deletes oversized Pods misstates LimitRange responsibilities. Claiming kubelet invents BestEffort values at runtime without changing the stored Pod spec fails because LimitRange defaulting is visible on the admitted API object.
Exam caveat: fields the developer explicitly sets are not overwritten by LimitRange defaults; only absent fields are filled from the LimitRange. Operational check: create an omit-resources Pod, inspect kubectl get pod -o yaml for injected CPU and memory values, and document those defaults for municipal application teams.