NCA-ADS - Data Science Pipelines and Workflow Automation (13% of the exam) - Section 3.5
Build reproducible pipelines.
Build reproducible data science pipelines by fixing random seeds, pinning library versions, and logging all transformation parameters. Understand why reproducibility requires controlling both code and environment, not only random state.
Practice question for this objective
lock_openFree sampleData Science Pipelines and Workflow Automationmedium
A team builds a RAPIDS-based ETL and model-training pipeline. After six months, a re-run of the pipeline on the same raw data produces different model metrics. An audit finds that cuDF, cuML, and CUDA were all updated in the shared environment, and the Parquet input files were repartitioned. Which single pipeline reproducibility practice, if it had been followed from the start, would have been sufficient to catch this class of problem before the re-run?
ASet a fixed random seed at the top of every pipeline script so that all stochastic operations produce the same draw sequence
BEnsure that Dask workers process DataFrame partitions in deterministic order by sorting partition keys before any aggregation step
CCapture the full pipeline configuration - including library versions, CUDA toolkit version, and a hash or snapshot of the versioned input data - in a config artefact stored alongside each pipeline runcheck_circle Correct
DContainerise the pipeline with Docker so that the runtime environment is isolated from changes on the shared cluster
Explain why capturing the full pipeline configuration, including library versions and data snapshots, is central to reproducible pipeline practice. Reproducible pipelines require that every input and every processing decision is recorded so that a run can be faithfully reconstructed or audited later. A config artefact that logs library versions (cuDF, cuML, CUDA), random seeds, and a reference or hash pointing to the exact versioned input data creates a complete provenance record. When metrics change on re-run, comparing the stored config against the new run immediately surfaces the discrepancy, whether that is a version upgrade, a data repartition, or a seed difference. Without this artefact, the team must reconstruct what changed after the fact, which is error-prone and slow.
Why A is wrong: Fixing random seeds is necessary for stochastic reproducibility, but it does not detect or prevent changes caused by library version upgrades or repartitioned input data, which are the stated causes in this scenario.
Why B is wrong: Deterministic partition ordering prevents order-dependent aggregation variance and is a sound pipeline practice, but it cannot catch metric changes caused by library API changes or altered input files.
Why C is correct: Recording the complete configuration at run time creates a manifest that makes any deviation - version drift or data mutation - immediately visible when comparing a new run against the baseline, enabling diagnosis before results diverge silently.
Why D is wrong: Containerisation is a reproducible-environments strategy that would also have prevented the version drift, but the question asks about pipeline reproducibility practices, not environment isolation. A run-config artefact catches both version drift and data mutation regardless of whether a container is used.
Exam traps in Data Science Pipelines and Workflow Automation
Answers that look right on this material and are not. Each one is a distractor from a different question in the NCA-ADS bank for this domain.
Re-pinning the cuDF and CUDA versions before the re-run so the compute environment exactly matches the original run.
errorWhy it is wrong: Matching the environment is part of reproducibility, but the prompt states the versions are already unchanged, so it does not address the real cause, which is that the underlying data has moved.
Add a cell at the top of the notebook that clears all variables, so each top-to-bottom execution begins from an empty namespace.
errorWhy it is wrong: Clearing the namespace removes leftover variables from a prior session, but it does not fix cells whose logic still depends on an out-of-order execution path, so a clean top-to-bottom run can still diverge.
Pin the cuML and RAPIDS library versions in the project requirements file
errorWhy it is wrong: Pinning library versions prevents behaviour changes across upgrades and is essential for reproducibility, but it does not address within-version non-determinism caused by floating-point reordering on the GPU during a single training run.