A transit ML team wants every ridership training job to use the same pinned scikit-learn and pandas versions. What should they define once and reuse?

Defining a curated Azure ML environment that packages the pinned Python dependencies for ridership jobs is correct because training reproducibility depends on identical package versions across runs and compute targets. Baking pinned scikit-learn and pandas (and related dependencies) into a shared environment asset lets every transit ridership training job reuse one known-good software stack. That eliminates laptop drift and documents the runtime for municipal audit and debugging. An Azure ML compute cluster that caches the pinned Python dependencies for ridership jobs fails consistency: compute provides execution hardware, not versioned software packaging, so scikit-learn and pandas versions can still drift between runs and produce non-comparable models. A versioned Azure ML data asset that bundles the pinned Python dependencies for ridership jobs fails consistency: data assets version data files for input, they do not install Python packages into the job runtime, so package drift between analysts and compute targets remains possible—unlike a single versioned environment asset every job references identically. A registered Azure ML model that embeds the pinned Python dependencies for ridership jobs captures the trained artifact after training, not the training environment, so dependency graphs can still float between runs and break the pin guarantees the stem requires. Exam caveat: environments capture conda/pip specifications (and often Docker bases) as versioned Azure ML assets. Distinguish environments (software) from compute (hardware) and from data assets (datasets). Operational check: create the curated environment with locked pins, attach it to ridership training jobs, confirm two sequential runs report the same package versions in logs, and prohibit ad-hoc pip installs on shared compute that mutate the golden stack.