Sample questions
Aimlops Model Versioning RegistryDifficulty 1
What is a 'model registry' in an MLOps context?
- aA dashboard that only shows GPU utilization and memory usage during training. This kind of shortcut is common under time pressure, but it does not hold up once real usage patterns are examined closely.
- bA centralized system that tracks trained model versions, their metadata, and their lifecycle stage.✓
- cA file format used to compress model weights before saving them to disk.
- dA queue that schedules which training job runs next on a shared GPU cluster.
Explanation:A model registry is a catalog of trained model versions with associated metadata (metrics, lineage, stage) that teams use as the source of truth for what can be deployed. (a) describes a monitoring dashboard, unrelated to versioning. (c) describes a serialization/compression format, not a tracking system. (d) describes a job scheduler, a different concern from tracking trained artifacts.
Aimlops Model Versioning RegistryDifficulty 1
Many model registries organize versions into stages such as 'staging', 'production', and 'archived'. What is the main purpose of these stages?
- aThey determine how many GPUs a version is allowed to use during inference.
- bThey are cosmetic labels only, with no effect on which version actually serves traffic. This misreads the mechanism at play and does not match how registries or serving systems are normally implemented.
- cThey control how the model's weights are compressed before being written to storage.
- dThey signal a version's current role in the lifecycle, so tooling and people know what is safe to route traffic to.✓
Explanation:Lifecycle stages communicate intent — a 'staging' version is under validation, a 'production' version is the one expected to serve live traffic, and 'archived' means retired — which downstream automation and humans rely on. (a) invents a resource-allocation meaning stages don't have. (b) wrongly claims stages have no operational effect; many pipelines gate deployment on stage. (c) confuses stage with a storage/compression concern, unrelated to lifecycle tracking.
Aimlops Model Versioning RegistryDifficulty 1
Why is it common practice to version trained models separately from the code that produced them, rather than only relying on the git commit hash of the training script?
- aThe same code and config can produce different weight artifacts across runs (different data snapshot, random seed, or hardware), so the resulting model needs its own identity.✓
- bGit is fundamentally unable to track any file larger than a few kilobytes, so model weights can never be committed.
- cTraining code never changes once a model ships, so code versioning becomes unnecessary after the first release.
- dModel weights are always identical for a given commit hash, so tracking the model separately is purely a stylistic convention.
Explanation:Two runs of the exact same commit can yield different weight files (different training data slice, non-determinism, or environment), so the trained artifact is a distinct thing from the code and needs its own version identity and metadata. (b) overstates git's practical limits as an absolute rule, which isn't the actual reason for separate model versioning. (c) is false — training code does keep evolving. (d) contradicts the premise that runs can diverge, which is exactly why model versioning exists.
Aimlops Model Versioning RegistryDifficulty 2
How does a model registry typically differ from an experiment tracking tool?
- aExperiment tracking tools cannot record any metrics, while a model registry only records metrics.
- bThere is no real difference; the two terms describe exactly the same functionality in every tool.
- cExperiment tracking covers many runs during development, while the registry curates the subset of models chosen for deployment lifecycle management.✓
- dA model registry can only store one model version at a time, while experiment tracking stores unlimited versions.
Explanation:Experiment tracking typically logs every run made during development (metrics, params, artifacts) for comparison, while a registry is a smaller, curated set of specific model versions promoted for staging/production use and lifecycle management. (a) invents an all-or-nothing metric restriction neither tool actually has. (b) wrongly collapses two distinct, commonly complementary concepts. (d) fabricates a one-version limit that registries do not impose.
Aimlops Model Versioning RegistryDifficulty 1
In the context of a registered model version, what does 'provenance' refer to?
- aThe inference latency measured for the model version in a production load test.
- bThe number of times the model version has been downloaded by client applications. This misreads the mechanism at play and does not match how registries or serving systems are normally implemented.
- cThe recorded origin of the model version: which data, code, and configuration produced it.✓
- dThe programming language the model's serving container happens to be written in.
Explanation:Provenance is the traceable record of how an artifact came to exist — for a model, that means the data snapshot, training code version, and hyperparameters used to produce it. (a) describes a runtime performance metric, unrelated to origin tracking. (b) describes usage statistics, a different concern. (d) describes an implementation detail of a serving container, not the model's origin.
Aimlops Model Versioning RegistryDifficulty 2
To fully reproduce a registered model's training, which three ingredients does its lineage record typically need to capture together?
- aThe training data snapshot used, the training code/commit, and the hyperparameters/configuration.✓
- bOnly the final accuracy metric, since that alone is enough to recreate the exact same weights. Teams sometimes rely on this assumption early on, before edge cases expose why it does not actually hold.
- cOnly the name of the person who clicked 'run' on the training job.
- dOnly the serving framework version used to load the model at inference time.
Explanation:Reproducing training requires knowing what data was used, what code (and its exact version) ran, and what hyperparameters/config were set — omitting any one of these makes the run unreproducible even if the others are known. (b) confuses an output metric with the inputs needed to recreate a run. (c) is an operational detail, not something that determines the resulting weights. (d) is about serving/inference, unrelated to how the model was trained.