Practice tests · 30 questions

Kubernetes, Slurm & GPU Scheduling: the practice test

Device plugins and dynamic resource allocation, MIG, MPS and time-slicing, gang scheduling with Kueue and Volcano, topology-aware placement, multi-tenancy and quotas, Slurm versus Kubernetes, containers and cold starts: the platform round at CoreWeave, Modal, Nebius and every GPU cloud. This test drills exactly that: 10 easy, 12 medium and 8 hard questions, every one explained, every explanation linking into the worked material.

Set up your test

Topic

How confident are you feeling?

Questions

10 in this pool · about 7 min

Reveal answers

Sample questions, answered

easy · sample

How does a Kubernetes pod get a GPU, and what does the scheduler know about that GPU?

The pod mounts /dev/nvidia0 directly and the scheduler tracks nothing about GPUs

✓A device plugin advertises GPUs as a count; the scheduler knows nothing about topology

The container runtime allocates GPUs at random and reports the choice back to the scheduler afterward

The scheduler reads nvidia-smi on every node at each scheduling cycle to find idle GPUs and their topology

The NVIDIA device plugin (installed by the GPU Operator) registers nvidia.com/gpu as an extended resource with a count per node; a pod requests a number of them, the scheduler places the pod where the count fits, and the plugin assigns specific devices at container start by setting the visible-devices environment and mounting the device files. The scheduler sees only a count, not which GPUs share an NVLink domain or which NIC they sit next to, which is why topology-aware and gang-aware layers are added on top for training workloads.

easy · sample

Why does a multi-node training job need gang scheduling?

Because Kubernetes can only run one pod per node, so the job must reserve whole nodes

Because the ranks share a checkpoint file that must be created on shared storage before any of them starts

✓All ranks must start together; partial placements idle GPUs and can deadlock

Because NCCL requires that every rank be launched from the same physical rack

A 64-GPU job's ranks block in the first collective until all 64 are up. A scheduler that places pods one by one can give job A 40 GPUs and job B 40 GPUs on a 64-GPU cluster: both hold GPUs, neither can finish placement, and both wait forever while the GPUs sit idle. Gang (all-or-nothing) admission, provided by Kueue, Volcano and KAI on Kubernetes and native to Slurm, reserves the whole set before any pod starts, and preempts whole gangs rather than individual pods.

Go deeper than the quiz

A practice test measures recall. The material it draws from teaches the reasoning: