ADA-C01 Question 371
Single answerAnalyze event tables for system health indicatorsA Snowflake administrator is asked to investigate intermittent service degradation in a production account. Users report occasional spikes in query latency and brief failures in automated tasks, but warehouse load appears normal. The administrator wants to use Snowflake event table data to identify system health indicators and correlate failures over time. Which approach is the MOST appropriate?
- A
Query the active event table for log and metric records, then filter by event timestamps, severity levels, and object attributes such as task name or service component to identify correlated health issues.
- B
Use QUERY_HISTORY exclusively, because event tables do not capture operational signals related to system components or task execution failures.
- C
Increase the warehouse size used by affected workloads, because event tables are intended only for security auditing and do not help diagnose platform health patterns.
- D
Run SHOW TASKS and DESCRIBE TASK for each failed task, because event tables cannot be queried with SQL for time-based analysis.
- E
Export all account usage views to an external monitoring tool first, because Snowflake event tables cannot store telemetry in a structured format that supports filtering.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to query the active event table directly to analyze logs and metrics associated with the reported degradation. Snowflake event tables support observability by storing telemetry data in a structured format that administrators can query with SQL. In a real troubleshooting scenario, filtering by event time, severity, and resource-specific attributes helps correlate task failures, service warnings, and latency-related indicators. QUERY_HISTORY and task metadata can complement the investigation, but they are not substitutes for event table analysis when the goal is to assess broader system health indicators. This aligns with Snowflake best practices for observability, where event tables are used to investigate operational behavior and detect patterns across logs, metrics, and traces.
- A. Correct.
Correct. Snowflake event tables are designed to store observability data such as logs, metrics, and traces in a queryable table format. For system health analysis, an administrator can query the active event table with SQL and filter on timestamp ranges, severity, and resource or object attributes to correlate incidents such as task failures or service degradation. This is the most direct and appropriate approach for analyzing health indicators over time.
- B. Incorrect.
Incorrect. QUERY_HISTORY is useful for query-level analysis, but it is not a complete substitute for event table telemetry. Event tables provide broader observability data, including logs and metrics, that can help identify operational patterns and failures not visible from query history alone. Relying exclusively on QUERY_HISTORY misses important system health signals.
- C. Incorrect.
Incorrect. Increasing warehouse size may help some performance issues, but the scenario explicitly states warehouse load appears normal and asks how to use event table data to identify health indicators. Event tables are not limited to security auditing; they are part of Snowflake observability capabilities and are intended to support operational diagnostics.
- D. Incorrect.
Incorrect. SHOW TASKS and DESCRIBE TASK can provide configuration and status details, but they are not sufficient for time-series correlation of platform events or repeated operational failures. Also, event tables are queryable with SQL, which is one of their key advantages for troubleshooting and trend analysis.
- E. Incorrect.
Incorrect. While exporting telemetry to external monitoring platforms can be useful in some architectures, it is not required before analysis. Snowflake event tables store telemetry in a structured, queryable format inside Snowflake, allowing administrators to filter and analyze records directly with SQL.