NVIDIA-Certified Associate: AI Infrastructure and Operations (NCA-AIIO) practice questions

A research team submits a distributed training job that requires 16 GPUs spread across 4 nodes. The job fails to start because the scheduler allocates only 3 of the 4 nodes before a competing job claims the fourth. Which scheduling strategy is specifically designed to prevent this outcome?

• AGang scheduling, which holds all required nodes in reserve and starts all processes simultaneouslycheck_circle Correct
• BFair-share scheduling, which divides available GPU resources proportionally among all active users
• CPreemptive scheduling, which evicts lower-priority jobs to free resources for higher-priority requests
• DBackfill scheduling, which slots smaller jobs into idle windows left by reserved future allocations

Why A is correct: Gang scheduling ensures every process in a distributed job is launched at the same time across all required nodes. This atomic allocation eliminates the partial-allocation deadlock where some nodes are claimed by competing jobs before the full gang is assembled.

Why B is wrong: Fair-share scheduling governs resource equity across users over time, but it does not guarantee that all nodes for a single job are reserved simultaneously, so the same partial-allocation race can still occur.

Why C is wrong: Preemptive scheduling can reclaim resources from lower-priority jobs, but it does not inherently co-allocate all nodes at once. A preempted node may become available only after the remaining nodes are already taken by other jobs.

Why D is wrong: Backfill scheduling improves cluster utilisation by filling gaps around reserved slots, but it is not the mechanism that guarantees simultaneous allocation of all nodes for a single multi-node job.

A team is preparing to train a large language model whose total memory footprint - accounting for model parameters, intermediate activations, and optimiser states - comfortably exceeds the capacity of a single GPU. Which infrastructure decision most directly addresses this constraint?

• AReplace the GPUs with DPUs to offload memory management to a dedicated data-processing unit.
• BSwitch to a higher-throughput Ethernet fabric between nodes, as network latency is the bottleneck that prevents the model fitting in memory.
• CIncrease fast NVMe storage capacity so the model can be streamed from disk into GPU memory in chunks during the forward pass.
• DDistribute the model across multiple GPUs so the combined memory across the pool can hold all training states simultaneously.check_circle Correct

Why A is wrong: DPUs handle networking, storage, and security offload from the CPU; they have no general-purpose tensor compute memory that substitutes for GPU VRAM in training workloads.

Why B is wrong: Network throughput affects gradient synchronisation speed but does not change how much GPU memory is available; upgrading the fabric cannot make a model fit in memory it does not have.

Why C is wrong: While CPU offload and disk-backed parameter swapping exist as workarounds, they introduce severe performance penalties; the standard architectural decision is to add GPUs until combined memory is sufficient, not to rely on disk streaming.

Why D is correct: When a model's parameters, activations, and optimiser states together exceed one GPU's memory, spreading them across multiple GPUs is the standard solution - each GPU holds a partition of the total working set.

An HPC cluster runs a mix of short interactive jobs and long batch training jobs. The site administrator wants to ensure that no single user or project monopolises GPU nodes over a rolling seven-day window. Which Slurm mechanism is most appropriate for implementing this policy?

• AJob array limits, which cap the number of simultaneously running tasks within a single array submission
• BFair-share scheduling with decay-based usage accounting, which deprioritises users who have consumed a large share of resources recentlycheck_circle Correct
• CPartition time limits, which define the maximum wall-clock duration allowed per job in a given queue
• DGRES (Generic Resource) constraints, which restrict how many GPU resources a job may request in a single submission

Why A is wrong: Job array limits constrain concurrency within a single submission from one user, but they do not account for historical consumption across all users over a time window.

Why B is correct: Slurm's fair-share plugin tracks each account's historical resource consumption using a decay factor over a configurable window. Users or accounts that have consumed more than their proportional share receive lower scheduling priority, naturally redistributing access without hard quotas.

Why C is wrong: Partition time limits bound how long a single job may run, which can indirectly reduce monopolisation, but they do not track cumulative usage across users over a rolling period.

Why D is wrong: GRES constraints limit the resource request for an individual job submission but do not track cumulative consumption across multiple jobs or users over time.