ARA-C01 Question 428
Single answerACCOUNT_USAGE and INFORMATION_SCHEMA viewsA Snowflake architect is building an operations dashboard that must show near-real-time query activity for users in a single database, while also supporting month-end governance reporting across the entire account for warehouse consumption and object usage trends. The team wants to minimize custom ETL and use built-in metadata sources whenever possible. Which approach best meets these requirements?
- A
Use INFORMATION_SCHEMA table functions and views for the near-real-time database-focused dashboard, and use SNOWFLAKE.ACCOUNT_USAGE views for the account-wide historical governance reports.
- B
Use only SNOWFLAKE.ACCOUNT_USAGE views for both use cases because they provide the broadest account-level coverage and the lowest-latency metadata.
- C
Use only each database's INFORMATION_SCHEMA because it contains both current and full historical account-wide usage, including all warehouses and all objects across the account.
- D
Replicate INFORMATION_SCHEMA into a central reporting schema for month-end governance because ACCOUNT_USAGE is intended only for billing data and does not include object or query history.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to combine both metadata sources according to their strengths. INFORMATION_SCHEMA is generally used for lower-latency access and is database-specific, which makes it useful for operational dashboards focused on a given database. SNOWFLAKE.ACCOUNT_USAGE, exposed through the shared SNOWFLAKE database, is designed for account-level observability and governance reporting, including historical trends such as warehouse usage and query activity, but many views are not real time and can lag. In practice, architects commonly use INFORMATION_SCHEMA for immediate operational checks and ACCOUNT_USAGE for centralized reporting, auditing, and trend analysis. This distinction is consistent with Snowflake documentation on metadata sources, where INFORMATION_SCHEMA provides ANSI-style metadata and Snowflake-specific table functions/views at the database level, while ACCOUNT_USAGE provides account-level historical usage views with documented latency considerations.
- A. Correct.
Correct. INFORMATION_SCHEMA is appropriate for lower-latency, operational metadata access and is scoped to a database, making it suitable for near-real-time monitoring within a specific database. For broader historical and governance reporting across the entire account, SNOWFLAKE.ACCOUNT_USAGE is the better fit because it provides account-level usage views such as query, warehouse, and object-related history, though with latency. This aligns with a common design pattern: INFORMATION_SCHEMA for operational visibility and ACCOUNT_USAGE for centralized historical analysis.
- B. Incorrect.
Incorrect. Although ACCOUNT_USAGE provides broad account-level visibility, it is not the lowest-latency source. Many ACCOUNT_USAGE views have a delay before data appears, so it is a poor choice when the requirement is near-real-time monitoring. A candidate might choose this option because ACCOUNT_USAGE is centralized and convenient, but that convenience does not eliminate its metadata latency characteristics.
- C. Incorrect.
Incorrect. INFORMATION_SCHEMA is not a full account-wide historical repository. It is database-oriented and better suited for current or recent metadata access within that scope. It does not replace account-level historical governance views for all warehouses and all objects across the account. This option reflects the misconception that INFORMATION_SCHEMA can serve as a universal metadata warehouse.
- D. Incorrect.
Incorrect. ACCOUNT_USAGE is not limited to billing data. It includes numerous usage and governance-oriented views, such as query history, warehouse metering, logins, grants, and object-related metadata, depending on the specific view. Replicating INFORMATION_SCHEMA just to create month-end reporting ignores the purpose-built account-wide historical metadata already available in ACCOUNT_USAGE.