A school-district GPU lab needs some nodes reserved for district operations and others available as preemptible student capacity. Which BCM approach fits?
Select an answer to reveal the explanation.
Short Explanation
You can use BCM categories to keep district-ops nodes reserved while student capacity remains preemptible. Giving students unrestricted reboot rights or disabling preemption undermines that balance. Removing node category labels also leaves the scheduler without the distinctions it needs.
Full Explanation
A school-district GPU lab that needs reserved district-ops capacity alongside preemptible student capacity should express that tenancy with BCM node categories and related scheduler policy. Categorizing nodes as reserved district-ops versus preemptible student pools gives the scheduler metadata to protect critical district operations while offering elastic capacity to students. Giving every student unrestricted reboot rights on all nodes undermines the reserved pool and risks disrupting district-ops hosts. Disabling preemption so student jobs always block district operations reverses the intended priority and can prevent essential district work from proceeding. Removing node category labels prevents the scheduler from applying separate policies to each tenancy, eliminating the distinctions this design requires. Exam caveat: reserved versus preemptible capacity is modeled through BCM categories and preemption policy, not by granting unrestricted student control or removing categories. Practical check: label the reserved and preemptible pools in BCM, bind district-ops and student queues accordingly, then run a student job that should preempt only preemptible nodes and verify district-ops nodes remain protected.