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 machine learning engineer has a graph with 50 million edges stored as a cuDF DataFrame with columns 'src' and 'dst'. She wants to compute connected components across the entire graph. Which cuGraph workflow correctly constructs the graph object and runs the algorithm?

• AConvert the cuDF DataFrame to a pandas DataFrame, pass it to networkx.from_pandas_edgelist, then call the NetworkX connected components function so cuGraph can intercept the call transparently
• BCreate a cuGraph Graph from the cuDF edge DataFrame directly, then call the cuGraph weakly connected components function, which returns a cuDF DataFrame of vertex-component assignmentscheck_circle Correct
• CUse the cuDF merge operation to self-join the edge DataFrame on matching src and dst columns; the resulting clusters correspond directly to connected components
• DStore the edges in a COO matrix via cuSparse, run sparse matrix-vector multiplication iteratively until convergence, then read component labels from the output vector

Why A is wrong: cuGraph does not intercept NetworkX calls; the graph must be constructed natively in cuGraph, and converting 50 million edges to pandas would move data off the GPU and lose the memory and compute advantages of RAPIDS

Why B is correct: cuGraph accepts a cuDF DataFrame to build its internal graph representation without leaving GPU memory; weakly connected components is implemented natively in cuGraph and returns results as a cuDF DataFrame, keeping the full workflow on the GPU

Why C is wrong: A self-join on src/dst identifies reflexive or duplicate edges, not transitive reachability; connected components require propagating labels through multi-hop paths, which is a graph algorithm, not a relational join

Why D is wrong: Iterative SpMV can implement label propagation but it is a low-level approach; cuGraph provides a purpose-built connected components primitive that is more efficient and handles convergence internally, without the engineer implementing the iteration manually

A social-network analyst needs to identify the accounts that act as bridges between otherwise disconnected communities - accounts whose removal would most fragment the network into isolated clusters. Which centrality measure directly quantifies this bridging role?

• ADegree centrality
• BEigenvector centrality
• CBetweenness centralitycheck_circle Correct
• DPageRank centrality

Why A is wrong: Degree centrality counts a node's direct connections, so highly connected hubs score well. A node can have many neighbours within a single community and score high on degree while providing no bridging function between separate groups.

Why B is wrong: Eigenvector centrality scores a node by the importance of its neighbours rather than their raw count. It rewards connection to influential nodes, not structural bridging, so an isolated bridge node between two small clusters would score poorly.

Why C is correct: Betweenness centrality counts how often a node appears on the shortest path between every other pair of nodes. Nodes that lie on paths crossing community boundaries accumulate high betweenness scores, directly measuring the bridging role.

Why D is wrong: PageRank models a random-walk process and assigns higher scores to nodes receiving links from already-important nodes. It was designed for directed web-link graphs and does not directly measure the fraction of shortest paths passing through a node.