SnowPro Advanced: Security Engineer Question 430
Single answerAccess Cortex Analyst request logs to audit natural language queries and generated SQLA security engineer must investigate whether business users are submitting sensitive natural language prompts to Cortex Analyst and verify the SQL that Cortex Analyst generated in response. The company wants an auditable, SQL-accessible history that can be filtered by time, user, and request details without relying on application-side logging. Which approach best meets this requirement?
- A
Query the Cortex Analyst request log view in the SNOWFLAKE.LOCAL package and join it with ACCOUNT_USAGE query history to correlate the natural language request with generated SQL.
- B
Review only LOGIN_HISTORY in ACCOUNT_USAGE because Cortex Analyst prompts are captured as part of session authentication metadata.
- C
Use ACCESS_HISTORY alone because it stores the original natural language prompt text and the generated SQL for all Cortex Analyst requests.
- D
Query INFORMATION_SCHEMA.QUERY_HISTORY because every Cortex Analyst natural language prompt is stored there as the submitted SQL text.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to audit both the natural language request sent to Cortex Analyst and the SQL generated from that request using a Snowflake-native, queryable logging source. The best solution is to use the Cortex Analyst request log view and, when needed, correlate it with standard account usage query telemetry for broader audit context. This is preferable to application logging because it creates a centralized, consistent audit trail under Snowflake governance. By contrast, LOGIN_HISTORY is limited to authentication events, ACCESS_HISTORY focuses on downstream object access rather than preserving the original natural language prompt, and QUERY_HISTORY is centered on executed SQL rather than the Analyst request itself. In practice, security teams should use the dedicated Cortex Analyst request logging capability for prompt-and-generated-SQL auditing, then combine it with ACCOUNT_USAGE views for user, time-window, and execution investigation patterns.
- A. Correct.
Correct. For auditing Cortex Analyst activity, Snowflake provides request log access that is intended to expose the natural language request and generated SQL in a SQL-queryable form. Using the Cortex Analyst request log view is the right primary source for these records, and correlating with ACCOUNT_USAGE query history is a practical way to enrich the audit trail with execution context such as user, timing, and related query metadata. This approach aligns with the requirement for server-side, auditable logging rather than relying on the client application.
- B. Incorrect.
Incorrect. LOGIN_HISTORY tracks authentication events such as successful and failed logins, client information, and related session access details. It does not capture Cortex Analyst prompt content or generated SQL. This option reflects a common misconception that all user activity is embedded in authentication telemetry.
- C. Incorrect.
Incorrect. ACCESS_HISTORY is useful for understanding object-level data access lineage and which objects were touched by queries, but it is not the authoritative source for the original natural language prompt submitted to Cortex Analyst. Relying on ACCESS_HISTORY alone would miss the specific analyst request text needed for this audit use case.
- D. Incorrect.
Incorrect. INFORMATION_SCHEMA.QUERY_HISTORY exposes SQL query history, but a natural language prompt submitted to Cortex Analyst is not itself stored there as if it were user-authored SQL text. At best, query history may show executed SQL after generation, but it does not provide the dedicated request-log record needed to audit both the original natural language request and generated SQL together.