Which practice best reflects recommended AI engineering discipline for versioning code, datasets, and trained models together?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Let me show you how this works in the real world. Code goes in Git—you already know that drill. Data and big model blobs? Different story. Drop multi-gigabyte training sets into plain Git and you'll cry. That's why tools like DVC sit alongside Git: they version data and models, point at remote storage, and keep experiments reproducible. Imagine your boss walks in: "Recreate last quarter's champion model." If the answer is "it lived on Sam's laptop under final_v7_really_final," you're in trouble. No backups? Hard no. Fancy filenames alone? Still chaos. Pair Git for code with DVC-style tracking for data and models, and you can move fast without losing the plot. Exam loves this best practice—remember it.
Full explanation below image
Full Explanation
Reproducible AI systems require coordinated versioning of application and training code, datasets (and often features), configuration, and model artifacts. Without that coordination, teams cannot reliably answer which data and code produced a given model, cannot roll back safely after a bad release, and cannot audit behavior for compliance or incident response. A widely recommended pattern is to use Git for source code and lightweight metadata while employing data-oriented versioning tools such as DVC (Data Version Control), lakeFS, or platform-native model and dataset registries for large binary assets that do not belong in a standard Git history.
The correct practice pairs Git with DVC-like tooling so that commits can reference specific data and model versions stored in remote object storage, enabling clone, checkout, and pipeline reproduction across machines. DVC tracks hashes and pointers rather than stuffing huge files into Git, preserves lineage for pipeline stages, and supports team collaboration with shared remotes. Model registries and artifact stores complement this picture for deployment stages, but the core best practice in many curricula and industry guides remains: version code properly and version data/models with purpose-built mechanisms.
Avoiding backups is never a best practice; it trades short-term convenience for unacceptable risk of data loss and irreproducible science. Simply renaming files for each version is a common beginner habit that does not provide branching, merging, attribution, conflict management, or cryptographic integrity checks that version control systems supply. Storing everything on a single computer centralizes risk, hinders parallel work, and makes continuous integration and multi-environment promotion impractical.
Operational best practices include immutable identifiers for datasets and models, linking experiment runs to commit hashes and data versions, automating tests when versions change, and defining retention policies so storage costs stay controlled without deleting the ability to reproduce critical releases. Teams should document how to restore a historical training run end to end. On exams and in production reviews, choosing Git plus data/model versioning tools demonstrates mature MLOps thinking: treat AI assets with the same rigor software engineering applies to code, extended to the data-dependent nature of machine learning systems across the full lifecycle from experimentation through monitoring and controlled rollback when production metrics degrade unexpectedly after a release.