ADA-C01 Question 372
Single answerAnalyze event tables for system health indicatorsA Snowflake administrator is troubleshooting intermittent query failures and performance degradation reported by several teams over the last 24 hours. The account has an event table configured and the administrator wants to use it to identify system health indicators, such as error spikes and resource-related issues, before escalating to engineering. Which approach would BEST use the event table for this analysis?
- A
Query the event table for recent log and trace records, filter on higher-severity entries and relevant categories, then aggregate by time window to identify spikes in errors or warnings that align with the reported incidents.
- B
Use the event table to retrieve complete historical query execution plans for all failed statements, because event tables are the primary source for optimizer diagnostics and plan regression analysis.
- C
Truncate the event table before analysis so that only new incidents are captured, then compare the next set of events manually to determine whether the warehouse is unhealthy.
- D
Query ACCOUNT_USAGE.QUERY_HISTORY only, because event tables are intended for application debugging and cannot be used to analyze system health indicators.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to query the event table directly for recent telemetry, filter to meaningful severity levels or categories, and aggregate by time interval to identify spikes and correlations. This reflects how administrators use telemetry for operational awareness: detecting clusters of warnings/errors, relating them to incident timestamps, and narrowing the scope before using other tools such as QUERY_HISTORY or Query Profile for statement-level details. Snowflake event tables are built to store observability data, including logs, traces, and metrics, and are appropriate for monitoring and troubleshooting system and application behavior. By contrast, query execution plans and optimizer-specific diagnostics are obtained from query history and profiling tools, not from the event table alone. Best practice is to preserve telemetry history for trend analysis rather than truncating it, and to combine event-table findings with other account monitoring views when needed.
- A. Correct.
Correct. Event tables are designed to store telemetry data such as logs, traces, and metrics generated by Snowflake components and applications using the telemetry framework. For system health analysis, a practical approach is to query recent records, focus on severity levels and categories associated with failures or degraded behavior, and aggregate over time to detect abnormal spikes that correlate with the incident window. This helps an administrator identify whether the issue is isolated or systemic before moving to deeper investigation.
- B. Incorrect.
Incorrect. Event tables are not the primary source for complete query execution plans or optimizer regression analysis. Query plans and statement execution details are typically investigated with query history, query profile, and related monitoring views/functions. Someone might choose this option because both telemetry and query troubleshooting involve operational data, but event tables are not a substitute for full optimizer diagnostics.
- C. Incorrect.
Incorrect. Truncating the event table would destroy useful historical context needed to compare normal and abnormal behavior. A better practice is to filter by timestamp ranges and analyze trends over defined windows. This distractor reflects a misconception that event-table analysis requires a clean slate, when in reality retaining historical telemetry is important for baselining and correlation.
- D. Incorrect.
Incorrect. ACCOUNT_USAGE.QUERY_HISTORY is useful for statement-level analysis, but it does not replace event table telemetry. Event tables can be used to analyze health-related indicators through logs, traces, and metrics. This option is plausible because administrators often start with QUERY_HISTORY, but saying event tables cannot be used for system health analysis is incorrect.