SnowPro Specialty: Gen AI Question 27
Single answerControl model accessA financial services company is enabling Snowflake Cortex AI functions for several business units. The security team wants analysts in the RISK role to use only an approved subset of LLMs for inference, while preventing access to higher-cost or non-approved models. Other teams may continue using the full set of available models. Which action should the Snowflake administrator take to meet this requirement with the least operational overhead?
- A
Create a network policy for the RISK role that blocks requests to non-approved models.
- B
Create a Cortex model allowlist for the RISK role that includes only the approved models.
- C
Grant USAGE on the approved models directly to the RISK role and revoke model access from all other roles.
- D
Use masking policies on prompts submitted by the RISK role so only approved models can process unmasked data.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to restrict model availability for the specific role by using Snowflake's Cortex model access controls, typically implemented through a role-based allowlist of approved models. This is the most appropriate mechanism for controlling which LLMs a role can use for inference. It satisfies the requirement to limit the RISK role to approved models, supports least-privilege governance, and avoids unnecessary impact on other teams.
The key distinction is that model access is a governance control specific to Cortex AI usage, whereas network policies govern connection origins and masking policies govern data visibility. Candidates should recognize that practical Snowflake security design uses the native control closest to the requirement: role-based model access restrictions for controlling approved model usage.
This reflects Snowflake best practices for AI governance: restrict model access by role, approve only needed models, and separate model governance from data governance and network security controls.
- A. Incorrect.
Incorrect. Network policies in Snowflake control where users can connect from, such as allowed IP addresses, not which Cortex models a role can invoke. This is a common confusion between connection-level controls and feature-level authorization.
- B. Correct.
Correct. Snowflake supports controlling access to Cortex models by defining which models are available to specific roles. Using a model allowlist for the RISK role is the most direct way to restrict that role to an approved subset while leaving other roles unaffected. This aligns with least-privilege access and minimizes ongoing administrative effort.
- C. Incorrect.
Incorrect. Snowflake does not manage Cortex model access by granting USAGE on individual models in the same way as database objects like warehouses or schemas. Also, revoking access from all other roles would not meet the requirement that other teams retain broader model access.
- D. Incorrect.
Incorrect. Masking policies protect sensitive data in query results or expressions, but they do not enforce model-level access restrictions. A masking policy could help reduce data exposure, but it would not stop a role from selecting a non-approved model if that role otherwise has access.