SnowPro Specialty: Gen AI Question 232
Single answerData safety and security considerationsA financial services company is building an internal chatbot in Snowflake that uses Cortex AI functions to summarize customer support cases. The source table contains personally identifiable information (PII), and the security team requires that analysts only see rows for their own region and that the model should not receive raw SSNs or full account numbers in prompts. The team wants a solution that minimizes application-side filtering logic and keeps controls enforceable inside Snowflake. Which approach should they implement?
- A
Create a secure view that masks sensitive columns and applies a row access policy for regional filtering, then have the chatbot query that protected object before sending text to Cortex AI functions.
- B
Grant analysts direct SELECT access to the base table and rely on the chatbot application to remove SSNs and account numbers from prompts before calling Cortex AI functions.
- C
Move the data to a separate schema for each region and let the application choose the correct schema, because Cortex AI functions cannot work with policy-protected tables or views.
- D
Use dynamic tables to replicate the support data for each analyst role, because row access policies and masking policies only apply to data sharing and not to AI workloads.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to enforce security controls natively in Snowflake before data is used by the Gen AI workflow. In this scenario, the company has two distinct requirements: row-level restriction by analyst region and protection of sensitive values so they are not exposed to users or passed into model prompts. Snowflake supports this pattern through governance features such as row access policies for row-level security and masking policies or protected views for sensitive columns. Using a secure view over the base table is a practical design because it centralizes the filtering and masking logic, reduces application complexity, and ensures consistent enforcement across SQL queries and AI-enabled workflows. This is preferable to relying on the application layer, which is harder to audit and easier to bypass. Snowflake documentation and best practices for data governance emphasize applying access controls, masking, and least-privilege access directly in the platform, especially when working with sensitive data in analytics and AI use cases.
- A. Correct.
Correct. This approach keeps data protection inside Snowflake by combining row-level and column-level controls. A row access policy can restrict analysts to their region, and masking or tokenization logic in a protected object such as a secure view can prevent raw SSNs or full account numbers from being exposed to users or included in prompts sent to Cortex AI functions. This aligns with Snowflake best practices of enforcing governance close to the data rather than depending on application logic.
- B. Incorrect.
Incorrect. Relying on the application to sanitize prompts is weaker because it shifts enforcement outside Snowflake and increases the risk of accidental exposure through misconfigured code, ad hoc queries, or other downstream uses. Direct access to the base table also allows analysts to see raw sensitive data unless additional controls are applied in Snowflake.
- C. Incorrect.
Incorrect. Creating separate schemas per region is an operational workaround, not the best governance design for this requirement. More importantly, the statement that Cortex AI functions cannot work with policy-protected tables or views is false. Snowflake governance features such as row access policies and masking policies are intended to be used with governed data objects accessed by downstream workloads.
- D. Incorrect.
Incorrect. Dynamic tables are for pipeline transformation and incremental maintenance, not for enforcing analyst-specific security boundaries. Row access policies and masking policies are not limited to data sharing; they are standard Snowflake governance controls that can be used for AI-related workloads as well.