Overview
Domain 1 is about the physical and firmware-level work that happens before any cluster software is installed. NVIDIA lists eleven objectives. They start with the order of deployment and validation steps and the network topologies used in AI factories, with separate compute, storage, in-band and out-of-band networks. They continue with initial configuration of the baseboard management controller (BMC), out-of-band (OOB) access and the Trusted Platform Module (TPM), then firmware upgrades on DGX and HGX systems with fault detection. The rest covers validating power and cooling, racking GPU-based servers, checking installed hardware, choosing and validating cable types and transceivers, installing physical GPUs, confirming the hardware can run workloads, and setting initial parameters for third-party storage.
At 31%, this is the second-largest domain, just behind Cluster Test and Verification. As of October 2026 NVIDIA lists the NCP-AII as active, with no announced retirement or replacement version.
How it's tested
NCP-AII questions in this domain are operational. They describe a stage of a DGX or HGX deployment and ask what should happen next, which tool or interface applies, or which component explains a symptom. Expect scenarios built around BMC access, firmware versions, rack power limits and cable choices rather than definitions.
-
Order the deployment steps
A partly completed rollout is described, and you pick the step that must come next, such as firmware baselining before burn-in.
-
Pick the right interface
A management task is described, and you choose between BMC web UI, Redfish, IPMI, the host OS or the OOB network.
-
Match cable to distance
A link length and speed are given, and you choose a DAC, active copper cable, active optical cable or transceiver with fiber.
A new HGX system shows only six of eight GPUs in nvidia-smi after racking. Reinstalling the driver is tempting, but a missing device at bring-up usually points to hardware or firmware. The better step is to check the BMC inventory and event log for the GPU baseboard, confirm the firmware bundle matches the validated set, and reseat or replace the tray if the BMC also misses the GPUs.
Objectives 11
Official objectives from the NVIDIA outline, in outline order.
1.1 Describe the sequence of events for deployment and validationThe ordered workflow from site readiness to an accepted cluster.
- What it means
- This objective covers the order in which an AI infrastructure deployment proceeds: site and rack readiness, receiving and racking servers, cabling, power-on, BMC setup, firmware baselining, OS and control plane installation, then single-node and multi-node validation and burn-in before handover.
- What to understand
- Each stage depends on the one before it. Firmware and BIOS settings must be at a known baseline before performance tests mean anything, and single-node tests come before multi-node fabric tests so that a bad node is not mistaken for a bad fabric. Burn-in is the last gate before users get access.
- How it shows up
- You are given a partially finished deployment and asked which step comes next or which step was skipped.
- Common confusion
- Running multi-node NCCL tests before confirming every node passes single-node checks.
1.2 Describe network topologies for AI FactoriesCompute, storage, in-band and out-of-band networks and how they are laid out.
- What it means
- This covers the separate networks in an NVIDIA AI factory or DGX SuperPOD design: the east-west compute fabric for GPU-to-GPU traffic, the storage fabric, the in-band management network and the out-of-band management network that reaches BMCs and switch management ports.
- What to understand
- The compute fabric uses InfiniBand or Spectrum-X Ethernet in a rail-optimized fat-tree, where the same-numbered NIC on every node connects to the same leaf group. Storage traffic is kept off the compute fabric where the design calls for it. The OOB network stays reachable even when hosts are down, which is why BMCs live there.
- How it shows up
- A traffic type or failure is described, and you identify which network carries it or how rails are wired.
- Common confusion
- Treating the OOB network as a path for workload or storage traffic.
1.3 Perform initial configuration of BMC, OOB, and TPMFirst access to the baseboard management controller, OOB addressing and TPM enablement.
- What it means
- This covers the first login to the BMC, changing default credentials, assigning a static or DHCP address on the OOB network, setting time and user accounts, and enabling the TPM in firmware so secure boot and measured boot can use it.
- What to understand
- The BMC runs independently of the host OS and exposes a web UI, Redfish and IPMI. It provides remote console, power control, sensor readings and the system event log. TPM must be enabled and owned before features that depend on it, and BMC credentials should be rotated before the server is exposed to any shared network.
- How it shows up
- A server cannot be managed remotely or fails a security check, and you choose the BMC or TPM setting to fix.
- Common confusion
- Assuming the BMC depends on the host OS being installed or booted.
1.4 Perform firmware upgrades (including on NVIDIA HGX™ systems) and fault detectionBringing BMC, BIOS, GPU tray, NVSwitch and NIC firmware to a validated set.
- What it means
- This covers upgrading the firmware components in DGX and HGX systems, including BMC, SBIOS, the HGX GPU baseboard with its NVSwitch and GPU firmware, and network adapter firmware, then checking for faults the update exposes.
- What to understand
- NVIDIA ships firmware as a validated bundle, and components should move together to that set rather than one at a time. On HGX systems the GPU baseboard is often updated through the BMC using Redfish, while DGX systems use NVIDIA's firmware update tooling such as nvfwupd. After updating, read versions back, check the event log and confirm every GPU and switch is present.
- How it shows up
- A firmware mismatch or failed update is described, and you choose the update path or the verification step.
- Common confusion
- Updating a single component in isolation and ignoring the version compatibility of the validated bundle.
1.5 Validate power and cooling parameterRack power budget, PSU redundancy, airflow and thermal readings.
- What it means
- This covers checking that each rack and server receives the power and cooling it was designed for: circuit and PDU capacity, power supply redundancy, inlet temperature, airflow direction and fan behavior, read through the BMC sensors and facility tools.
- What to understand
- A fully loaded eight-GPU system can draw around 10 kW, so rack density is limited by the power and cooling budget, not by rack units. All power supplies should be connected to independent feeds where redundancy is required. BMC sensor data shows inlet and component temperatures and supply status before and during load.
- How it shows up
- A server throttles or trips power under load, and you pick the power or cooling cause.
- Common confusion
- Validating power at idle only, which hides problems that appear under full GPU load.
1.6 Install GPU-based servers (SMI)Racking, mounting and first power-on of GPU servers.
- What it means
- This covers physically installing GPU servers: rail kits, weight and lift requirements, rack placement for airflow, connecting power and network, and the first power-on with checks through the BMC and the NVIDIA System Management Interface (nvidia-smi).
- What to understand
- GPU servers are heavy and deep, so mechanical lifts and correct rail kits matter, and placement must respect cold-aisle and hot-aisle orientation. After first boot, nvidia-smi confirms that the driver sees every GPU with the expected memory, power limit and clocks, which is the first software-level health check.
- How it shows up
- A newly installed server is described, and you choose the next installation or verification action.
- Common confusion
- Thinking nvidia-smi works before a GPU driver is loaded; the BMC is the check available without an OS.
1.7 Validate installed hardwareConfirming the delivered configuration matches the build specification.
- What it means
- This covers confirming that CPUs, memory, GPUs, NVSwitches, NICs, DPUs and drives in each server match the bill of materials and are detected correctly by the BMC and the operating system.
- What to understand
- Validation compares inventory from several views: BMC hardware inventory, lspci, nvidia-smi, and NVIDIA System Management (nvsm) on DGX systems. Missing memory DIMMs, a NIC in the wrong slot or a GPU running at reduced PCIe link width all count as failed validation, even if the server boots.
- How it shows up
- Inventory output is shown, and you spot the missing or degraded component.
- Common confusion
- Assuming a server that boots and runs nvidia-smi has passed hardware validation.
1.8 Describe and validate cable types and transceiversDAC, ACC, AOC and optical transceivers, form factors and validation.
- What it means
- This covers the cable and optic types used in GPU clusters, including passive copper DAC, active copper, active optical cables and transceivers with multimode or single-mode fiber, plus OSFP and QSFP form factors, and how to confirm that each link uses the intended part.
- What to understand
- Passive copper suits the shortest in-rack runs, active copper extends that a little, and optical links cover row and building distances. Quantum-2 InfiniBand switches use twin-port OSFP cages, so one switch-side optic can serve two 400G links. Tools such as mlxlink and mlxcables report the cable type, part number and link state.
- How it shows up
- A link distance and speed are described, and you choose the right cable or transceiver.
- Common confusion
- Mixing multimode and single-mode optics or fiber on the same link.
1.9 Install physical GPUsSeating PCIe GPUs or GPU trays, power connectors and slot placement.
- What it means
- This covers physically installing GPUs, either as PCIe cards in qualified servers or as SXM modules on an HGX baseboard, with correct slot choice, auxiliary power cables, retention and anti-static handling.
- What to understand
- PCIe GPU placement should follow the server's GPU-qualified slots so that each GPU sits near a NIC and CPU socket for good PCIe topology. SXM GPUs are installed on a baseboard and usually serviced as a tray. After installation, confirm PCIe link speed and width and that the BMC and nvidia-smi see every device.
- How it shows up
- A GPU is installed but underperforming or undetected, and you identify the installation cause.
- Common confusion
- Ignoring PCIe link width, so a GPU that works at x8 is accepted as healthy.
1.10 Validate hardware operation for workloadsShort functional tests that prove the hardware can carry real jobs.
- What it means
- This covers proving that the server is ready for workloads by running short diagnostics such as NVIDIA DCGM diagnostics, checking GPU-to-GPU and GPU-to-NIC topology, and confirming that NVLink, PCIe and network links run at their rated speeds.
- What to understand
- DCGM diagnostics run at increasing levels, from quick checks to long stress runs. nvidia-smi topo -m shows how GPUs, NICs and CPUs connect, which matters for placing work. This objective sits between hardware validation and the longer cluster tests in Domain 4.
- How it shows up
- Diagnostic or topology output is given, and you decide whether the node is ready for workloads.
- Common confusion
- Running only nvidia-smi and treating a device listing as a functional test.
1.11 Configure initial parameters for third party storageFirst connection of nodes to external storage systems.
- What it means
- This covers setting up the initial client-side parameters for partner storage, such as storage network interfaces, IP addressing, MTU, RDMA settings, client software and mount points, so that nodes can reach the shared file system.
- What to understand
- Third-party storage for DGX systems is usually a parallel or high-performance network file system on its own fabric or VLAN. MTU must match end to end, RDMA must be enabled where the storage uses it, and the vendor's client must be compatible with the installed OS and network driver stack.
- How it shows up
- Nodes cannot mount storage or get poor throughput, and you choose the misconfigured parameter.
- Common confusion
- Leaving a mismatched MTU between the host interface and the storage network.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Deployment order
Rack, cable, power, BMC, firmware baseline, OS and control plane, single-node tests, multi-node tests, burn-in.
- Remember
- Firmware baselining precedes any performance testing.
- Tested as
- Sequence questions.
- Trap
- Testing performance on nodes with mixed firmware.
-
BMC
An independent controller for remote power, console, sensors, inventory and event logs.
- Remember
- It works without a host OS.
- Tested as
- Remote management and fault questions.
- Trap
- Assuming the OS must be up to use it.
-
Redfish vs. IPMI
Redfish is the modern REST API for BMCs; IPMI is the older protocol.
- Remember
- HGX firmware updates commonly go through Redfish.
- Tested as
- Interface choice questions.
- Trap
- Picking IPMI for tasks that need Redfish.
-
TPM
A hardware security chip that stores keys and measurements for secure and measured boot.
- Remember
- Enable it in firmware before using it.
- Tested as
- Security setup questions.
- Trap
- Expecting the OS to enable it alone.
-
Validated firmware bundle
A tested set of BMC, BIOS, GPU, NVSwitch and NIC firmware versions.
- Remember
- Move all components to the same set.
- Tested as
- Firmware questions.
- Trap
- Upgrading one component out of sequence.
-
Rail-optimized topology
Each node's same-numbered NIC connects to the same leaf group.
- Remember
- It keeps GPU-to-GPU traffic for a rail on one switch hop.
- Tested as
- Topology questions.
- Trap
- Cabling NICs to arbitrary leaves.
-
Four networks
Compute, storage, in-band management and out-of-band management.
- Remember
- OOB carries BMC traffic only.
- Tested as
- Network role questions.
- Trap
- Sending workload traffic over OOB.
-
Rack power budget
Per-rack power and cooling capacity limits how many GPU servers fit.
- Remember
- An eight-GPU server can draw around 10 kW.
- Tested as
- Power planning questions.
- Trap
- Planning by rack units instead of kilowatts.
-
Cable reach
DAC for short in-rack runs, active copper slightly longer, optics for longer runs.
- Remember
- Distance and speed decide the cable.
- Tested as
- Cable choice questions.
- Trap
- Using passive copper beyond its reach.
-
Twin-port OSFP
One OSFP cage on Quantum-2 switches carries two 400G ports.
- Remember
- Switch-side and host-side optics differ.
- Tested as
- Transceiver questions.
- Trap
- Assuming the same optic fits both ends.
-
nvidia-smi topo -m
Shows how GPUs, NICs and CPUs are connected.
- Remember
- Use it to check affinity and NVLink presence.
- Tested as
- Workload readiness questions.
- Trap
- Ignoring topology when GPUs show up.
-
DCGM diagnostics
NVIDIA's GPU diagnostic tool with run levels from quick to extended.
- Remember
- Higher levels take longer and stress more.
- Tested as
- Health validation questions.
- Trap
- Using level 1 as a full stress test.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Management interfaces
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| BMC web UI | Browser access to console, power and sensors | Interactive, one server at a time | Using it for fleet-wide updates |
| Redfish | REST API on the BMC | Scriptable and current standard | Confusing it with in-band tools |
| IPMI | Legacy BMC protocol | Older, limited command set | Choosing it for HGX firmware updates |
| In-band tools | nvidia-smi, nvsm, lspci in the OS | Need a booted OS and driver | Expecting them on a dead host |
Cable and optic types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Passive DAC | Copper with no signal electronics | Shortest reach, lowest power | Using it across racks |
| Active copper | Copper with signal conditioning | Somewhat longer copper reach | Treating it as optical |
| AOC | Fiber with fixed optics at both ends | Longer reach, not separable | Expecting to swap the fiber |
| Transceiver plus fiber | Pluggable optics with separate fiber | Longest reach, flexible | Mixing multimode and single-mode |
AI factory networks
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Compute fabric | East-west GPU traffic | Highest bandwidth, rail-optimized | Sharing it with OOB |
| Storage fabric | Traffic to shared storage | Separate path or VLAN | Mixing it into compute rails |
| In-band management | Provisioning and SSH to hosts | Requires a running OS | Confusing it with OOB |
| OOB management | BMC and switch management ports | Works when hosts are down | Routing data through it |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Driver first
- What candidates pick
- Reinstall the GPU driver when nvidia-smi shows fewer GPUs than expected.
- Why it looks right
- Driver problems are common.
- Why it's wrong
- If the BMC inventory is also missing the GPU, the cause is hardware or firmware, and a driver reinstall changes nothing.
Clue to watch for The BMC inventory or event log also lacks the device.
-
Update one part
- What candidates pick
- Upgrade only the component named in a release note.
- Why it looks right
- It looks like the smallest change.
- Why it's wrong
- NVIDIA validates firmware as a bundle, so a lone update can create an untested combination across BMC, BIOS, GPU and NVSwitch.
Clue to watch for The question mentions a validated or recommended firmware set.
-
OOB carries data
- What candidates pick
- Use the out-of-band network for storage or job traffic.
- Why it looks right
- It is already cabled to every node.
- Why it's wrong
- OOB is a low-bandwidth management network for BMCs and switch management, not a data path.
Clue to watch for The traffic described is workload, storage or provisioning data.
-
Idle power check
- What candidates pick
- Sign off power validation from idle readings.
- Why it looks right
- Idle readings are easy to collect.
- Why it's wrong
- Peak draw only appears under full GPU load, so idle checks miss tripped breakers and supply overloads.
Clue to watch for The failure occurs only when jobs start.
-
Rack units decide density
- What candidates pick
- Fill a rack by available rack units.
- Why it looks right
- Space looks like the limit.
- Why it's wrong
- Power and cooling capacity cap GPU server density long before space runs out.
Clue to watch for A rack kilowatt limit appears in the scenario.
-
One optic fits all
- What candidates pick
- Use the same transceiver model on switch and host ends.
- Why it looks right
- The link speed is the same.
- Why it's wrong
- Switch and adapter cages and port counts can differ, such as twin-port OSFP on Quantum-2 switches.
Clue to watch for The ends of the link are different device types.
Answer framework
Use these steps when a bring-up question asks what to do next or why a new server is not ready.
- Place the scenario in the deployment sequence and confirm that every earlier stage, such as racking, power and BMC access, is complete.
- Decide whether the task needs the out-of-band path through the BMC or an in-band tool that depends on a booted OS and driver.
- Check firmware against the validated bundle before blaming software, and update components together rather than one at a time.
- Verify physical factors next: power feeds and budget, airflow direction, cable type against distance, and GPU slot and PCIe link width.
- Close with a functional check such as DCGM diagnostics and topology review, and only then move the node to cluster-level testing.
Practice question
Want more like this? The NCP-AII practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Treat this domain as a physical runbook. Start with the deployment sequence and the four networks, because most scenarios assume you know where a node is in the rollout and which network a task uses. Draw a small rail-optimized fabric and the OOB network on paper until you can explain each connection.
Next, work through BMC tasks hands-on if you have any access to a server with a BMC: change credentials, read sensors and the event log, use the remote console and try a Redfish query. Then read the DGX H100 user guide sections on firmware updates and the DGX best practices guide, focusing on why firmware is applied as a validated bundle.
After that, study cables and transceivers by distance and form factor using the NVIDIA cabling and cable management guides listed on the certification page. Practice reading nvidia-smi, nvidia-smi topo -m and lspci output to spot missing GPUs or narrow PCIe links. Finish with DCGM diagnostic levels and the client settings for partner storage. Because this domain and Domain 4 make up nearly two thirds of the exam, give them the largest share of your study time and revisit missed practice questions by objective.
FAQ
How much of the NCP-AII is System and Server Bring-Up?
System and Server Bring-Up is 31% of the NCP-AII, the second-largest domain after Cluster Test and Verification at 33%. With 70 to 75 questions, that is roughly 22 questions.
Is the NCP-AII exam being retired or replaced?
As of October 2026, NVIDIA's certification page lists the NCP-AII as active with no retirement date or new version announced. The certification is valid for two years, and recertification is by retaking the exam.
What is the difference between the BMC and OOB network?
The BMC is the controller inside each server that handles remote power, console and sensors. The OOB network is the separate management network the BMCs and switch management ports connect to.
Why are firmware updates done as a bundle?
NVIDIA tests specific combinations of BMC, BIOS, GPU baseboard, NVSwitch and NIC firmware. Moving all components to that tested set avoids untested combinations that can cause faults or poor performance.
Do I need to memorize cable reach numbers?
Know the relative order: passive copper is shortest, active copper is a little longer, and optical cables and transceivers cover longer runs. Know form factors such as OSFP and QSFP and that switch and host ends can differ.
What does validating hardware for workloads involve?
It means running functional checks such as DCGM diagnostics, reviewing GPU, NIC and CPU topology, and confirming NVLink, PCIe and network links run at rated speeds before the node joins cluster tests.
How deep does the storage objective go?
It covers the first client-side settings for partner storage: interfaces, addressing, MTU, RDMA and client software. Storage testing and optimization come later in Domains 4 and 5.
Other Artificial Intelligence & Machine Learning certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
You have covered deployment order, BMC and TPM setup, firmware bundles, power, cabling and GPU installation. Check whether you can choose the right next step in a bring-up scenario.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the NCP-AII AI tutor Get any concept explained your way