A school-district AI lab's first rack failed because teams installed the OS before power and cooling validation. What risk does that out-of-order sequence create?
Select an answer to reveal the explanation.
Short Explanation
Installing the OS before proving power and cooling is like painting the classroom before the HVAC passes inspection—you might finish the pretty work and still cook the gear. Facility shortfalls show up as heat, brownouts, or flaky nodes after imaging, which is a painful place to learn the lesson.
Full Explanation
Installing an OS before power and cooling validation on a school-district AI lab rack creates a real hardware and stability risk, not a paperwork delay. Dense GPU servers assume PDU capacity, circuit balance, and cooling setpoints that match nameplate and measured load; skipping those checks can leave newly imaged hosts exposed to brownouts, thermal throttling, unexpected shutdowns, or component stress. Once the OS and local state exist, recovering from facility shortfalls is harder because teams must chase flaky software symptoms that are actually environmental. Claiming thermal and power faults cannot affect installed software ignores how GPU nodes behave under insufficient watts or airflow: crashes, ECC storms, and reimaging loops follow. OS-first sequencing does not upgrade HGX firmware to a safe train; firmware currency is a separate coordinated gate. It also does not guarantee nvidia-smi will enumerate every GPU regardless of facility limits—power capping, thermal trips, and failed devices can still hide or drop GPUs. Exam caveat: imaging media may boot on under-provisioned power briefly, which fools teams into thinking day-0 is done; sustained AI load is the real facility test. Operational check: before imaging school-lab nodes, verify PDU ratings versus planned GPU load, confirm cooling setpoints and airflow, then power-soak or vendor health-check the rack and only afterward install the OS.