What you will be able to do
- Promote and roll back model versions with the default version, aliases or tags, without changing production code
- Choose a lifecycle scheme based on who has authority to promote, and grant the right privileges
- Outline an automated retraining pipeline that ends by conditionally logging a new version to the registry
1.The default version as the production pointer
The registry is designed so you can roll out a new version without touching production code. The simplest of its four lifecycle schemes treats the default version as production. Production SQL calls my_model!predict(...) without naming a version, so it always runs the default. When a retrained version passes evaluation, you promote it by making it the default. Pre-release versions can still be called explicitly by name with MODEL(my_model, new_version)!predict(...).
The first logged version is the default automatically. If production must not use the model before it's ready, log an initial version that immediately throws an error, and keep it as the default until a real version replaces it. Rollback uses the same mechanism as promotion. The default is just a pointer, so if the newly promoted version misbehaves, you set the default back to the previous version, which is still registered. Use this scheme when the model owner decides what goes to production and you only need two stages: development and production.
default_version = m.default
m.default = "v2"Checkpoint 1 of 7· Fill the gap
Which property completes this statement, which promotes new_version to production under the default-version scheme?
ALTER MODEL my_model SET ? = new_version;Under this scheme, production calls the model without naming a version, so setting DEFAULT_VERSION promotes the version. Setting it back to the prior version rolls back.
Source: docs.snowflake.comCheckpoint 2 of 7· Exam question
A platform team wants batch scoring jobs to use a stable name for the approved fraud model while data scientists keep logging new versions. Which design fits Snowflake Model Registry best?
Correct answer: B — Assign a `PROD` alias to the approved version and have jobs call `MODEL(FRAUD, PROD)!PREDICT(...)`, moving it on each approval.
- A. Incorrect: versions are not renamed for promotion, and two versions could not both be named PROD while history is kept.
- B. Correct: an alias is a movable pointer resolved directly in `MODEL(name, alias)`, so promotion becomes a single alias reassignment.
- C. Incorrect: parsing free-text comments is brittle and not a supported way to select a version at call time.
- D. Incorrect: tags classify objects but are not resolved by `MODEL(...)` calls, so jobs would need extra lookup logic.
Sources1
2.Aliases for multi-stage lifecycles
Many teams track more stages than development and production, such as alpha, beta, canary or deprecated. Aliases are user-defined labels on model versions. You can use an alias anywhere a version name is accepted, in Python or in SQL. Each alias points to only one version at a time. To move an alias, you unset it on the old version and set it on the new one. Production then calls MODEL(my_model, production)!predict(...), and testers call the alpha or beta alias in the same way.
ALTER MODEL my_model VERSION v1 UNSET ALIAS;
ALTER MODEL my_model VERSION v2 UNSET ALIAS;
ALTER MODEL my_model VERSION v2 SET ALIAS = production;Checkpoint 3 of 7· Put it in order
Put the alias-based lifecycle for a new version v2 in order. v1 currently holds the production alias.
- 1.Remove the production alias from v1 and the beta alias from v2
- 2.Log v2 and set its alias to alpha
- 3.Unset v2's alias and set it to beta
- 4.Call MODEL(my_model, production)!predict(...) from production code
- 5.Set v2's alias to production
A new version enters as alpha and is then promoted to beta. Finally, the production alias moves from the old version to the new one, so production code that calls the alias picks up v2 unchanged.
“remove the production alias from the current production version, here v1, and apply it to the new version, here v2.”Source: docs.snowflake.com
Every model also has three system aliases that you can't redefine. DEFAULT is the default version, FIRST is the oldest version by creation time, and LAST is the newest version by creation time. The alias names you create can't collide with these or with any existing version name. Note that LAST changes whenever a version is logged, whether or not anyone promoted it.
Checkpoint 4 of 7· Check yourself
A nightly scoring job runs SELECT MODEL(CHURN, LAST)!PREDICT(...). A data scientist logs experimental version V9 without promoting it, and the next night's scores change. Why?
LAST follows creation time, not promotion. Production code should call the default or a curated alias such as production.
“LAST refers to the newest version of the model by creation time.”Source: docs.snowflake.com
Sources2
3.Tags, schemas and privileges when someone else promotes
The default-version and alias schemes both assume the model owner decides what reaches production. In many organizations a production engineering role makes that decision instead. Two schemes support that split. In the tag scheme, a production role creates a tag such as live_version in its own schema and sets it on the model to the name of the live version. Tags are secured by role-based access control, so data scientists can't change the tag. Production code reads the tag with SYSTEM$GET_TAG, where the object domain for models is MODULE, and then calls the named version.
-- get production model version from live_version tag
SET live_version = (SELECT
SYSTEM$GET_TAG('prod_db.prod_schema.live_version', 'my_model', 'MODULE'));
-- call that version
SELECT MODEL(my_model, IDENTIFIER($live_version))!predict(...) FROM ... ;For that setup, the production role needs APPLY TAG on the account and USAGE on the model's schema. Creating the tag requires CREATE TAG on the schema. The multiple-schemas scheme separates environments more strongly. Production code calls models only in a dedicated production schema, and a version is copied there when it's ready. The copies are separate objects with their own access control, which protects them from accidental changes by developers. The role that does the copying needs OWNERSHIP or READ on the source model.
| Privilege | What it allows |
|---|---|
| OWNERSHIP | Full control: manage versions, access artifacts, update metadata; only one role can own the model |
| USAGE | Warehouse inference plus SHOW MODELS / SHOW VERSIONS IN MODEL; no access to code, weights or artifacts |
| READ | SPCS inference, model files and metadata, plus SHOW MODELS / SHOW VERSIONS IN MODEL |
Checkpoint 5 of 7· Match them up
Match each lifecycle scheme to the situation it fits
Tap a term, then the definition that fits it.
The first two schemes leave promotion with the model owner. Tags and separate schemas let another role control what goes to production.
“Tags are securable by role-based access control and are suitable for this separation of responsibility.”Source: docs.snowflake.com
Sources1
4.Automating retraining into the registry
The registry is where an automated retraining pipeline ends. Snowflake's guidance is to start with interactive development, then harden the pipeline and automate it with CI/CD. To prepare, split the code into modular functions for data preparation, feature engineering, training and evaluation. Parameterize table names and hyperparameters, and write an entrypoint script that runs the whole pipeline end to end.
| Stage | Tool | Role in retraining |
|---|---|---|
| Model Training | ML Jobs | Runs resource-intensive training on high-memory, GPU or distributed compute |
| Model Deployment | Model Registry | Registers and versions each retrained model, supporting promotion and rollback |
| Model Monitoring | Model Monitoring | One monitor per model version that surfaces drift and performance signals |
| Workflow Orchestration | Task Graphs | Runs the pipeline as a DAG on a schedule or on event-based triggers |
| Workflow Orchestration | Scheduled Notebooks | Runs a parameterized notebook non-interactively on a schedule |
In a Task Graph, each step is a task, and a child task runs only after all its predecessor tasks have completed successfully. Snowflake's reference pipeline reads features, trains with an ML Job, evaluates the model, and only then *conditionally* logs it to the Model Registry. The new version doesn't replace production automatically. It's promoted through the default version, an alias or a tag, as described above. Monitoring is set up per version, so a newly promoted version needs its own monitor.
Checkpoint 6 of 7· Check yourself
Which design best automates retraining with the Snowflake tools above?
Each retrain becomes a new, evaluated version, and production changes only when a promotion moves its pointer. Reusing a version name is not allowed, and LAST would skip the promotion gate.
“The pipeline concludes by evaluating the trained model and conditionally logging the trained model to Model Registry for downstream consumption.”Source: www.snowflake.com
Checkpoint 7 of 7· Exam question
A governance team must list every registered model trained on customer PII across several schemas and report the owning team of each. Which approach is most appropriate?
Correct answer: B — Create a tag like `data_sensitivity` with approved values, set it with `ALTER MODEL ... SET TAG`, and query the tag references views.
- A. Incorrect: `QUERY_TAG` labels queries in query history, not the objects those queries create.
- B. Correct: object tags are governed key-value metadata attachable to models and discoverable through `TAG_REFERENCES`, supporting cross-schema reporting.
- C. Incorrect: free-text comments have no controlled vocabulary and a regex search will miss variants and typos.
- D. Incorrect: aliases point at versions within one model and are not a governance classification surfaced by `SHOW MODELS`.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.MODEL(my_model, LAST) is a safe way for production to follow the latest approved model.Why is that wrong?
LAST is a system alias for the newest version by creation time, so any logged version, promoted or not, replaces it. Production should call the default or a curated alias.
Covered in Aliases for multi-stage lifecycles
2.USAGE on the development model is enough for a release role to copy versions into the production schema.Why is that wrong?
USAGE allows only warehouse inference and SHOW commands, with no access to artifacts. The promoting role needs OWNERSHIP or READ on the source model.
Covered in Tags, schemas and privileges when someone else promotes
3.After a retrained version is promoted, the existing model monitor starts tracking it.Why is that wrong?
Monitors are created per model version, so a newly promoted version needs its own monitor.
Covered in Automating retraining into the registry
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.snowflake.com/en/developer-guide/snowflake-ml/model-registry/model-managementOfficial docs
“you promote a model version to production simply by setting it as the default”
↩︎ The default version as the production pointer“How to roll out a new version of a model without any changes to production code.”
↩︎ The default version as the production pointer“you might log an initial version that immediately throws an error.”
↩︎ The default version as the production pointer“The SQL domain of models, for use with SYSTEM$GET_TAG, is MODULE.”
↩︎ Tags, schemas and privileges when someone else promotes“Because the production models are separate objects with their own access control, you can protect them from accidental modification”
↩︎ Tags, schemas and privileges when someone else promotes“Roles with only USAGE cannot access the model code, weights, or other artifacts.”
↩︎ Tags, schemas and privileges when someone else promotes“the role that promotes models to production should have OWNERSHIP or READ privilege on the source model.”
↩︎ Exam trap 2“A model must always have a default version.”
↩︎ Prediction“remove the production alias from the current production version, here v1, and apply it to the new version, here v2.”
↩︎ Checkpoint“Tags are securable by role-based access control and are suitable for this separation of responsibility.”
↩︎ Checkpoint - 2.
“A given alias can be assigned to only one model version at a time.”
↩︎ Aliases for multi-stage lifecycles“Alias names you create must not be the same as any existing version name or alias in the model, including system aliases.”
↩︎ Aliases for multi-stage lifecycles“LAST refers to the newest version of the model by creation time.”
↩︎ Exam trap 1“LAST refers to the newest version of the model by creation time.”
↩︎ Checkpoint - 3.
“Operationalize your ML pipeline into a Directed Acyclic Graph (DAG) and configure it to run on a schedule or by event based triggers.”
↩︎ Automating retraining into the registry“pipelines are hardened and automated with CI/CD (Continuous Integration/Continuous Delivery).”
↩︎ Automating retraining into the registry“Parameterize all configuration values like table names and hyperparameters to enable cross-environment deployment.”
↩︎ Automating retraining into the registry“Create a monitor per model version to materialize inference logs and automatically refresh daily metrics”
↩︎ Exam trap 3 - 4.
“The child task runs only after all specified predecessor tasks have successfully completed their own runs.”
↩︎ Automating retraining into the registry
Also cited
“The pipeline concludes by evaluating the trained model and conditionally logging the trained model to Model Registry for downstream consumption.”
↩︎ Checkpoint