NCA-ADS - Data Science Pipelines and Workflow Automation - 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

Free 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 run 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.

See more NCA-ADS practice questions, answers explained.

More in this domain

Back to all Data Science Pipelines and Workflow Automation objectives, or the NCA-ADS cert hub.

Examworthy is not affiliated with or endorsed by NVIDIA. Original, blueprint-aligned practice material only.