Foundational AI infrastructure and operations knowledge - GPU architecture, the NVIDIA software stack, data centre networking, and operations - for the NVIDIA-Certified Associate AI Infrastructure and Operations exam.
Free sample questions
No account needed. Every question has a worked explanation, just like the full bank.
lock_openFree sampleAI Operationsmedium
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
Explain how gang scheduling prevents partial-allocation failures in multi-node distributed GPU training jobs. Gang scheduling (also called co-scheduling) treats all processes of a distributed job as a single indivisible unit. The scheduler withholds the job from running until every required slot on every required node is available at the same instant, then launches all ranks together. This is essential for tight-coupling frameworks such as MPI or PyTorch distributed training where all ranks must communicate from the first iteration. Without gang scheduling, partial allocations stall indefinitely, wasting the already-allocated GPUs and blocking other work.
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.
lock_openFree sampleAI Operationsmedium
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
Identify the Slurm fair-share mechanism that enforces proportional GPU access across users over a rolling time window. Slurm's fair-share scheduler computes a usage factor for each account based on allocated resources over a decay window (commonly seven days). Jobs from accounts whose recent usage is below their fair-share target receive a priority boost, while accounts that have over-consumed receive a penalty. This dynamic reprioritisation prevents any single user or project from perpetually dominating the cluster without requiring hard quotas that would leave GPUs idle when under-utilised accounts are inactive.
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.
lock_openFree sampleAI Operationsmedium
A platform team is migrating containerised inference services to a Kubernetes cluster that has GPUs. Multiple small inference replicas each need a fraction of a single GPU rather than an entire device. Which approach best enables multiple pods to share one physical GPU on that cluster?
- ARequest multiple CPU cores per pod and rely on the GPU driver to time-share the device automatically across pods
- BSet Kubernetes CPU and memory requests per pod and let the default scheduler bin-pack the inference replicas onto the GPU node with no GPU-sharing driver
- CDeploy a fractional GPU scheduler such as Run:ai or NVIDIA MIG, which partitions the GPU and exposes sub-GPU resource fractions to the Kubernetes schedulercheck_circle Correct
- DSet resource requests to zero for the GPU field so pods schedule freely, then configure a node taint to attract only inference workloads
Describe how fractional GPU scheduling enables multiple Kubernetes pods to share a single physical GPU for inference workloads. Standard Kubernetes GPU device plugins expose whole GPUs as integer resources, so each pod receives one or more complete devices. Fractional GPU solutions such as the Run:ai scheduler or NVIDIA MIG break this constraint. Run:ai provides a virtual GPU abstraction that enforces per-pod memory and compute limits on a shared physical GPU. MIG statically partitions supported NVIDIA GPUs into isolated instances with their own memory bandwidth and compute resources, each presented to Kubernetes as a separate allocatable resource. Both approaches allow multiple smaller inference pods to coexist on one GPU, improving utilisation without interference.
Why A is wrong: Standard GPU drivers do not automatically time-share a GPU across independent processes in proportion to pod CPU requests. Without an explicit partitioning or virtualisation layer, each pod would attempt to use the full device, causing contention.
Why B is wrong: CPU and memory requests constrain only host resources; they do not partition or arbitrate the GPU. With no GPU-sharing driver the default scheduler still treats the GPU as one indivisible device, so the first pod claims it and the remaining replicas are starved or fail to schedule.
Why C is correct: Fractional GPU schedulers extend the Kubernetes device-plugin model to advertise sub-GPU resources. Run:ai intercepts scheduling and enforces GPU memory and compute quotas per pod. NVIDIA Multi-Instance GPU (MIG) partitions a physical GPU into independent instances with dedicated memory and compute slices, each schedulable as a distinct Kubernetes resource.
Why D is wrong: Setting GPU requests to zero causes the Kubernetes scheduler to ignore GPU availability entirely; pods would be placed without any GPU allocation or enforcement, leading to uncontrolled device access and potential out-of-memory failures.
Frequently asked questions
- How many questions are on the NCA-AIIO exam?
- The NVIDIA-Certified Associate: AI Infrastructure and Operations (NCA-AIIO) exam has 50 questions and runs for 60 minutes. The format is multiple choice, online proctored.
- What score do I need to pass NCA-AIIO?
- NVIDIA does not publish a fixed pass mark for NCA-AIIO, so treat any "X%" figure you see elsewhere as unofficial. Examworthy gives you a per-domain readiness score so you can judge when you are ready across every domain.
- How much does the NCA-AIIO exam cost?
- The exam costs 125 USD to sit. Practising on Examworthy is free to start, with a worked explanation on every question.
- Is there a NCA-AIIO practice exam?
- Yes. Examworthy's exam mode runs a timed NCA-AIIO practice exam (mock) paced to match the real exam, scored per domain so you can see exactly where you stand against the blueprint. Timed mocks are free with an account.
- How does Examworthy help me prepare for NCA-AIIO?
- Every practice question carries a worked explanation and a per-distractor rationale, mapped to the official blueprint domains. You learn why each answer is right or wrong, not just the letter.
- Is Examworthy affiliated with NVIDIA?
- No. Examworthy is not affiliated with or endorsed by NVIDIA. Our questions are original, blueprint-aligned practice material; we never reproduce live exam items.
Examworthy is not affiliated with or endorsed by NVIDIA. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. NCA-AIIO and related marks belong to their respective owners.
