NCA-GENM - Performance Optimization (10% of the exam) - Section 6.2
Deploy scalable applications in Kubernetes clusters.
Design Kubernetes deployments for AI inference workloads, including GPU node selectors, resource requests, and horizontal pod autoscaling. Distinguish between stateless and stateful components to determine the appropriate Kubernetes workload type for each service.
Kubernetes
Practice question for this objective
lock_openFree samplePerformance Optimizationhard
A team is deploying a multimodal inference service on Kubernetes. Each pod requires one GPU for model execution. The NVIDIA device plugin is installed on the cluster. Which resource request configuration in the pod spec correctly reserves a single GPU for the container?
ASet resources.requests to cpu: 0 and memory: 0, then annotate the pod with nvidia.com/gpu: 1 in the metadata section.
BSet resources.limits to gpu: 1 using the standard Kubernetes resource name and omit the vendor prefix entirely.
CSet resources.requests and resources.limits both to nvidia.com/gpu: 1 under the container spec.check_circle Correct
DSet resources.requests to nvidia.com/gpu: 1 only, leaving resources.limits unset, so the pod can burst beyond one GPU when the node has capacity.
Correctly configure GPU resource requests and limits using the NVIDIA device plugin in a Kubernetes pod spec. The NVIDIA device plugin registers each GPU on a node as the extended resource nvidia.com/gpu. Kubernetes treats extended resources as integer quantities with no overcommit: the scheduler only allocates them when both resources.requests and resources.limits carry the same value. Setting both to 1 under the container spec is therefore the required pattern to reserve a single GPU for an inference container.
Why A is wrong: Kubernetes annotations are informational metadata and have no effect on resource scheduling. Extended resources like GPUs must appear in the resources block, not as annotations, to be recognised by the scheduler.
Why B is wrong: gpu is not a standard Kubernetes resource name. The NVIDIA device plugin registers GPUs under the vendor-prefixed extended resource nvidia.com/gpu; omitting the prefix means the scheduler cannot locate or allocate the device.
Why C is correct: The NVIDIA device plugin exposes GPUs as the extended resource nvidia.com/gpu. Kubernetes requires that extended resources be specified identically in both requests and limits, so setting both to 1 correctly reserves one GPU for the container.
Why D is wrong: Extended resources in Kubernetes do not support burst behaviour. The scheduler requires that limits equal requests for any extended resource; specifying only a request without a matching limit causes the pod to be rejected at admission.
Answers that look right on this material and are not. Each one is a distractor from a different question in the NCA-GENM bank for this domain.
The HorizontalPodAutoscaler ceiling on the Deployment is set to four, so the Cluster Autoscaler treats the workload as already satisfied and never requests additional GPU nodes.
errorWhy it is wrong: Tempting because autoscalers interact, but the HPA controls replica count and not node provisioning, and the four pods are already pending and unschedulable, which is exactly the trigger the Cluster Autoscaler acts on.
The horizontal autoscaler resizes the resource requests of running pods in place while the vertical autoscaler launches additional replicas across more nodes.
errorWhy it is wrong: Tempting because it pairs the right mechanisms with autoscaler names, but it inverts them: replica count is horizontal and per-pod resource tuning is vertical, so the description is exactly backwards.
Horizontal pod autoscaling cannot scale deployments that request GPU resources; it is limited to CPU-only workloads.
errorWhy it is wrong: The horizontal pod autoscaler is not restricted to CPU workloads. It can scale any deployment; the issue lies in how the scaling metric is sourced and configured, not in the presence of GPU resource requests.