SnowPro Advanced: Security Engineer Question 407
Single answerImplement content moderation and safety using Cortex Large Language Model (LLM) functions:A company is building a Snowflake-native support assistant that uses Cortex LLM functions to draft responses from support case text stored in a table. The security team requires that the solution reduce the risk of generating responses from prompts containing unsafe or disallowed content, while keeping all enforcement and auditing inside Snowflake SQL. Which approach BEST meets this requirement?
- A
Call a Cortex completion function directly on all user prompts, and rely on the model provider's built-in safeguards as the only control.
- B
Create a SQL workflow that first evaluates each prompt with a Cortex content moderation/safety function, stores the moderation result for auditability, and only sends prompts that pass policy to the generation function.
- C
Mask the prompt column with a dynamic data masking policy before calling the Cortex generation function, because masking policies are designed to block unsafe instructions from reaching LLMs.
- D
Use row access policies on the support case table so that unsafe prompts are automatically rejected before the Cortex generation function runs.
Show answer and explanation
Correct answer: B
Explanation
For Cortex-based applications, the strongest pattern for content moderation and safety is to explicitly evaluate input with a moderation or safety-focused Cortex LLM function before sending it to a text generation function. In a secure implementation, developers persist moderation outputs or decisions in Snowflake tables so the organization can audit what was screened, what policy was applied, and which prompts were blocked or allowed. This approach supports defense in depth: moderation is implemented in the customer's SQL workflow rather than delegated entirely to model-provider safeguards.
The key misconception behind the incorrect answers is confusing governance controls with content safety controls. Dynamic data masking and row access policies are important Snowflake security features, but they solve different problems: protecting sensitive values and restricting row visibility. They do not classify prompt safety or enforce LLM-specific moderation policy. Best practice is to combine traditional Snowflake security controls with Cortex moderation/safety functions when building LLM applications that must manage unsafe or disallowed content.
- A. Incorrect.
Incorrect. Relying only on provider-side safeguards does not satisfy the stated requirement to keep enforcement and auditing inside Snowflake SQL. Built-in model safeguards may help, but they are not a substitute for an explicit moderation step that can be logged, policy-driven, and consistently enforced by the customer's own workflow.
- B. Correct.
Correct. A two-step SQL pattern is the best fit: first run content moderation/safety analysis using Cortex LLM functions, persist the result for auditing, then conditionally invoke text generation only for prompts that comply with policy. This aligns with a security engineering approach that emphasizes in-platform enforcement, traceability, and controlled handling of unsafe input.
- C. Incorrect.
Incorrect. Dynamic data masking is intended to protect sensitive data exposure based on role or context, not to classify or block harmful prompt content. Although masking is a powerful control for confidentiality, it is not a content moderation mechanism for LLM safety screening.
- D. Incorrect.
Incorrect. Row access policies control which rows a user can see based on context, but they do not evaluate the semantic safety of prompt text for LLM usage. A row access policy could restrict access to records, but it is not the right control to detect harassment, self-harm, sexual content, violence, or other unsafe prompt categories.