COF-C03 Question 266
Single answerSNOWFLAKE.ACCOUNT_USAGE views (Snowflake database views)A Snowflake administrator needs to build a monthly cost and usage dashboard for leadership. The dashboard must show warehouse credit consumption trends for the entire account using Snowflake-provided metadata, and it does not need real-time data. The administrator wants a solution that avoids querying each individual database or schema. Which approach should the administrator use?
- A
Query the SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY view to retrieve account-level warehouse credit usage history
- B
Query INFORMATION_SCHEMA.TABLE_STORAGE_METRICS in each user database because ACCOUNT_USAGE does not contain warehouse consumption details
- C
Query SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY and sum execution time to estimate warehouse credits consumed by each warehouse
- D
Query SHOW WAREHOUSES output and persist the results daily, because Snowflake does not provide historical warehouse metering views
Show answer and explanation
Correct answer: A
Explanation
For account-wide historical reporting, the SNOWFLAKE database's ACCOUNT_USAGE schema is the standard Snowflake-provided source. In this scenario, the administrator needs monthly warehouse credit consumption trends and does not require real-time data, which makes SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY the best fit. ACCOUNT_USAGE views are intended for centralized governance, monitoring, and usage reporting across the account, whereas INFORMATION_SCHEMA is database-specific and SHOW commands are oriented toward current object metadata rather than historical metering. Snowflake documentation also notes that ACCOUNT_USAGE views can have latency, so they are appropriate for reporting and dashboards that do not require immediate freshness.
- A. Correct.
Correct. SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY is the appropriate Snowflake-provided account-level view for historical warehouse credit consumption. ACCOUNT_USAGE views are designed for centralized account metadata reporting and are commonly used for governance, usage, and billing analysis. This matches the requirement to build a monthly dashboard without needing real-time data and without querying individual databases.
- B. Incorrect.
Incorrect. INFORMATION_SCHEMA views are scoped to a database and are not the right source for centralized warehouse credit consumption reporting. TABLE_STORAGE_METRICS relates to storage, not warehouse metering. This option reflects a common misconception that INFORMATION_SCHEMA is the primary source for all operational reporting, when ACCOUNT_USAGE is typically the better fit for account-wide historical usage analysis.
- C. Incorrect.
Incorrect. QUERY_HISTORY contains query-level metadata and can support workload analysis, but summing execution time does not directly produce accurate warehouse credit consumption. Credit usage is metered separately and should be sourced from warehouse metering views rather than inferred from query duration. Different warehouse sizes and states make execution time an unreliable proxy for billed credits.
- D. Incorrect.
Incorrect. SHOW WAREHOUSES returns current warehouse metadata, not historical credit metering. Persisting SHOW output manually would be unnecessary for this requirement because Snowflake already provides historical warehouse usage through ACCOUNT_USAGE views. This distractor targets the misconception that SHOW commands are the only way to obtain administrative metadata.