SnowPro Specialty: Gen AI Question 44
Single answerUsing Snowflake Model Registry (custom model)A data science team has trained a custom text-classification model outside Snowflake and wants to operationalize it in Snowflake for governed batch inference. They need to version the model, keep metadata about each release, and promote newer versions without changing downstream SQL or Python consumer code more than necessary. Which approach best meets these requirements using Snowflake Model Registry?
- A
Register the custom model in Snowflake Model Registry, log each release as a new model version, and have consumers call the model through the registry-managed versioned interface or a designated default version.
- B
Store the model artifact in an internal stage and let analysts load the file directly in their SQL queries whenever they need predictions.
- C
Create a separate Snowflake account for each model version so production users can choose which account contains the correct release.
- D
Convert every new model version into a different table of precomputed predictions and require downstream applications to switch tables when a new version is released.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake Model Registry as the system of record for the custom model and its versions. In Snowflake ML workflows, Model Registry is intended to store and manage models with metadata, versioning, and controlled promotion, which is especially useful when teams need repeatable deployment and governed inference. This supports a practical MLOps pattern: train externally or in Snowflake, register the model, log successive versions, and let downstream consumers access a stable registered asset rather than raw files or ad hoc tables. By contrast, stages are for artifact storage, not full model lifecycle management; separate accounts are not a versioning strategy; and swapping prediction tables forces avoidable downstream changes. This aligns with Snowflake documentation and best practices around Model Registry for managing custom models, model versions, and production inference workflows.
- A. Correct.
Correct. Snowflake Model Registry is designed to manage ML models as governed assets, including custom models, with support for model versioning and metadata. Registering the model and logging each release as a new version allows teams to track changes, manage lifecycle, and promote versions in a way that minimizes downstream changes. Consumers can reference the registered model and use version-aware access patterns rather than hard-coding artifact locations.
- B. Incorrect.
Incorrect. An internal stage can store files, but it does not provide the governance, model lifecycle management, version tracking, or registry semantics required here. Analysts also cannot simply load arbitrary model files directly in SQL for inference as a general pattern. This option reflects the misconception that artifact storage alone is equivalent to model management.
- C. Incorrect.
Incorrect. Snowflake accounts are organizational boundaries, not a model versioning mechanism. Creating an account per version adds unnecessary operational complexity, weakens maintainability, and does not align with Model Registry best practices. Versioning should occur within the registry, not by duplicating environments for every release.
- D. Incorrect.
Incorrect. Precomputing predictions into separate tables may help in some reporting scenarios, but it does not solve the stated need to manage the custom model itself as a versioned asset for ongoing inference. It also increases downstream maintenance because applications must be updated to point to new tables whenever the model changes. This is the opposite of minimizing consumer impact.