ADA-C01 Question 277
Single answerUse query history filters including client-generated queries and queries executed by user tasksA Snowflake administrator is investigating a spike in warehouse usage that occurred overnight. They suspect the activity came from a scheduled task, but the initial review of query history is cluttered with statements automatically issued by BI tools and JDBC sessions. The administrator needs to isolate only the SQL statements executed by user-defined tasks and exclude client-generated queries from the investigation. Which approach should the administrator use?
- A
Query QUERY_HISTORY and filter for queries where IS_CLIENT_GENERATED_STATEMENT = FALSE and QUERY_TYPE = 'TASK'
- B
Query QUERY_HISTORY and filter for queries where USER_NAME = 'TASK' and CLIENT_APPLICATION_ID IS NULL
- C
Query QUERY_HISTORY and filter for queries where IS_CLIENT_GENERATED_STATEMENT = FALSE and TASK_NAME IS NOT NULL
- D
Query LOGIN_HISTORY and filter for sessions started by the task owner, then join to QUERY_HISTORY on SESSION_ID
Show answer and explanation
Correct answer: C
Explanation
The best solution is to use query history metadata specifically designed for this type of operational analysis. In Snowflake query history views and table functions, IS_CLIENT_GENERATED_STATEMENT helps identify statements automatically generated by clients, drivers, or applications, which is useful when administrators want to focus on user-submitted or system-orchestrated SQL. To isolate work performed by tasks, task-related columns such as TASK_NAME should be used, because a task can execute standard SQL statement types rather than a special QUERY_TYPE called 'TASK'. This makes Option 3 the only accurate and practical choice. As a best practice, administrators investigating warehouse spikes should filter query history by time window, warehouse, and task metadata, and then exclude client-generated statements to reduce noise. Refer to Snowflake documentation for QUERY_HISTORY output columns and task monitoring guidance in Account Usage and Information Schema.
- A. Incorrect.
Incorrect. IS_CLIENT_GENERATED_STATEMENT = FALSE is the right idea for excluding statements automatically generated by clients and drivers, but QUERY_TYPE = 'TASK' is not the correct way to identify SQL executed by a task. Task-executed statements are normal SQL statements such as SELECT, INSERT, MERGE, or COPY, and are identified in query history by task-related metadata rather than a QUERY_TYPE value of 'TASK'.
- B. Incorrect.
Incorrect. Tasks do not appear as a literal USER_NAME of 'TASK'. Queries executed by a task run under the task owner's context, so filtering on USER_NAME = 'TASK' would miss the actual statements. CLIENT_APPLICATION_ID is also not a reliable or intended filter for separating task queries from other activity.
- C. Correct.
Correct. QUERY_HISTORY exposes whether a statement was client-generated through IS_CLIENT_GENERATED_STATEMENT, allowing the administrator to remove noise from tools and drivers. Queries executed by a user task can be identified using task metadata such as TASK_NAME. Filtering on IS_CLIENT_GENERATED_STATEMENT = FALSE and TASK_NAME IS NOT NULL is the most direct way to isolate user task activity while excluding client-generated queries.
- D. Incorrect.
Incorrect. LOGIN_HISTORY tracks authentication events, not the execution source of individual SQL statements. Joining login sessions to query history based on the task owner would still not distinguish task-executed queries from manually submitted queries by that same user. This approach is indirect and unreliable for the stated requirement.