SnowPro Specialty: Gen AI Question 210
Single answerUsing the Snowflake Model RegistryA data science team trains several versions of a text-classification model in Snowflake using Snowpark ML. They want to manage these versions centrally, compare them, and make a selected version available for batch inference by other teams without sharing raw training code notebooks. Which approach best uses the Snowflake Model Registry for this requirement?
- A
Log each trained model version to the Snowflake Model Registry with its metrics and metadata, then let downstream teams reference the registered model version for inference.
- B
Store the model weights in an internal stage and ask downstream teams to download them locally, because the Model Registry is only for experiment tracking and not for using models later.
- C
Publish the model as a secure view so downstream teams can query predictions directly, because the Model Registry cannot version models.
- D
Convert the model into a table of coefficients and store it in a database schema, because only table objects can be governed and shared in Snowflake.
Show answer and explanation
Correct answer: A
Explanation
The best practice is to use the Snowflake Model Registry to register trained model versions and their associated metadata so teams can manage the model lifecycle inside Snowflake. This aligns with Snowflake's support for storing versioned models, tracking metrics and signatures, and making approved versions easier to use for inference workflows. In contrast, storing files in stages or encoding a model manually in tables does not provide the same lifecycle and governance benefits. Secure views are for data access patterns, not model registration. Candidates should recognize that the Model Registry is intended for centralized model management and reuse across teams, especially when the goal is to operationalize models without exposing development notebooks or ad hoc local processes.
- A. Correct.
Correct. The Snowflake Model Registry is designed to register and manage model versions along with associated metadata such as metrics, signatures, and other details. This supports centralized lifecycle management and allows teams to discover and use an approved model version for inference without depending on access to the original notebooks or local artifacts. This is the best fit for a scenario requiring versioning, comparison, and controlled reuse.
- B. Incorrect.
Incorrect. Storing model artifacts in a stage is possible for generic file storage, but it does not provide the versioned model management, metadata tracking, and standardized governance benefits of the Snowflake Model Registry. The misconception here is treating the registry as if it were only an experiment log rather than a model lifecycle management capability.
- C. Incorrect.
Incorrect. A secure view is a database object for controlled data access, not a mechanism for publishing and versioning ML models. The Snowflake Model Registry does support model versioning, so this option is based on an incorrect assumption about the registry's capabilities.
- D. Incorrect.
Incorrect. Representing a model as a table of coefficients is not a general solution, especially for modern ML models such as text classifiers that may require preprocessing logic and non-tabular artifacts. While Snowflake tables are governable objects, this approach does not provide proper model packaging, versioning, or standardized inference usage through the registry.