SnowPro Advanced: Security Engineer Question 411
Single answerUse filtered responses (for example, NULL from TRY_COMPLETE())A security engineering team has built an internal Snowflake app that lets analysts summarize support tickets by calling an LLM through a SQL function. Some tickets can contain sensitive data, so the team configured content filtering and wants the application to fail safely when generated output is blocked. During testing, they observe that some model calls return NULL instead of text. The team must ensure analysts do not see unfiltered output and that downstream SQL logic handles blocked generations correctly. Which approach best meets this requirement?
- A
Use TRY_COMPLETE() and explicitly check for NULL in SQL, returning a controlled fallback message or taking alternate logic when the filtered response is blocked.
- B
Use COMPLETE() instead of TRY_COMPLETE() because COMPLETE() automatically replaces blocked content with a masked string that is safer to display.
- C
Wrap TRY_COMPLETE() with COALESCE(..., original_prompt) so users still receive the source text when the model output is filtered.
- D
Disable filtering for trusted internal analysts and rely on role-based access control alone, because filtering is only needed for external users.
Show answer and explanation
Correct answer: A
Explanation
The best practice is to treat filtered model responses as an expected condition and code for them explicitly. In Snowflake Cortex SQL functions, TRY_COMPLETE() is designed for safer error handling patterns and can return NULL instead of causing the application to proceed with unsafe assumptions. In a security-focused design, downstream SQL should check for NULL and either return a controlled message, log the event, or route the request for manual review. This aligns with fail-safe application behavior and reduces the risk of exposing sensitive content through unintended fallbacks. By contrast, assuming automatic masking, echoing back the original prompt, or relying only on RBAC are all flawed approaches. Refer to Snowflake documentation for Cortex AISQL/LLM function behavior, including TRY_* function semantics and content filtering considerations.
- A. Correct.
Correct. TRY_COMPLETE() can return NULL when a response is filtered or otherwise cannot be produced safely, so the secure implementation pattern is to check for NULL and handle it explicitly in downstream SQL or application logic. This prevents accidental display of unsafe or incomplete output and supports fail-safe behavior.
- B. Incorrect.
Incorrect. COMPLETE() does not provide a guarantee that blocked content will be replaced with a safe masked string for display. This option reflects a common misconception that the non-TRY variant automatically sanitizes or substitutes output. Security-sensitive workflows should not assume a placeholder value unless the application explicitly implements one.
- C. Incorrect.
Incorrect. Falling back to the original prompt can create a security issue, because prompts or source text may contain the very sensitive information the team is trying to avoid exposing. COALESCE is useful for handling NULL, but substituting the raw prompt is not a safe fallback in this scenario.
- D. Incorrect.
Incorrect. Role-based access control is important, but it does not replace response filtering. Even trusted internal users may trigger blocked generations, and the application still needs to handle filtered responses safely. Security controls should be layered rather than relying on RBAC alone.