Why version data and model artifacts, not just code

WHAT THIS TESTS This checks whether you understand that a trained model is the joint product of code, data, and configuration, so reproducibility and recovery require versioning all of them. It rewards a concrete failure scenario.

A GOOD ANSWER COVERS Unlike traditional software, where the same code reliably produces the same binary, an ML model depends on the training data and hyperparameters as much as the code. If you version only the code, you cannot reconstruct exactly which model was running when something broke, nor reproduce it for debugging. Versioning the training data, the trained model artifact, and the config gives you several capabilities: exact reproducibility of any past model, fast and safe rollback to a previous known-good version when a new release misbehaves, the ability to diagnose a regression by comparing what changed across versions, and audit or regulatory traceability proving which data and model produced a given decision. It also enables A/B comparison and lineage tracking from a prediction back to its inputs.

COMMON WRONG ANSWERS Claiming Git on the code is enough. Ignoring rollback, so you have no way to revert when a deploy degrades performance. Forgetting compliance and audit needs in regulated domains. Assuming the data is static and never changes.

LIKELY FOLLOW-UPS What tools enable data versioning at scale? How do you link a prediction back to the exact model and data that produced it? How do you store large artifacts efficiently?

ONE CONCRETE EXAMPLE An upstream ETL job silently changes how a key feature is computed. The next scheduled retraining ingests the altered data and the new model's quality quietly drops in production. Because only code was versioned, the team cannot reproduce or roll back to the previous model and spends days reconstructing what changed. With data and artifact versioning, they would have immediately rolled back to the last good model and diffed the data versions to find the ETL change in minutes.