SnowPro Specialty: Gen AI Question 280
Single answerLoggingA data engineering team has deployed a Python stored procedure in Snowflake that invokes an LLM-powered workflow for customer-support summarization. During testing, the team needs to troubleshoot intermittent failures and understand execution flow, but they must avoid exposing raw customer message content in monitoring data. Which approach BEST meets these requirements using Snowflake logging capabilities?
- A
Add Python logging statements at key steps in the stored procedure, configure an event table to collect log entries, and log metadata such as request IDs, model names, and status codes instead of raw prompts or customer text.
- B
Use QUERY_HISTORY output as the primary logging solution because it automatically captures all prompt and response payloads generated by the Python stored procedure for debugging.
- C
Enable ACCESS_HISTORY and rely on it to store detailed application log messages emitted from the stored procedure, including custom exception traces and step-level progress messages.
- D
Write all prompts and model responses into a permanent relational table so the team can inspect failures later; this is the recommended Snowflake logging pattern for AI observability.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use application-level logging from the Python stored procedure and capture those logs in a Snowflake event table, while intentionally logging only non-sensitive metadata. Snowflake supports logging, tracing, and metrics collection for supported languages and stores this observability data in event tables. For GenAI workloads, a key best practice is to avoid placing sensitive prompt or response content into logs unless there is a clear business need and appropriate controls. Instead, log correlation IDs, execution milestones, model selection, latency, token-related metadata if available, and exception summaries. QUERY_HISTORY and ACCESS_HISTORY provide useful administrative and governance information, but they are not substitutes for structured application logging. This aligns with Snowflake observability guidance around event tables and secure logging practices.
- A. Correct.
Correct. In Snowflake, supported handlers such as Python can emit log messages through standard logging APIs, and those messages can be captured in an event table for monitoring and troubleshooting. This is the right pattern for operational observability. The scenario also requires minimizing exposure of sensitive customer content, so logging metadata like correlation IDs, execution stage, model identifier, timing, and error codes is preferable to logging raw prompts or responses.
- B. Incorrect.
Incorrect. QUERY_HISTORY is useful for tracking executed SQL statements and related query metadata, but it is not a purpose-built application logging mechanism for capturing step-by-step custom log messages from handler code. It also should not be assumed to safely or comprehensively store all prompt/response payloads for debugging.
- C. Incorrect.
Incorrect. ACCESS_HISTORY is designed for governance and lineage-style visibility into data access patterns, not for capturing custom application logs from Python stored procedures. It does not replace event-table-based logging for handler-emitted messages.
- D. Incorrect.
Incorrect. Persisting all prompts and responses in a permanent table may create unnecessary privacy and compliance risk, especially when the requirement explicitly says to avoid exposing raw customer content in monitoring data. While teams may store carefully governed audit data for approved use cases, this is not the best logging approach for troubleshooting under the stated constraints.