A municipal rack team is bringing up new DGX-class nodes for city services. What should they do with BMC before any in-band OS install?
Select an answer to reveal the explanation.
Short Explanation
BMC is the city’s backstage intercom to the server when the main OS stage is dark. Set credentials and out-of-band networking first so you can still reach the box before any in-band install—and do not park that path on guest Wi-Fi.
Full Explanation
Municipal DGX-class bring-up requires BMC credentials and out-of-band network reachability before any in-band OS install so operators can power-cycle, console, and recover the platform when the host OS is absent or broken. BMC is the independent management plane for city services hardware; configuring it first establishes identity, access control, and network path on the management fabric rather than discovering locked defaults during an outage. Leaving BMC on factory defaults until after the first production outage postpones hardening and invites unauthorized OOB access precisely when the node is already trusted with workloads. Disabling BMC permanently to free a PCIe lane for an extra NIC trades away the recovery channel HGX/DGX operations depend on and is not how municipal platforms gain capacity. Bridging BMC onto a public Wi-Fi guest SSID exposes chassis management to an untrusted wireless domain and violates least-privilege OOB design. Exam caveat: some imaging workflows briefly use vendor tools over OOB in parallel with OS install, but credentials and OOB reachability are still established first—not skipped. Operational check: from the city management jump host, authenticate to each new node’s BMC with the hardened credentials, open a remote console, and confirm power control works before starting the in-band OS image.