Public-health students deploy apps without resource fields. How can the namespace automatically supply default container CPU and memory at admission?
Select an answer to reveal the explanation.
Short Explanation
LimitRange is the namespace's defaulting ruler—admit a Pod with missing resources and it can fill in defaults or reject out-of-bounds values. PDBs and Ingress annotations are not resource defaulting tools.
Full Explanation
When public-health students deploy apps without resource fields, the namespace can automatically supply default container CPU and memory at admission via a LimitRange that defaults or constrains container resources for Pods in the namespace. LimitRange can inject default request and limit values and enforce min/max, which is the standard namespaced guardrail for teaching clusters and shared civic namespaces that otherwise see BestEffort sprawl.
A PodDisruptionBudget that injects defaults when minAvailable is unset does not provide resource defaults—PDBs limit voluntary disruptions. A PriorityClass named default that silently writes requests into every Pod misunderstands PriorityClass, which only carries scheduling priority. An Ingress annotation that propagates cluster-wide resource defaults is not how container resource defaults work.
Exam caveat: LimitRange defaults apply at admission for Pods in that namespace; existing Pods are unchanged until recreated. Operational check: apply a LimitRange with default CPU and memory, create a student Pod without resources, and confirm defaults appear on the admitted PodSpec. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.