A student namespace on the school-district cluster risks claiming all GPUs. What Kubernetes control fits?
Select an answer to reveal the explanation.
Short Explanation
ResourceQuotas are the school hallway pass limit—student namespaces get a fair GPU allowance. Cluster-admin for students and kube-system dumping are how labs melt the cluster.
Full Explanation
Applying Kubernetes ResourceQuotas so the student namespace cannot claim all civic GPUs fits school-district multi-tenancy because ResourceQuotas bound CPU, memory, and extended resources (including GPUs) per namespace. Student labs need room to learn without monopolizing the district cluster that also serves faculty and production education services.
Removing all quotas so student labs can monopolize district GPUs fails by multi-tenant isolation: unconstrained namespaces capture the pool. Granting students cluster-admin so they can raise quotas themselves fails by privilege concept—students must not own cluster policy. Putting every student pod in kube-system to inherit unlimited capacity fails by namespace hygiene: kube-system is for cluster components, not class workloads seeking unlimited GPUs.
Exam caveat: ResourceQuota is necessary but often paired with LimitRanges, network policies, and admission controls. The question focuses on preventing one student namespace from claiming all GPUs—ResourceQuota is the direct control named in that objective.
Operational check: set a ResourceQuota on the student namespace including nvidia.com/gpu (or the district's GPU resource name), attempt an over-quota job, confirm admission rejection or pending within limit, and verify faculty namespaces retain their allocations.