Free NCA-AIIO practice questions

A team is preparing to train a large language model whose total memory footprint - accounting for model parameters, intermediate activations, and optimiser states - comfortably exceeds the capacity of a single GPU. Which infrastructure decision most directly addresses this constraint?

• AReplace the GPUs with DPUs to offload memory management to a dedicated data-processing unit.
• BSwitch to a higher-throughput Ethernet fabric between nodes, as network latency is the bottleneck that prevents the model fitting in memory.
• CIncrease fast NVMe storage capacity so the model can be streamed from disk into GPU memory in chunks during the forward pass.
• DDistribute the model across multiple GPUs so the combined memory across the pool can hold all training states simultaneously.check_circle Correct

Why A is wrong: DPUs handle networking, storage, and security offload from the CPU; they have no general-purpose tensor compute memory that substitutes for GPU VRAM in training workloads.

Why B is wrong: Network throughput affects gradient synchronisation speed but does not change how much GPU memory is available; upgrading the fabric cannot make a model fit in memory it does not have.

Why C is wrong: While CPU offload and disk-backed parameter swapping exist as workarounds, they introduce severe performance penalties; the standard architectural decision is to add GPUs until combined memory is sufficient, not to rely on disk streaming.

Why D is correct: When a model's parameters, activations, and optimiser states together exceed one GPU's memory, spreading them across multiple GPUs is the standard solution - each GPU holds a partition of the total working set.

During a multi-GPU training run, GPUs must frequently exchange gradient tensors to keep model replicas synchronised. Which interconnect characteristic is most critical for preventing this communication from becoming the training bottleneck?

• AHigh aggregate bandwidth between GPUs, provided by an interconnect such as NVLink, to sustain rapid all-reduce gradient synchronisation.check_circle Correct
• BLow per-packet CPU overhead, so the host processor is not saturated routing gradient traffic.
• CSupport for jumbo Ethernet frames to reduce the number of packets needed per gradient exchange.
• DDeep packet buffers in the switch fabric to absorb gradient bursts without dropping packets during synchronisation.

Why A is correct: All-reduce operations move large volumes of gradient data between every GPU in the group during each training step. A high-bandwidth interconnect like NVLink provides the throughput needed to complete these transfers quickly enough that GPU compute is not left idle waiting for gradients.

Why B is wrong: RDMA-capable fabrics already bypass the CPU for data movement; CPU overhead is far less significant than raw bandwidth when gradients are large dense tensors transferred continuously throughout training.

Why C is wrong: Jumbo frames reduce per-packet overhead on standard Ethernet but do not provide the aggregate bandwidth of a purpose-built high-bandwidth GPU interconnect; packet-size tuning is a secondary concern compared to total available bandwidth.

Why D is wrong: Buffer depth helps prevent congestion on lossy fabrics but is a network-fabric property rather than the primary determinant of gradient sync speed; sustained bandwidth between GPUs is the dominant factor.

A data engineering team notices that GPU utilisation drops sharply between mini-batches during a training job, even though the GPUs have sufficient memory and the network interconnect is not saturated. Which infrastructure layer is the most likely cause of this idle time?

• AThe GPUs are throttling compute to reduce thermal output because the data-centre cooling system is undersized.
• BThe training dataset is stored on a shared file system that cannot sustain the read throughput required to keep all GPUs continuously fed with data.check_circle Correct
• CThe NVLink interconnect is saturated by gradient traffic, forcing GPUs to pause before starting the next forward pass.
• DThe CPU is unable to pre-process samples fast enough because the number of data-loader worker processes is set too low.

Why A is wrong: Thermal throttling would manifest as consistently lower sustained throughput rather than sharp drops between mini-batches; the described pattern of idle gaps between batches points to a data-supply problem rather than a thermal one.

Why B is correct: GPU compute is far faster than most storage systems. When storage throughput is insufficient, the data-loading pipeline stalls, leaving GPUs idle while they wait for the next batch of samples. High-bandwidth parallel storage is required to match the consumption rate of a multi-GPU cluster.

Why C is wrong: The question states the interconnect is not saturated; even if it were, interconnect saturation would affect gradient sync time rather than the idle gap between loading one mini-batch and the next.

Why D is wrong: Insufficient CPU data-loader workers can contribute to a starvation bottleneck, but this is a software-configuration issue rather than an infrastructure layer; the underlying root cause in most large-scale cases is storage throughput, which no amount of worker tuning can overcome if the storage fabric itself is the limit.

Which combination of factors is most widely credited for enabling the dramatic performance improvements in deep learning models over the past decade?

• AAvailability of large datasets, GPU-based parallel compute, and advances in model architecturescheck_circle Correct
• BFaster internet connectivity, improved operating systems, and reduced hardware costs
• CAdoption of relational databases, faster CPUs, and improved compiler toolchains
• DWider use of edge devices, lower memory prices, and growth in mobile applications

Why A is correct: These three pillars - big data, parallel GPU compute, and algorithmic advances such as the transformer architecture - are the foundational reasons deep learning achieved its recent breakthroughs.

Why B is wrong: Network speed and OS improvements are enabling infrastructure factors but not the core technical pillars. They do not directly drive model quality or training capability.

Why C is wrong: Relational databases and CPU speed gains did not drive deep learning progress. The shift to parallel GPU compute specifically unlocked the scale needed for modern AI workloads.

Why D is wrong: Edge devices and mobile apps are consumers of AI, not drivers of its foundational improvement. Lower memory prices alone do not account for architectural breakthroughs or training-scale gains.

A data science team wants to train a large language model but lacks on-premises GPU infrastructure. Which development has most directly lowered the barrier for teams in this position?

• AThe introduction of DPUs that offload networking and storage processing from CPUs
• BThe release of open-source model weights and cloud-based GPU compute servicescheck_circle Correct
• CWider adoption of NVLink interconnects inside GPU servers
• DStandardisation of InfiniBand networking for distributed training clusters

Why A is wrong: DPUs (data processing units) improve data-centre efficiency by offloading networking and security tasks, but they do not give a team without GPUs access to training-scale parallel compute.

Why B is correct: Open model releases (such as Llama and Mistral) combined with cloud GPU services (on-demand A100 or H100 instances) let teams fine-tune or build on existing models without capital investment in hardware.

Why C is wrong: NVLink is a high-bandwidth GPU-to-GPU interconnect that improves multi-GPU training throughput within a node. It is a hardware feature inside a server, not something that reduces entry barriers for teams without infrastructure.

Why D is wrong: InfiniBand reduces latency in large GPU clusters and benefits teams that already have infrastructure. It does not help a team that has no on-premises GPUs at all.

A data science team has finished cleaning and versioning their training dataset and wants to begin iterative model experimentation. Which lifecycle stage immediately follows data preparation, and what is the primary software concern at that stage?

• AModel registry - storing approved model artefacts for controlled promotion to production
• BInference serving - deploying a model endpoint so applications can request predictions in real time
• CTraining framework - orchestrating compute, defining model architecture, and running gradient-based optimisation on the prepared datacheck_circle Correct
• DMonitoring - tracking data drift and model performance degradation against production baselines

Why A is wrong: A model registry manages promotion of validated models, not the iterative experimentation that comes directly after data preparation. Registries operate after training and evaluation are complete.

Why B is wrong: Inference serving comes after a model is trained and registered. Running a serving layer on unprepared, untrained weights produces no useful predictions and is the wrong stage.

Why C is correct: After data is prepared and versioned the next stage is model training, where a framework such as PyTorch or TensorFlow defines the network, manages distributed compute, and executes the optimisation loop.

Why D is wrong: Monitoring is a post-deployment concern that tracks live model behaviour. There is no production model to monitor immediately after data preparation, so this stage does not follow data prep.

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

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.

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

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.

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

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.