NCP-ADS Practice Questions: 20 Exam-Style Scenarios Explained (2026)

Row-wise Python callables cannot use the GPU's parallelism; they serialize work and often force slow paths, so the fix is to express the logic as vectorized operations (.str accessors, where, masks) that run as GPU kernels across all 80 million rows at once. A misdiagnoses the problem: memory headroom does nothing for a compute-bound serialized step. C reintroduces a CPU bottleneck plus a device-to-host copy in the middle of the pipeline. D keeps the slow pattern and just runs it several times.

Dask-cuDF splits the dataset into partitions and streams them through the GPU, so the working set at any moment fits in device memory, and spilling (moving idle partitions to host RAM) covers the moments when intermediate results exceed it. Together they make out-of-core processing routine. B is backwards: CSV is larger and slower to parse than columnar Parquet. D doubles memory per value (float64 is 8 bytes against float32's 4) and makes the problem worse.

The accelerator mode (cudf.pandas) intercepts pandas calls, executes supported operations on the GPU, and transparently falls back to CPU pandas for corner cases, which is exactly the zero-rewrite, works-everywhere constraint described. A is months of engineering for a team that asked for this quarter. B adds a migration without adding a GPU. D multiplies CPU workers on a workload the scenario already wants on the GPU.

Join memory scales with row width and key size, so casting int64 keys with 40,000 distinct values down to int32 and replacing repeated strings with categorical codes shrinks both inputs and the join's intermediate buffers, often by several times. A changes the join algorithm's access pattern without shrinking data. B trades the crash for a job that runs an order of magnitude slower and still copies everything off the device. C helps only if something also gets smaller per partition; alone, the wide rows still blow up each piece.

GPUs earn their cost through parallelism, and single-item inference wastes it; dynamic batching (an inference server collecting requests that arrive within a few milliseconds of each other into one batch) recovers that parallelism while staying inside the latency budget. B fails the requirement outright: fraud decisions are needed at transaction time. C multiplies memory-hungry model replicas while each still runs batch-of-one. D couples model runtime to the database and has no GPU story at all.

Reproducibility has two failure sources: the software stack and the randomness. A pinned environment (identical library, CUDA, and dependency versions via lockfile or container) removes the first, and fixed seeds plus deterministic flags remove the second, within the limits each library documents. A does the opposite of pinning, introducing drift per machine. C is observability: worth having, but it reports the disagreement instead of preventing it.

The failure described is data drift: a new segment shifts the input distribution long before enough labels accumulate for accuracy metrics to move. Monitoring feature and prediction distributions (comparing live traffic against the training distribution and alerting on divergence) catches that shift in days. A watches the hardware, which is healthy. B spends compute on a cadence with no signal attached and can silently learn the miss. D makes a lagging indicator more precise while leaving it just as lagging.

Training/serving skew (features computed differently at training time than at inference time) is an environment and code-path problem, so the durable fix is a single source of truth: the same image, the same preprocessing module, the same versions in both places. B detects a fraction of the damage after it ships. C teaches the model to live with a bug instead of removing it. D pins today's inconsistency in place permanently, updates were never the root cause.

With heavy right skew, the mean is dragged upward by the outlier tail, so mean imputation injects values that look like moderately large transactions into 4% of rows; the median is robust to that tail and represents a typical transaction. Dropping 12 million rows discards signal in the other columns for no reason. Zero-filling invents a spike of impossible values at zero that a linear model will happily learn; if used at all it needs a missingness indicator, which the option explicitly omits.

One-hot encoding creates 1.2 million columns, which no amount of hardware makes sensible for a tree model; target encoding (replacing each category with a statistic of the label for that category, fitted with leakage controls) or frequency encoding keeps the merchant signal in a single dense column. A spends cluster money to preserve a representation that tree models do not need. B throws away a feature the scenario says is predictive. C is a legitimate family, but 100 arbitrary buckets for 1.2 million merchants destroys most of the signal the question asks you to keep.

cuDF's .str methods run string kernels across the whole column in parallel, and expressing the cleanup as a chain of those vectorized calls keeps all 50 million rows on the device with no per-row Python involvement. C is the canonical anti-pattern: a device-to-host copy, a serial Python loop, and a copy back, every hour. D adds file I/O and a second toolchain to something the DataFrame library does natively, and loses dtype fidelity along the way.

A 21 GB float64 frame becomes roughly 10.5 GB in float32, and every intermediate buffer the pipeline creates shrinks with it, which typically turns an OOM crash into comfortable headroom at zero accuracy cost when the model tolerates single precision (the scenario states it does). A spends money to avoid a one-line dtype fix. B abandons the GPU speedup to dodge a solvable memory problem. D sacrifices model inputs when nothing about the features was the issue.

LocalCUDACluster (from the dask-cuda package) exists for exactly this: it spawns one worker process pinned to each GPU, wires in device memory management and spilling, and the Dask client then distributes partitions across the four workers. A runs the same job four times with no coordination and no data splitting. C describes an API that does not exist; a cuDF DataFrame lives on one device. D adds CPU threads to one process, which does nothing to enlist the other three GPUs.

Spot and preemptible instances (spare cloud capacity sold at a steep discount that the provider can reclaim with short notice) are the textbook fit for fault-tolerant batch work, and this job already checkpoints and resumes, so an interruption costs at most ten minutes of progress. A rearranges the same on-demand spend. B locks in list price, which is the opposite of a saving, reserved pricing only helps below list and still exceeds spot. C cuts cost by cutting the model's training budget, which changes outcomes the scenario said to leave alone.

Early-stopping search strategies (successive halving and its variants allocate a small budget to many configurations, then promote only the promising ones) routinely cut sweep cost by an order of magnitude at equal final quality, which compounds with the GPU speedup. B multiplies every grid point by ten evaluations, buying variance reduction the sweep does not need at this stage. C assumes hyperparameters do not interact, which regularly picks the wrong region of the space. D triples the cost of the exhaustive approach the question is trying to escape.

XGBoost has first-class GPU training: set the device to CUDA (current releases use device="cuda"; older ones used the gpu_hist tree method) and it consumes GPU-resident data, avoiding the round trip through host memory entirely. A serializes 90 million rows to text, the slowest possible hand-off. C forces a device-to-host copy that the direct integration exists to avoid. D is an ensemble workaround that keeps the 70-minute problem, ten times over, and changes the model.

At 0.4% prevalence, a model that predicts "not fraud" every time scores 99.6% accuracy, so the metric is the mirage; precision-recall metrics (and PR-AUC) measure what the model does on the rare class you care about. Pairing that with imbalance handling during training (class weights or resampling so positives influence the fit) attacks the cause. A polishes a meaningless number. B changes how much data judges the model without changing the broken yardstick doing the judging.

The dataset is already on the GPU, and grouped aggregations, correlations, and quantiles are exactly the operations cuDF executes in seconds at this scale, so the full-population answer is now cheaper than the workaround; sampling adds error for zero benefit. B is a bigger version of the unnecessary compromise, and rare segments still vanish. C converts an interactive loop into a day-long cadence. D collapses at 150 million rows long before it renders a chart.

cuGraph is the RAPIDS graph library built for precisely this hand-off: the edge list is already a cuDF DataFrame, and its GPU PageRank implementation handles billions of edges, turning the sampled prototype into a full-graph production job. A scales memory but keeps single-threaded Python graph traversal, which is the actual bottleneck. B expresses an iterative algorithm in a language hostile to iteration; it will be slow and fragile. D answers a different question, influence within a tiny subgraph, and fraud rings rarely live only among the biggest hubs.

Aggregation-based rendering rasterizes the full 120 million points into a density image (each pixel shows how many points landed there), which is built for exactly this scale and preserves the structure that sampling destroyed; the RAPIDS ecosystem pairs cuDF with such renderers for interactive speed. A produces 100 slow, uncomparable plots. C is the same information loss the analyst already rejected, with prettier markers. D is a crude form of binning that aliases patterns and still leaves millions of points to draw.