Cluster Management and Orchestration
Free NVIDIA-Certified Professional: AI Infrastructure practice — 6 questions on Cluster Management and Orchestration, with explanations. No sign-up. Full 12-question mixed test →
A company runs large-scale LLM training jobs (multi-node, multi-GPU, requiring full un-partitioned GPU access per job) and also serves many small inference microservices that each need only a fraction of a GPU. They want to run both workload types on the same physical GPU cluster managed by Kubernetes with the NVIDIA GPU Operator, without under-utilizing GPUs for inference. Which configuration BEST meets these requirements?
Separating node pools lets inference use MIG's hardware-isolated fractional GPUs for efficient sharing, while training jobs retain full, un-partitioned GPUs with full memory/NVLink access needed for multi-node scaling — labels/taints direct each workload type to the correct pool.
A platform team needs strict per-tenant fair-share scheduling with backfill, gang scheduling for tightly-coupled multi-node MPI training jobs, and detailed job accounting across departments, on a bare-metal DGX SuperPOD. Which orchestration approach is MOST appropriate?
Slurm, provisioned and managed through BCM, natively supports gang scheduling, backfill, QOS-based fairshare, and granular per-department job accounting — exactly the HPC/MPI training requirements described.
An administrator wants to enable GPU time-slicing on a Kubernetes cluster using the NVIDIA GPU Operator so that 4 pods can share a single physical GPU for lightweight inference. Which is the correct configuration approach?
GPU Operator time-slicing is configured via a ConfigMap specifying resources and a 'replicas' value, referenced by the ClusterPolicy's devicePlugin.config, and applied to nodes via a label so the device plugin advertises multiple virtual GPU slots.
An organization operates a cluster containing both DGX H100 and DGX A100 nodes managed under a single Base Command Manager head node. They need different software images, driver versions, and Slurm partitions for each hardware generation while maintaining a single pane of management. What is the BEST approach in BCM?
BCM node categories allow per-hardware-generation software images, driver versions, and kernel modules to be provisioned consistently, and categories can be mapped directly to distinct Slurm partitions — preserving a single management pane.
Which statement correctly differentiates MIG (Multi-Instance GPU) from time-slicing for GPU sharing on NVIDIA GPUs in a Kubernetes environment?
MIG physically partitions an Ampere/Hopper-generation GPU's SMs and memory into isolated instances with dedicated bandwidth, while time-slicing simply schedules full-GPU compute time slices across processes with no memory partitioning or isolation.
A shared GPU Kubernetes cluster serves two tenants: Tenant A runs sensitive fine-tuning jobs that must run exclusively on H100 nodes, and Tenant B runs general inference workloads that must never be scheduled onto those H100 nodes. Both tenants use separate namespaces. Which combination of controls BEST enforces this isolation while still allowing tenant-based scheduling?
Taints on H100 nodes repel any pod lacking the matching toleration, and enforcing that toleration exclusively through an admission control policy (with Tenant A's node affinity/nodeSelector further targeting those nodes) guarantees only Tenant A's pods can ever land there.
Ready for the real thing?
The full course: two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed explanations.
$199.99 $34.99 with code FREETEST33 — valid through September 9.
Get my $34.99 deal →