SnowPro Advanced: Security Engineer Question 409
Single answerConfigure COMPLETE() and TRY_COMPLETE() functions to filter contentA security engineer is building an internal support assistant in Snowflake that uses Cortex COMPLETE to summarize incident tickets. The source tickets can contain sensitive values such as credit card numbers and secrets. The team wants the application to do the following: block unsafe prompts and responses when possible, avoid exposing raw model errors to analysts, and return a safe fallback value if generation cannot be completed because of content filtering or other runtime issues. Which approach best meets these requirements?
- A
Use COMPLETE() with guardrails enabled, and wrap the call in application logic outside Snowflake to catch any failures.
- B
Use TRY_COMPLETE() with guardrails enabled, and use COALESCE() to substitute a fallback string when the function returns NULL.
- C
Use COMPLETE() without guardrails, because TRY_COMPLETE() suppresses all model output and cannot return filtered text.
- D
Use TRY_COMPLETE() without guardrails, because content filtering is handled automatically by Snowflake regardless of function parameters.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use TRY_COMPLETE() with guardrails enabled and then handle NULL with a fallback such as COALESCE(). In Snowflake Cortex, COMPLETE() returns a model-generated completion but raises an error when the call fails, while TRY_COMPLETE() is the error-tolerant variant that returns NULL instead of failing the SQL statement. For security-focused implementations, enabling guardrails helps filter unsafe or disallowed content in prompts and/or responses, and TRY_COMPLETE() prevents raw exceptions from surfacing to end users. A common secure pattern is: COALESCE(TRY_COMPLETE(... with guardrails ...), 'Request could not be processed safely'). This aligns with Snowflake best practices for resilient SQL pipelines and controlled handling of AI-generated content.
- A. Incorrect.
This is only partially aligned. COMPLETE() can be configured with guardrails to help filter unsafe content, but COMPLETE() raises an error when the completion fails. Catching failures only in external application logic does not best satisfy the requirement to handle failures and provide a safe fallback directly in SQL. The scenario specifically calls for avoiding raw model errors and returning a fallback value when content filtering or runtime issues prevent completion.
- B. Correct.
Correct. TRY_COMPLETE() is designed to return NULL instead of raising an error when the completion cannot be produced successfully. When guardrails are enabled, the function can apply content filtering to prompts and responses. Combining TRY_COMPLETE() with COALESCE() is a practical pattern for security-sensitive workloads because it allows the SQL layer to return a sanitized fallback string rather than exposing an exception or raw failure details to users.
- C. Incorrect.
This is incorrect. COMPLETE() without guardrails does not meet the requirement to block unsafe prompts and responses when possible. In addition, the statement about TRY_COMPLETE() is a misconception: TRY_COMPLETE() does not suppress all normal model output. It returns the completion result on success and NULL on failure, which is exactly why it is useful for safe fallback handling.
- D. Incorrect.
This is incorrect because guardrails are not implicitly enabled for all calls regardless of parameters. If the goal is to filter unsafe content, the engineer should explicitly configure the function call to use guardrails. TRY_COMPLETE() helps with graceful failure handling, but without guardrails it does not address the content-filtering requirement.