What you will be able to do
- Name the Snowflake-native object that replaces each part of an external MLOps toolchain
- Explain the governance advantage of managing models as Snowflake objects under RBAC
- Choose between Experiments, Datasets and the Feature Store for tracking and reproducible training inputs
- Identify ML Observability and Explainability as replacements for external monitoring and attribution tooling
1.The Model Registry as the governed model store
An external MLOps stack usually spreads work across separate tools: one tracks experiments, another versions data, another stores features, another stores models, and others monitor and explain predictions. Moving onto Snowflake means replacing each of these with a native object that lives in a database and schema next to your data. The table maps each need to its replacement. The rest of this page covers what sets each one apart.
| Workflow need | Snowflake-native alternative |
|---|---|
| Model store, versioning and serving | Snowflake Model Registry |
| Experiment tracking: runs, parameters, metrics, artifacts | Snowflake ML Experiments |
| Versioned, reproducible training data | Snowflake Datasets |
| Shared, refreshed feature definitions | Snowflake Feature Store |
| Production drift and performance monitoring | ML Observability |
| Per-feature prediction attribution | Model Registry explainability function (Shapley values) |
The registry is at the center. Snowflake calls logging a model "the first and most significant step in your Snowflake ML Ops journey," because it puts your ML operations under Snowflake's control, security and governance. Models are first-class objects, so the standard governance features apply to them unchanged: role-based access control, plus the INFORMATION_SCHEMA.MODEL_VERSIONS view for querying every model and version. Version rollout is designed so a new model version can go live without any changes to production code.
Access comes from ordinary grants. There are three privileges, and they split along the inference path a consumer uses.
GRANT USAGE ON MODEL my_model TO ROLE prod_role;
-- OR
GRANT READ ON MODEL my_model TO ROLE prod_role;Checkpoint 1 of 6· Match them up
Match each model privilege to what it allows
Tap a term, then the definition that fits it.
USAGE covers warehouse prediction without exposing artifacts. READ adds SPCS inference and model files. OWNERSHIP is full control.
“Roles with only USAGE cannot access the model code, weights, or other artifacts.”Source: docs.snowflake.com
Checkpoint 2 of 6· Exam question
A model uses a proprietary scoring library that the Snowflake Model Registry does not support natively. Which approach lets the team register it without rewriting the model?
Correct answer: A — Subclass `CustomModel`, load serialized files through `ModelContext`, and expose a `@custom_model.inference_api` method that returns a pandas DataFrame.
- A. Correct: CustomModel with ModelContext is the documented bring-your-own-model mechanism, and inference_api methods define the callable interface and signature.
- B. Incorrect: views are not a registry model type and cannot hold serialized scoring logic or a signature.
- C. Incorrect: aliases attach to model versions only; a stored procedure is not a registry object and gains no versioning from an alias.
- D. Incorrect: worksheet scripts are not converted into model versions; models enter the registry through log_model or the supported import paths.
Sources1
2.Experiments in place of an external tracking server
Snowflake ML Experiments replaces a separate experiment-tracking service. An experiment is a series of runs, and each run holds its own parameters, metrics and artifacts. Snowflake doesn't restrict what you upload as an artifact. Results show up in Snowsight under AI & ML » Experiments and can also be retrieved from Python or SQL. Experiments need snowflake-ml-python 1.19.0 or later, plus the CREATE EXPERIMENT privilege on the schema where run artifacts are stored.
There are two ways to record runs. For XGBoost, LightGBM and Keras, autologging registers a callback that records parameters and metrics during fit. Migrated models were usually trained elsewhere and arrive pre-trained, so the manual API is the one that applies to them.
# Log model parameters with the log_param(...) or log_params(...) methods
exp.log_param("learning_rate", 0.01)
exp.log_params({"optimizer": "adam", "batch_size": 64})
# Log model metrics with the log_metric(...) or log_metrics(...) methods
exp.log_metric("loss", 0.3, step=100)
exp.log_metrics({"loss": 0.4, "accuracy": 0.8}, step=200)Experiments also connect to the registry. exp.log_model(...) logs a model into the experiment's model registry, and exp.log_artifact(...) attaches local files to the run. When a run executes on a Snowflake Notebook or an ML Job, live logging can send stdout and stderr to the default event table so they appear in the run's Logs tab.
Checkpoint 3 of 6· Check yourself
A team brings a pre-trained PyTorch model from another platform and wants its evaluation metrics recorded in Snowflake ML Experiments. What should they do?
Autologging covers XGBoost, LightGBM and Keras during training. Pre-trained models or unsupported frameworks use manual logging.
“For models which don’t support automatic logging or are pre-trained, you can manually log experiment information and upload artifacts in Python.”Source: docs.snowflake.com
Sources2
3.Datasets and the Feature Store for training inputs
A model you migrate is only reproducible if you can rebuild its training inputs. Two native objects handle this, and they solve different problems.
Snowflake Datasets take over the data-versioning job. A Dataset is a schema-level object made of versions, and each version holds a materialized snapshot of your data with guaranteed immutability. Snowflake recommends Datasets when you need to version large datasets for reproducible training and testing, when you need file-level access or shuffling for distributed training, when you integrate with external ML frameworks, or when you need to track the lineage behind a model. Datasets incur storage costs, and creating one requires the CREATE DATASET privilege on the schema.
The Snowflake Feature Store takes over the feature-platform job. It centralizes feature transformations so teams can reuse them, refreshes feature values from source data through Snowflake-managed Feature Views, and supports point-in-time correct backfills with ASOF JOIN. Its data stays inside Snowflake under your governance, and it integrates with the Model Registry. ML Lineage traces each model back from dataset to feature to source, which also lets a model retrieve the correct feature values at inference time.
A migration doesn't have to rewrite every pipeline. The Feature Store explicitly supports user-managed feature pipelines built with external tools such as dbt, so existing transformation code can keep feeding it.
Checkpoint 4 of 6· Check yourself
A migrated model must be retrainable on exactly the same data it was originally trained on. Which Snowflake object fits?
Datasets exist for versioning data for reproducible training. A Feature View's refresh is useful for fresh features, but it means the data changes over time.
“Each version holds a materialized snapshot of your data with guaranteed immutability”Source: docs.snowflake.com
Checkpoint 5 of 6· Exam question
A data science group has MLflow pyfunc models in a Databricks workspace and must serve them from Snowflake. Which action is the most direct migration step?
Correct answer: A — Load the pyfunc model in a Python environment and register it with `Registry.log_model`, supplying a signature or `sample_input_data` and pinned package versions.
- A. Correct: the Model Registry supports MLflow models, so loading the artifact and calling log_model with a signature and pinned dependencies creates a native model version.
- B. Incorrect: no proxy MLflow server is required; the registry stores the model itself rather than forwarding calls to an external tracking service.
- C. Incorrect: copying metadata tables does not move the model artifact and the registry does not auto-discover models from user tables.
- D. Incorrect: retraining is unnecessary because MLflow models can be logged to the registry directly.
4.Observability and explainability without extra libraries
ML Observability replaces external drift-monitoring tools for models deployed through the Model Registry. It tracks performance, drift and volume, and it can break those down by string categorical segments. Regression, binary classification and multi-class classification models are supported. Monitors read a log table of IDs, timestamps, features, predictions and ground truth labels, so they work whether inference ran in Snowflake or outside it with results written back. You create one monitor object per model version. It is a strict one-to-one link, the aggregation window is at least one day, and you can add a baseline table for drift comparisons.
Explainability replaces a separately installed attribution library. The registry has a built-in explainability function based on Shapley values, which attribute a model's output to its input features by measuring each feature's average marginal contribution across combinations of features. This matters most in regulated industries such as finance and healthcare, which may need stronger evidence that a model produces the right results for the right reasons.
Checkpoint 6 of 6· Check yourself
After migration, a risk team needs per-feature attributions explaining individual predictions from a registered model. What should they look for first?
Feature attribution is what the registry's Shapley-based explainability function does. Drift reports, run metrics and lineage answer different questions.
“the Snowflake Model Registry includes an explainability function based on Shapley values”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Adopting the Snowflake Feature Store means rewriting existing dbt feature pipelines as managed Feature Views.Why is that wrong?
The Feature Store supports user-managed pipelines built with external tools such as dbt, alongside Snowflake-managed Feature Views.
Covered in Datasets and the Feature Store for training inputs
2.One ML Observability monitor can cover all versions of a model, so you set it up once per model.Why is that wrong?
Monitors and model versions are paired one-to-one, so every version you want to monitor needs its own monitor.
Covered in Observability and explainability without extra libraries
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
“Logging your model in the registry is the first and most significant step in your Snowflake ML Ops journey”
↩︎ The Model Registry as the governed model store“you can use all standard Snowflake governance capabilities with them, including role-based access control and the information schema.”
↩︎ The Model Registry as the governed model store“How to roll out a new version of a model without any changes to production code.”
↩︎ The Model Registry as the governed model store“Roles with only USAGE cannot access the model code, weights, or other artifacts.”
↩︎ Checkpoint - 2.
“Each experiment consists of a series of runs, which are metadata and artifacts from your training.”
↩︎ Experiments in place of an external tracking server“You can autolog training information for XGBoost, LightGBM, or Keras models during model training.”
↩︎ Experiments in place of an external tracking server“Snowflake Experiments require snowflake-ml-python version 1.19.0 or later.”
↩︎ Experiments in place of an external tracking server“For models which don’t support automatic logging or are pre-trained, you can manually log experiment information and upload artifacts in Python.”
↩︎ Checkpoint - 3.
“You need to manage and version large datasets for reproducible machine learning model training and testing.”
↩︎ Datasets and the Feature Store for training inputs“Each version holds a materialized snapshot of your data with guaranteed immutability”
↩︎ Checkpoint - 4.
“Your data remains secure, completely under your control and governance, and never leaves Snowflake.”
↩︎ Datasets and the Feature Store for training inputs“Backfill and point-in-time correct features with ASOF JOIN”
↩︎ Datasets and the Feature Store for training inputs“Ability to use user-managed feature pipelines with external tools such as dbt”
↩︎ Exam trap 1 - 5.https://docs.snowflake.com/en/developer-guide/snowflake-ml/model-registry/model-observabilityOfficial docs
“ML Observability allows you to track the quality of production models you have deployed via the Snowflake Model Registry across multiple dimensions”
↩︎ Observability and explainability without extra libraries“Each model version can have exactly one monitor, and each monitor can monitor exactly one model version”
↩︎ Exam trap 2“Even in cases where inference is run outside Snowflake, it is common to store the results in Snowflake.”
↩︎ Prediction - 6.https://docs.snowflake.com/en/developer-guide/snowflake-ml/model-registry/model-explainabilityOfficial docs
“Industries that have regulations around trustworthy systems, like finance and healthcare, might require stronger evidence”
↩︎ Observability and explainability without extra libraries“the Snowflake Model Registry includes an explainability function based on Shapley values”
↩︎ Checkpoint