SnowPro Advanced: Security Engineer Question 431
Single answerAccess Cortex Analyst request logs to audit natural language queries and generated SQLA financial services company recently enabled Cortex Analyst for internal business users. The security team must audit what users asked in natural language and review the SQL that Cortex Analyst generated in response. An auditor also requires that the team use a native Snowflake logging source rather than application-side logs, because some requests may originate from multiple client applications. Which approach should the security engineer use to meet this requirement?
- A
Query the Cortex Analyst request logs exposed by Snowflake to review both the natural language prompts and the generated SQL for each request.
- B
Use ACCESS_HISTORY alone, because it stores the full natural language prompt submitted to Cortex Analyst together with the generated SQL text.
- C
Review only QUERY_HISTORY, because every Cortex Analyst interaction is logged there with the original natural language request and no additional source is needed.
- D
Enable object tagging on semantic models, then query TAG_REFERENCES to reconstruct user prompts and the SQL returned by Cortex Analyst.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to audit both parts of a Cortex Analyst interaction: the natural language request and the SQL generated in response, using a Snowflake-native source rather than relying on front-end application logging. The correct solution is to access Cortex Analyst request logs, which are intended for this exact auditing scenario. In contrast, QUERY_HISTORY and ACCESS_HISTORY are useful complementary sources for downstream SQL execution and object access analysis, but they do not replace Analyst request logs when the auditor needs the original natural language prompt. As a best practice, security engineers should use the dedicated Analyst request logging capability for request-level auditability, then correlate it with query and access history if deeper investigation into execution behavior or object access is required.
- A. Correct.
Correct. The requirement is specifically to audit Cortex Analyst natural language requests and the SQL generated from them by using a Snowflake-native logging source. Cortex Analyst request logs are the appropriate source for this use case because they are designed to expose request-level details for Analyst interactions, including the natural language query and generated SQL, which supports centralized auditing across client applications.
- B. Incorrect.
Incorrect. ACCESS_HISTORY is valuable for auditing data access and understanding what objects were touched by executed statements, but it is not the correct source for the original natural language prompt sent to Cortex Analyst. Relying on ACCESS_HISTORY alone would miss the prompt-level context the auditor asked for.
- C. Incorrect.
Incorrect. QUERY_HISTORY is useful for reviewing executed SQL statements, performance, and execution metadata, but it does not serve as the authoritative source for the original natural language request submitted to Cortex Analyst. A candidate might pick this because generated SQL can appear in query-related logs, but the requirement includes auditing the user’s natural language input as well.
- D. Incorrect.
Incorrect. Tags and TAG_REFERENCES help classify and govern Snowflake objects, not capture conversational request logs or reconstruct generated SQL from Cortex Analyst interactions. This option reflects a governance feature being misapplied to an auditing requirement.