ARA-C01 Question 429
Single answerACCOUNT_USAGE and INFORMATION_SCHEMA viewsA global enterprise wants to build an internal near-real-time governance dashboard that shows which tables were queried in the last 30 minutes and who queried them. The dashboard must work across the entire Snowflake account and should also support daily historical reporting for the last 6 months. During testing, the architect notices that queries against SNOWFLAKE.ACCOUNT_USAGE sometimes do not show the most recent activity. Which approach best meets both the near-real-time and historical reporting requirements?
- A
Use only SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY because it contains account-wide history and is optimized for both immediate operational monitoring and long-term reporting.
- B
Use INFORMATION_SCHEMA.QUERY_HISTORY for the last 30 minutes of activity, and use SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY for historical reporting over months.
- C
Use only INFORMATION_SCHEMA.QUERY_HISTORY because Information Schema views are the authoritative source for all historical metadata and have no practical retention limitations.
- D
Query TABLE_STORAGE_METRICS in SNOWFLAKE.ACCOUNT_USAGE to identify recently queried tables, and join it to INFORMATION_SCHEMA.USERS for user attribution.
Show answer and explanation
Correct answer: B
Explanation
For this scenario, the architect needs two different characteristics: low-latency visibility into recent activity and longer-term account-wide history. In Snowflake, INFORMATION_SCHEMA table functions such as QUERY_HISTORY are commonly used for recent query inspection because they expose current metadata with less delay. In contrast, SNOWFLAKE.ACCOUNT_USAGE provides account-level usage and metadata views intended for historical analysis and governance reporting, but these views can have latency before the latest events appear. Therefore, a common best-practice pattern is to use INFORMATION_SCHEMA for near-real-time operational dashboards and ACCOUNT_USAGE for durable historical reporting. This aligns with Snowflake documentation that distinguishes Information Schema metadata access from Account Usage reporting views, including the latency characteristics of ACCOUNT_USAGE and the historical governance/reporting value it provides.
- A. Incorrect.
Incorrect. SNOWFLAKE.ACCOUNT_USAGE provides account-level historical metadata and is commonly used for reporting, but many ACCOUNT_USAGE views, including query history-related views, can have latency before the newest records appear. That makes it a poor sole source for near-real-time operational dashboards. The misconception is assuming that because ACCOUNT_USAGE is account-wide, it is also the best source for immediate monitoring.
- B. Correct.
Correct. INFORMATION_SCHEMA table functions such as QUERY_HISTORY are designed for recent query activity with low latency, which makes them appropriate for near-real-time monitoring. SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY is better suited for longer-term, account-wide historical analysis and reporting, even though it may lag behind recent activity. Combining the two sources is a practical architecture when both timeliness and long-term retention are required.
- C. Incorrect.
Incorrect. INFORMATION_SCHEMA query history functions are useful for recent activity, but they are not intended to serve as the primary source for long-term historical reporting over many months. They also have scope and retention limitations compared with ACCOUNT_USAGE. The misconception here is treating Information Schema as a full historical repository rather than a more immediate metadata access layer.
- D. Incorrect.
Incorrect. TABLE_STORAGE_METRICS reports storage-related metadata, such as table storage usage, and does not identify which tables were queried recently or which users ran those queries. Joining it to user metadata would not produce accurate query-access lineage. This distractor reflects a common confusion between operational/query history metadata and storage/account object metadata.