NVIDIA-Certified Associate: Accelerated Data Science (NCA-ADS) practice questions

A data engineer loads a social network dataset into cuGraph using a compressed sparse row (CSR) representation. After running a breadth-first search from a single source node, she notices the traversal completes far faster than the equivalent NetworkX run on CPU. Which characteristic of GPU hardware most directly explains this speedup for BFS on large sparse graphs?

• ABFS can expand the entire frontier of unvisited neighbours in parallel across GPU threads, saturating memory bandwidth with concurrent edge readscheck_circle Correct
• BGPUs have higher single-core clock speeds than CPUs, so each edge inspection executes faster
• CCSR layout stores edges in sorted order, letting cuGraph skip visited nodes via binary search instead of hash-table lookup
• DcuGraph offloads the BFS queue management to the CPU while the GPU handles only the arithmetic, reducing data-transfer overhead

Why A is correct: Each BFS frontier level exposes a large set of independent neighbour checks; GPU threads process these in parallel and the high aggregate memory bandwidth of GPU HBM handles the irregular sparse-memory access pattern at scale

Why B is wrong: GPUs typically run at lower clock speeds than modern CPUs; their advantage comes from massively parallel execution across thousands of cores, not faster individual clock cycles

Why C is wrong: CSR is a compact adjacency format that enables coalesced reads, but BFS visited-node tracking uses a bitset or boolean array, not binary search; the speedup is from parallelism, not search algorithm substitution

Why D is wrong: cuGraph keeps both the graph data and the traversal state resident on the GPU throughout; round-tripping queue state to the CPU would add PCIe latency and negate the GPU advantage

A data engineer loads a 10 GB CSV file into a cuDF DataFrame and then needs to join it with a 500 MB lookup table that currently lives in a pandas DataFrame. Which approach correctly brings both tables onto the GPU so that the merge operation runs entirely on GPU memory?

• APass the pandas DataFrame directly to cudf.merge as the right-hand argument; cuDF will convert it automatically during the merge.
• BConvert the cuDF DataFrame to pandas using the to_pandas method and perform the merge in pandas on the CPU, then reload the result into cuDF.
• CConvert the pandas DataFrame to a cuDF DataFrame using cudf.from_pandas before calling the merge operation on the two cuDF objects.check_circle Correct
• DUse the cudf.pandas accelerator module so that both DataFrames are transparently promoted to GPU; no explicit conversion call is needed.

Why A is wrong: Tempting because cuDF's merge signature resembles pandas, but cuDF does not silently convert a pandas object passed as the right-hand frame - it raises a TypeError, so the merge would fail before running.

Why B is wrong: This approach moves 10 GB from device to host, loses the GPU acceleration for the merge, and then requires another host-to-device copy for subsequent GPU work - the opposite of the intended workflow.

Why C is correct: cudf.from_pandas copies the host-side pandas data to GPU memory, producing a cuDF DataFrame. Both frames are then on the GPU, so the merge executes entirely on the device without further host-device transfers.

Why D is wrong: The cudf.pandas accelerator intercepts pandas API calls on objects created after the module is activated, but a pandas DataFrame that already exists in memory before activation is not retroactively transferred to GPU without an explicit conversion step.

A data scientist loads a 500-row CSV into a cuDF DataFrame, applies a single group-by aggregation, and finds the operation is slower than the equivalent pandas operation. What is the most likely explanation?

• AcuDF does not support group-by aggregations on small DataFrames and falls back silently to a CPU-based path.
• BGroup-by aggregations require sorting as a prerequisite, and sorting is a serial algorithm that GPUs cannot accelerate compared to a modern CPU core.
• CThe GPU's clock speed is lower than a modern CPU's single-core clock speed, so any single-threaded aggregation step will always be slower on the GPU.
• DThe host-to-device and device-to-host data transfers dominate the total wall-clock time when the dataset is small, erasing any parallelism benefit from the GPU kernel itself.check_circle Correct

Why A is wrong: cuDF does support group-by aggregations regardless of DataFrame size; there is no automatic silent fallback that would explain the slowdown as a capability gap.

Why B is wrong: Sorting is not strictly required for all group-by strategies, and GPU-based radix and merge sorts can be faster than CPU sorts for larger data; this reasoning does not explain the small-data slowdown.

Why C is wrong: While GPUs do have lower per-core clock speeds, cuDF group-by operations are data-parallel and use thousands of CUDA cores simultaneously; raw clock speed comparison is not the correct explanation for this scenario.

Why D is correct: GPU acceleration carries a fixed overhead for copying data across the PCIe bus. On a 500-row dataset the transfer cost exceeds the compute savings, making the GPU path net slower than an in-process pandas call.