Free NCA-ADS practice questions

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 team wants to accelerate an existing pandas-based ETL script that performs several group-by aggregations and inner joins on large tables. They want to achieve GPU acceleration with the smallest number of code changes. Which mechanism is designed for exactly this goal?

• ARewrite every DataFrame assignment to use cudf.DataFrame explicitly and replace each pandas method call with its cuDF equivalent throughout the script.
• BWrap the ETL logic in a Dask-cuDF pipeline by converting each pandas call to a dask_cudf delayed graph, then trigger computation at the end.
• CEnable CUDA Unified Memory so that pandas DataFrames are automatically paged to the GPU during computation without any import or conversion step.
• DImport the cudf.pandas compatibility module at the top of the script; it intercepts subsequent pandas API calls and dispatches them to GPU where cuDF supports the operation.check_circle Correct

Why A is wrong: A full rewrite does achieve GPU acceleration, but it requires touching every line that constructs or operates on a DataFrame - the opposite of minimal code changes, and unnecessary when a drop-in accelerator exists.

Why B is wrong: Dask-cuDF is the correct tool for data that exceeds a single GPU's memory and requires distributed computation, but it demands significant restructuring of the pipeline rather than a minimal-change approach.

Why C is wrong: CUDA Unified Memory allows the CPU and GPU to share a single virtual address space, but pandas itself has no awareness of the GPU and will not issue CUDA kernels; simply enabling Unified Memory does not make pandas operations run on the GPU.

Why D is correct: The cudf.pandas module is RAPIDS' drop-in accelerator: adding the import statement before any pandas import causes Python to route supported pandas operations through cuDF on the GPU transparently, requiring no further source changes for standard group-by, join, and aggregation operations.

A cuDF DataFrame loaded from a sensor log contains a numeric column where roughly 8% of rows hold null values. The nulls are missing at random and the column is used as a feature in a downstream regression model. Which approach best preserves information while keeping the GPU DataFrame pipeline intact?

• AFill nulls with the column mean computed directly on the cuDF Seriescheck_circle Correct
• BDrop every row that contains a null in that column
• CConvert the column to a Python list, impute in a for-loop, then reassign it to the DataFrame
• DReplace nulls with zero because cuDF does not support statistical aggregations on columns with nulls

Why A is correct: Mean imputation preserves all rows, uses only the non-null values for the statistic, and cuDF supports the fillna operation natively on the GPU, keeping the entire workflow accelerated without a CPU round-trip.

Why B is wrong: Dropping rows is fast and simple, but discarding 8% of records reduces the training set and can introduce bias if the missing pattern correlates with the target, making it a poor default when imputation is feasible.

Why C is wrong: Transferring data off the GPU to a Python list and looping element-by-element eliminates all GPU parallelism, introduces significant host-device transfer overhead, and defeats the purpose of using cuDF for large-scale data.

Why D is wrong: cuDF aggregations such as mean and median skip null entries by default, so the claim is incorrect. Substituting zero introduces a systematic bias that distorts model training unless zero is a meaningful domain value.

A cuML pipeline is trained on a highly imbalanced binary dataset where the minority class makes up roughly 8% of samples. A colleague suggests using standard k-fold cross-validation with k=5. What is the primary risk of this approach, and which alternative directly addresses it?

• AStandard k-fold shuffles rows before splitting, which corrupts temporal ordering in time-series data; stratified k-fold avoids shuffling altogether to maintain sequence integrity.
• BStandard k-fold may assign all minority samples to a single fold, causing some folds to have no positive examples; stratified k-fold preserves the class ratio in each fold to avoid this.check_circle Correct
• CStandard k-fold uses the same random seed across folds, causing data leakage between train and validation sets; stratified k-fold uses distinct seeds per fold to eliminate leakage.
• DStandard k-fold computes metrics only on the training folds, so minority-class performance is never evaluated; stratified k-fold explicitly evaluates each fold as a held-out test set.

Why A is wrong: Shuffling and temporal ordering are relevant concerns for time-series problems, not for the class-imbalance problem described. Stratified k-fold still shuffles rows but does so within each class stratum, so it does not solve a time-ordering concern.

Why B is correct: With severe imbalance, random partitioning can produce folds where the minority class is absent or dramatically under-represented, making fold-level metrics meaningless. Stratified k-fold samples each class proportionally into every fold, ensuring a consistent evaluation signal across all splits.

Why C is wrong: Data leakage is not a consequence of the random seed or fold structure in standard k-fold. Both standard and stratified k-fold maintain strict separation between train and validation partitions; seed choice does not introduce leakage.

Why D is wrong: In every k-fold variant, each fold takes a turn as the held-out validation set and metrics are computed on that held-out portion - not on the training folds. This is a misunderstanding of how k-fold evaluation works, not a real distinction between the two methods.

A data scientist evaluates a cuML regression model using a single 80/20 train-test split and records the root mean squared error. A second data scientist evaluates the same model architecture using 10-fold cross-validation on the same dataset. Why does the second approach give a more reliable estimate of generalisation error?

• ACross-validation trains the model 10 times, so the final cuML estimator has seen more gradient updates and converges to a lower training loss than a single-split model.
• BCross-validation prevents overfitting by exposing the model to the full dataset during training in each fold, which regularises the weights more strongly than training on 80% of the data once.
• CCross-validation reduces variance in the error estimate by averaging results across 10 non-overlapping held-out folds, so the estimate is less sensitive to which specific samples happened to land in the held-out set.check_circle Correct
• DCross-validation eliminates the need for a separate test set because the rotating held-out folds collectively cover every sample, making the reported metric equivalent to a leave-one-out test on unseen data.

Why A is wrong: Cross-validation is an evaluation strategy, not a training intensification method. The ten trained models are discarded after evaluation; they do not collectively produce a single better-converged model. Generalisation error estimation and training convergence are separate concerns.

Why B is wrong: Each fold still trains on k-1 folds, which is 90% of the data in 10-fold CV compared to 80% in a single split - a modest difference. Cross-validation is not a regularisation mechanism; it is an evaluation technique. Overfitting is controlled by the model's own regularisation parameters, not by the evaluation protocol.

Why C is correct: A single split produces one error sample whose value depends heavily on the random composition of that particular 20% held-out set. By rotating through 10 folds, cross-validation draws 10 independent error estimates and averages them, substantially reducing the estimator variance without changing the dataset size. This is the foundational statistical justification for k-fold CV over a single holdout.

Why D is wrong: While k-fold CV does ensure every sample appears in a validation fold exactly once, it does not replace a held-out test set in a rigorous evaluation pipeline. Using the same data for both hyperparameter selection via CV and final reporting can still introduce optimistic bias; a distinct held-out test set remains best practice.

A data scientist has loaded a 50-million-row dataset into a cuDF DataFrame and wants to train a logistic regression model using cuML. Which statement best describes how cuML's API design makes this transition straightforward?

• AcuML requires the data to be first converted to a NumPy array before fitting, because the underlying CUDA kernels only accept host-memory buffers as input to the training routines.
• BcuML exposes a custom object-oriented API that has no similarity to scikit-learn, so practitioners must learn new method names and a different fit-predict lifecycle when switching from CPU-based workflows.
• CcuML automatically detects the size of the dataset and falls back to a scikit-learn CPU implementation when the number of rows exceeds available GPU memory, providing transparent failover.
• DcuML mirrors the scikit-learn estimator interface, so the fit and predict calls on a cuML LogisticRegression object follow the same pattern as the scikit-learn equivalent, but computation runs on the GPU.check_circle Correct

Why A is wrong: This is the opposite of the performance intent: cuML accepts cuDF DataFrames and CuPy arrays directly in GPU memory, so forcing a conversion to NumPy would transfer data back to host memory and eliminate the GPU advantage.

Why B is wrong: cuML is explicitly built around scikit-learn compatibility as a design goal, so claiming the API is unrelated misrepresents the library's core value proposition for teams migrating from CPU pipelines.

Why C is wrong: cuML does not contain a built-in transparent CPU fallback tied to data size; managing out-of-core or multi-GPU scenarios requires explicit use of Dask or other orchestration, so this claim describes a feature that does not exist in cuML itself.

Why D is correct: cuML is deliberately designed to match scikit-learn's estimator contract, meaning fit, predict, and transform signatures are intentionally compatible, which lets practitioners reuse familiar patterns while gaining GPU execution.

A data engineer is processing a 200 GB Parquet dataset on a four-GPU node. Each GPU has 40 GB of VRAM. The engineer creates a dask_cudf DataFrame by reading the dataset with dask_cudf.read_parquet and then calls a group-by aggregation. The aggregation does not execute immediately. What triggers actual computation and causes the Dask scheduler to dispatch work to the GPU workers?

• AAssigning the dask_cudf DataFrame to a Python variable
• BReading the Parquet files with dask_cudf.read_parquet, which loads data eagerly into GPU memory across all workers
• CPrinting the dask_cudf DataFrame object, which forces Dask to resolve all partitions so the repr can be displayed
• DCalling the compute method on the resulting dask_cudf DataFramecheck_circle Correct

Why A is wrong: Assignment is a Python name-binding operation and has no effect on Dask scheduling; the task graph remains unevaluated and no GPU work is dispatched at that point.

Why B is wrong: dask_cudf.read_parquet records a read step in the task graph but does not load data eagerly; actual I/O and GPU placement happen only when computation is triggered, which is the key characteristic of Dask lazy execution.

Why C is wrong: Printing a dask_cudf DataFrame displays a high-level metadata repr without executing the full task graph; only a subset of metadata may be resolved, so this does not reliably trigger complete distributed computation across workers.

Why D is correct: dask_cudf operations build a lazy task graph; compute is the explicit trigger that instructs the Dask scheduler to execute all pending graph nodes across the available GPU workers and return a materialised cuDF result.

A team has a cuDF-based ETL pipeline that runs correctly on a single GPU but must now handle datasets that exceed available VRAM. They refactor the code to use dask_cudf. During testing they find that increasing the number of partitions beyond what the data volume strictly requires causes a measurable rise in total execution time even though each partition now fits comfortably within VRAM. Which explanation best accounts for this overhead?

• AEach additional partition introduces task-graph nodes that the Dask scheduler must serialise, communicate, and track, adding scheduling and inter-worker coordination overhead that accumulates with partition countcheck_circle Correct
• BMore partitions increase the total GPU memory reserved per worker because dask_cudf pre-allocates a fixed buffer for each partition regardless of its actual size
• Cdask_cudf converts each partition to a pandas DataFrame before sending it to a worker, and more partitions multiply the host-to-device transfer cost
• DIncreasing partition count forces the Dask scheduler to serialise all partitions through a single worker to maintain partition ordering, eliminating parallelism

Why A is correct: Every partition maps to at least one node in the Dask task graph. The scheduler must plan, dispatch, and track each node; inter-worker data movement and result aggregation also scale with partition count. When partitions are too small the coordination overhead outweighs the parallelism benefit, making an over-partitioned graph slower than a well-sized one.

Why B is wrong: dask_cudf does not pre-allocate fixed-size buffers per partition; memory is allocated when a partition is actually loaded, so partition count alone does not inflate reserved memory in the way described.

Why C is wrong: dask_cudf keeps data as cuDF DataFrames on the GPU workers and does not convert partitions to pandas as a standard step; claiming a pandas conversion occurs conflates the dask_cudf path with the CPU-based Dask DataFrame path.

Why D is wrong: The Dask scheduler does not route all partitions through a single worker to maintain order; partitions are processed concurrently across workers and ordering constraints are handled at the graph level only when a shuffle or sort is explicitly requested.

A data scientist is building a cuML pipeline on a GPU cluster. After splitting data into train and test sets, they want to remove features whose variance falls below a threshold and then apply mutual information scoring to rank the survivors. Which practice is essential to prevent target leakage when fitting these two selection steps?

• AFit the variance threshold and mutual information selector on the combined train-plus-test data so that the full feature distribution is captured accurately.
• BFit the variance threshold and mutual information selector on the training set only, then apply the fitted selector to transform both the training and test sets.check_circle Correct
• CFit the variance threshold on the training set but fit the mutual information selector on the test set, because mutual information requires the true label distribution to score features.
• DApply the variance threshold before the train-test split and fit the mutual information selector on the training set, treating the two steps as independent preprocessing stages.

Why A is wrong: Fitting on combined train and test data causes target leakage because test-set statistics influence which features are retained, making evaluation results optimistic and unreliable in production.

Why B is correct: Fitting selection steps exclusively on the training set ensures that no information from the test set contaminates the selection criteria, preserving the integrity of the held-out evaluation and reflecting how the pipeline would behave on unseen data.

Why C is wrong: Using test-set labels to fit the mutual information scorer leaks target information from the held-out set into the selection step, which invalidates the evaluation and produces overly optimistic performance estimates.

Why D is wrong: Applying variance thresholding before splitting means the threshold is influenced by test-set variance, which is a subtle form of leakage. Both selection steps must be fitted strictly after the train-test split and only on training data.

A data scientist is summarising the annual salaries in a dataset that contains a small number of extremely high earner outliers. Which measure of central tendency gives the most representative picture of the typical employee salary?

• AThe median, because it is resistant to extreme values at the tail of the distributioncheck_circle Correct
• BThe arithmetic mean, because it incorporates every value in the dataset
• CThe mode, because the most frequently occurring salary describes what is normal
• DThe variance, because it quantifies how spread out the salary values are

Why A is correct: The median splits the ordered distribution at the midpoint and is unaffected by how extreme the highest values are, so it reflects where most salaries actually fall.

Why B is wrong: The mean is tempting because it uses all data points, but outliers pull it far above most employees' salaries, making it unrepresentative of the typical worker.

Why C is wrong: The mode identifies the most common single value, but salary data is often spread across many distinct figures, making the mode a poor summary of the centre.

Why D is wrong: Variance measures dispersion, not central tendency, so it describes spread rather than where a typical salary sits in the distribution.

A RAPIDS workflow loads a large CSV into a cuDF DataFrame and needs a quick summary of the central tendency and spread of every numeric column. Which cuDF operation produces per-column statistics including the mean, standard deviation, and quartile values in a single call?

• AThe value_counts operation, which returns frequency counts for each unique entry in every column
• BThe describe operation, which returns count, mean, standard deviation, min, quartile values, and max for each numeric columncheck_circle Correct
• CThe corr operation, which computes pairwise correlation coefficients across all numeric columns
• DThe info operation, which reports column names, non-null counts, and data types for the DataFrame

Why A is wrong: value_counts tallies occurrence frequencies for categorical-style data and does not compute numeric summary statistics such as mean, standard deviation, or quartiles.

Why B is correct: cuDF's describe method mirrors the pandas describe API and executes on the GPU, returning a summary DataFrame covering the core descriptive statistics needed in EDA in a single call.

Why C is wrong: corr produces a correlation matrix showing relationships between column pairs, but it does not report individual column means, standard deviations, or quartile boundaries.

Why D is wrong: info summarises schema metadata such as dtypes and null counts, not numeric distributional statistics like mean, variance, or quartiles.

A data scientist runs a two-sample t-test comparing mean GPU kernel execution times between two hardware configurations. The result is p = 0.03 with a significance level of 0.05. Which statement is the most statistically precise interpretation of this result?

• AThere is a 3% probability that the null hypothesis is true
• BThe alternative hypothesis is true with 97% confidence, confirming a real difference exists
• CAssuming the null hypothesis is true, there is a 3% probability of obtaining a test statistic at least as extreme as the one observedcheck_circle Correct
• DThe probability of committing a type II error on this test is 3%

Why A is wrong: This is one of the most common misinterpretations of a p-value. A p-value is not the probability that the null hypothesis is true; it is the probability of observing data at least as extreme as the sample data, assuming the null hypothesis is already true.

Why B is wrong: A p-value below the significance threshold justifies rejecting the null hypothesis but does not assign a probability of truth to the alternative hypothesis. Confidence intervals and effect sizes are needed to gauge practical significance.

Why C is correct: This is the precise frequentist definition of a p-value. It quantifies how compatible the observed data are with the null hypothesis, not the probability that either hypothesis is correct.

Why D is wrong: Type II error probability, known as beta, depends on statistical power and the effect size being tested. It is a separate quantity from the p-value and cannot be read directly from a single test result.

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.

A team is choosing between a CPU-based and a GPU-based pipeline for two tasks: (1) computing element-wise transformations across 200 million floating-point values, and (2) executing a decision-tree traversal where each row follows a unique branch path determined by its feature values. Which assignment best matches each task to the correct processing unit?

• AGPU for the element-wise transformations and CPU for the decision-tree traversal, because uniform parallel operations over large arrays suit GPU throughput while conditional, branchy logic suits the CPU's out-of-order execution model.check_circle Correct
• BGPU for both tasks, because modern GPUs have enough cores to handle branchy tree traversal in parallel across all rows simultaneously.
• CCPU for both tasks, because CPUs have higher single-core clock speeds and larger caches that benefit all data science workloads regardless of data size.
• DCPU for the element-wise transformations and GPU for the decision-tree traversal, because CPUs handle large vectorised operations more efficiently than GPUs do.

Why A is correct: Element-wise operations over 200 million values are embarrassingly parallel with no branching, exactly matching GPU strengths. Decision-tree traversal involves per-row conditional branching that causes CUDA warp divergence, degrading GPU efficiency; the CPU's branch predictor and out-of-order execution handle this pattern far better.

Why B is wrong: GPU cores execute in SIMD warps where divergent branches cause serialisation within a warp; branchy decision-tree traversal with per-row unique paths leads to warp divergence and poor GPU utilisation, making a CPU the better fit for that task.

Why C is wrong: Higher single-core clock speed and larger caches do not compensate for the lack of parallelism when processing 200 million values; the element-wise transformation is exactly the class of embarrassingly parallel, compute-heavy work where GPUs excel.

Why D is wrong: This assignment is reversed. Large-scale element-wise floating-point work is embarrassingly parallel and is precisely where GPU throughput dominates; CPU vector units cannot match thousands of GPU cores for that task at 200 million elements.

A data scientist has a 200 GB Parquet dataset and a single 80 GB GPU. She loads it as a Dask-cuDF DataFrame and calls a group-by aggregation. Which mechanism makes this operation feasible on hardware where the data cannot fit in GPU memory at once?

• ADask streams the entire dataset into GPU memory in one batch by temporarily spilling excess frames to CPU RAM automatically without any partitioning.
• BDask splits the dataset into partitions, builds a lazy task graph, and executes the aggregation one partition at a time, keeping peak GPU memory use proportional to partition size rather than total dataset size.check_circle Correct
• CDask-cuDF converts the group-by operation into a cuML algorithm that uses unified memory addressing, allowing the GPU to page individual rows on demand from host RAM during computation.
• DDask eagerly materialises all partitions into a contiguous GPU buffer before executing the group-by, ensuring consistent performance by avoiding repeated device-to-host transfers.

Why A is wrong: Dask does not load all data into GPU memory as a single batch. It partitions the dataset and executes work partition by partition according to a lazy task graph, so peak GPU memory pressure stays bounded by partition size, not total dataset size.

Why B is correct: This is the core out-of-core mechanism: Dask represents the computation as a directed acyclic task graph and materialises only the partitions currently being processed, so a dataset larger than GPU memory can be aggregated correctly without exceeding device capacity.

Why C is wrong: Unified memory (CUDA managed memory) is a distinct CUDA mechanism unrelated to Dask partitioning, and cuML is the machine-learning library, not a component involved in group-by aggregation. Dask-cuDF achieves scalability through partition-based lazy evaluation, not through managed memory paging.

Why D is wrong: Dask's defining characteristic is lazy evaluation: it constructs a task graph and defers computation until explicitly triggered. Eagerly materialising all partitions upfront would defeat the out-of-core purpose and would still require the full dataset to fit in GPU memory simultaneously.

A data scientist trains a scikit-learn StandardScaler on the training split and saves it alongside the trained model weights. Which term best describes the StandardScaler object in the context of ML artefact management?

• AA preprocessing artefactcheck_circle Correct
• BA hyperparameter configuration file
• CA dataset version snapshot
• DAn evaluation metrics record

Why A is correct: A fitted preprocessing transformer such as StandardScaler is a preprocessing artefact: a serialisable object produced during the training pipeline that must be versioned and stored alongside the model so that inference inputs can be transformed identically to training inputs.

Why B is wrong: Hyperparameter files record settings such as learning rate or max depth, not fitted transformation state. A StandardScaler holds computed mean and variance values that are required to reproduce the exact transformation applied at training time.

Why C is wrong: A dataset version snapshot refers to a recorded, immutable cut of raw or processed data, not a fitted transformation object. Conflating the two would cause an artefact store to mis-categorise the object and break reproducibility checks.

Why D is wrong: Evaluation metrics records store scalar or aggregate performance values such as accuracy or RMSE. A StandardScaler contains no performance measurement; it holds statistical parameters derived from training data and applied during feature transformation.

A team uses an experiment tracker to log each training run. They want future colleagues to reproduce any model exactly. Which practice most directly supports that goal?

• ALogging only the final validation loss for each run to keep the tracker lightweight
• BLinking each stored artefact to the run record that produced it, including code version and dataset versioncheck_circle Correct
• CStoring model weights in a shared folder without recording which run produced them
• DTagging each artefact file with the current calendar date as its version identifier

Why A is wrong: Recording only the final loss omits the information needed to identify which run produced a given model. Without linking the run record to the stored artefacts, a colleague cannot determine which code version, dataset version, or hyperparameters generated the result.

Why B is correct: Reproducibility requires a complete, queryable link from every artefact - model weights, preprocessors, and metrics - back to the exact run that generated it, including the code commit and the dataset version used. This linkage lets any team member reconstruct the full pipeline from a single run identifier.

Why C is wrong: Saving weights without run linkage breaks the audit trail. If multiple runs produce files with similar names, colleagues cannot determine which configuration generated a specific model, making reproducibility impossible in practice.

Why D is wrong: A calendar date is a weak version identifier: multiple runs on the same day collide, and the date carries no information about the code or data that was used. Proper artefact versioning requires linking to a specific run record rather than an imprecise timestamp.

A machine learning engineer is running a fair CPU-versus-GPU comparison for a cuML random forest training task. The first GPU run is measured at 4.2 seconds and subsequent runs average 1.1 seconds. The engineer plans to report 4.2 seconds as the representative GPU time. What is the main flaw in that plan?

• AThe reported time should be the median of all runs, including the first, because the median is more robust to outliers than the mean.
• BThe GPU time should be divided by the number of CPU cores to produce a per-core comparison that is fair to single-threaded CPU workloads.
• CThe first run includes one-off costs such as JIT compilation and CUDA context initialisation that are not paid on subsequent calls, so using it as the representative time overstates steady-state GPU latency.check_circle Correct
• DThe benchmark should be run with a larger dataset for the GPU comparison because small datasets do not saturate GPU parallelism and will always make the GPU appear slower than the CPU.

Why A is wrong: Choosing a different aggregation statistic does not address why the first run is slow; the issue is that one-off initialisation costs inflate the first measurement, and including it in any average distorts the steady-state performance the benchmark aims to characterise.

Why B is wrong: Dividing by core count is not a standard or meaningful normalisation for end-to-end training time; it conflates throughput with resource usage and does not relate to the elevated first-run time caused by warm-up overheads.

Why C is correct: GPU frameworks often compile kernels on the first invocation and initialise the CUDA context, both of which are one-time costs. Including that first run inflates the reported latency well beyond what the GPU takes for real workloads, making the comparison unfair to the GPU. Warm-up runs should be excluded from reported figures.

Why D is wrong: While dataset size does affect whether GPU parallelism is fully utilised, the question specifically asks about using the first-run time of 4.2 seconds versus the steady-state 1.1 seconds; the flaw is the one-off warm-up cost, not the dataset size.

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.

A data scientist pins all package versions in a conda environment YAML file and commits a conda lock file to the project repository. A colleague clones the repository six months later and rebuilds the environment. Which outcome does this practice most directly guarantee?

• AThe rebuilt environment will contain exactly the same package versions as the original, so the pipeline behaviour is reproducible regardless of when it is rebuilt.check_circle Correct
• BThe rebuilt environment will use the latest compatible releases of each package, taking advantage of bug fixes published after the original pin.
• CThe lock file prevents any two projects on the same machine from installing conflicting packages, because conda enforces global version uniqueness.
• DThe GPU drivers on the colleague's machine are automatically matched to the CUDA version recorded in the lock file, ensuring hardware compatibility.

Why A is correct: Exact version pins combined with a lock file record every direct and transitive dependency at a specific version. Any later rebuild resolves identically, eliminating the risk that a newer release changes pipeline behaviour.

Why B is wrong: Pinning exact versions prevents any upgrade, so the latest releases are not fetched. This describes the behaviour of an unpinned or range-constrained environment, not a pinned one.

Why C is wrong: A lock file records versions for one environment; it does not enforce cross-environment uniqueness. Conda environments are isolated per-environment, not globally, so two projects can use different versions of the same package without conflict.

Why D is wrong: Lock files track Python package versions, not host driver installation. GPU driver compatibility must be managed separately; a mismatch between the recorded CUDA toolkit version and the installed driver will still cause runtime errors.

A team maintains two separate GPU-accelerated projects on the same workstation. Project A requires cuDF 23.10 and Project B requires cuDF 24.06. Without per-project virtual environments, what is the most likely consequence when both projects are run from a single shared Python installation?

• ABoth versions of cuDF are loaded simultaneously into memory, and Python selects the correct one automatically based on the import context.
• BOnly one version of cuDF can be installed in the shared environment, so one project will run against an incompatible version and may produce incorrect results or fail with import errors.check_circle Correct
• CThe projects run correctly because pip resolves version conflicts at import time by inspecting each script's requirements file.
• DThe RAPIDS compatibility matrix prevents installation of cuDF 24.06 when cuDF 23.10 is already present, so the team is warned before any conflict occurs.

Why A is wrong: Python can only have one version of a package active in a given interpreter at a time. There is no automatic context-based version switching within a single installation; installing a second version simply overwrites the first.

Why B is correct: A standard Python installation holds exactly one version of each package. Upgrading cuDF for Project B overwrites the version Project A requires. The affected project then either fails to import or silently uses an API surface that has changed, risking incorrect computation without an obvious error.

Why C is wrong: pip does not perform runtime version selection. Resolution happens at install time, not import time. Once a package is installed, all scripts using that interpreter see the same version, making runtime conflict resolution impossible.

Why D is wrong: pip and conda will typically overwrite the existing version rather than block installation outright, depending on solver settings. A warning or solver error may appear, but the protection comes from isolated environments, not from a built-in compatibility matrix block.

A data scientist runs nvidia-smi on a workstation and sees a CUDA Version of 12.2 listed in the top-right corner of the output. They then run nvcc --version and it reports CUDA compilation tools release 11.8. What does this mismatch most likely indicate?

• ABoth values report the same underlying CUDA runtime, so the mismatch is cosmetic and will not affect GPU-accelerated libraries.
• Bnvidia-smi and nvcc both read from the same CUDA runtime library, so the figures should always agree and any difference points to a corrupted installation.
• CThe driver supports CUDA 12.2, but the CUDA toolkit installed for compiling is version 11.8, so compiled extensions may not match the driver capabilities.check_circle Correct
• DThe CUDA version shown by nvidia-smi reflects the toolkit release, so upgrading the driver would bring nvcc in line without reinstalling the toolkit.

Why A is wrong: This is a common misconception. The two values come from different sources - the driver and the installed toolkit - and a mismatch can cause real runtime errors when a library compiled against 12.2 tries to use toolkit-11.8 symbols.

Why B is wrong: nvidia-smi reads from the GPU driver, not the CUDA runtime library. It is normal and expected for the driver-reported CUDA ceiling to be higher than the toolkit version, so a difference does not automatically mean corruption.

Why C is correct: nvidia-smi reports the maximum CUDA version the installed driver can support, while nvcc reports the toolkit version actually installed. A gap between the two means compiled CUDA code targets an older toolkit, which can cause compatibility issues with libraries expecting 12.x features.

Why D is wrong: nvidia-smi shows the maximum CUDA version the driver supports, not the toolkit release. Upgrading the driver raises that ceiling further but does not change the installed toolkit version reported by nvcc.