NCP-AIO Workload Management Practice Question
An administrator supports a multi-tenant cluster where several teams share GPUs. Leadership requires that each team's batch jobs receive a fair share of GPU time and that one team cannot monopolize devices by submitting thousands of low-priority pods. Jobs are submitted through a Kubernetes-native batch scheduler that supports queueing. Which approach best enforces fair-share GPU allocation across teams?
⚠ Common exam trap
The trap here is equating namespace isolation or equal priorities with fairness, when fair share actually requires a scheduler that tracks per-queue usage and applies weighted allocation across teams.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Define per-team queues with weighted fair-share policies and GPU-aware scheduling in the batch scheduler
Weighted fair-share queues in a GPU-aware batch scheduler allocate device time proportionally among teams and enforce queue-level limits, preventing a single tenant from monopolizing GPUs by volume. The default scheduler, equal priorities, or static node partitioning cannot provide dynamic proportional sharing or gang scheduling for distributed jobs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use node taints and tolerations to dedicate specific GPU nodes to each team permanently
Why it's wrong here
Taints and tolerations create static, exclusive partitions, which reduces overall utilization and does not adapt to fluctuating demand. If one team's nodes sit idle while another team is backlogged, capacity is wasted. This is hard partitioning rather than fair-share allocation, and it fails the requirement for proportional sharing across teams.
- ✗
Assign each team a distinct Kubernetes namespace and rely on the default kube-scheduler for GPU placement
Why it's wrong here
Namespace separation provides naming and policy boundaries but the default kube-scheduler processes pods individually on a first-come basis with no notion of team fair share. A team submitting many pods would still win capacity. It also lacks gang scheduling, so distributed GPU jobs can deadlock waiting for all workers to be placed.
- ✓
Define per-team queues with weighted fair-share policies and GPU-aware scheduling in the batch scheduler
Why this is correct
A GPU-aware batch scheduler with per-team queues and weighted fair-share policies allocates GPU capacity proportionally across tenants and prevents any single team from monopolizing devices through sheer volume. It coordinates gang scheduling and quotas at the queue level, directly delivering the fairness and anti-monopolization requirement for shared GPU clusters.
- ✗
Apply identical PriorityClass values to all team pods so the scheduler treats them equally
Why it's wrong here
Equal priorities remove ordering but do not create proportional sharing; the team that submits first or most still consumes the GPUs. Fair share requires accounting of historical and pending usage per team, which PriorityClass alone cannot express. It also provides no queue-level quotas to stop one team from flooding the cluster.
About these practice questions
This NCP-AIO question is part of Courseiva's 309-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official NVIDIA exam blueprint
This NCP-AIO practice question is part of Courseiva's free NVIDIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NCP-AIO exam.