Building-permits developers notice pods consume more CPU and memory than their manifests declare. A LimitRange applies default requests and limits in the namespace. What is the most accurate explanation?
Select an answer to reveal the explanation.
Short Explanation
If the YAML looks skinny but the scheduler sees a heavier ask, a LimitRange probably stamped defaults at admission. The cluster fills in what the developer left blank.
Full Explanation
LimitRange objects can apply default requests and limits at admission when developers omit them. Building-permits pods that appear to consume—or at least to be scheduled with—more CPU and memory than their sparse manifests declare are often explained by those admission-applied defaults changing the actual resources the scheduler and runtime enforce. The cluster fills in what the YAML left blank at the front door. kubectl top does not always double reported usage for civic namespaces; that claim invents a metrics distortion that is unrelated to LimitRange behavior. PersistentVolumeClaims do not automatically inject CPU requests equal to storage size; volume capacity and CPU requests are separate resource dimensions. NetworkPolicies do not force every pod into Guaranteed QoS; QoS class derives from how requests and limits are set on containers, not from network policy objects. Exam caveat: After LimitRange defaults apply, QoS class and scheduling fit can diverge from the author’s mental model—always inspect the live pod spec with kubectl get pod -o yaml. Operational check: Describe LimitRanges in the namespace, compare live pod requests and limits to the developer manifest, and adjust defaults or educate teams so permits workloads receive intentional sizing.