ADA-C01 Question 360
Single answerSet up a dashboard to monitor Snowflake costsA Snowflake administrator has been asked to create a near-real-time dashboard for finance and engineering leaders to monitor Snowflake spend by warehouse and identify which teams are driving compute costs. The dashboard must use native Snowflake data sources, support SQL-based reporting, and minimize manual data preparation. Which approach should the administrator use?
- A
Build the dashboard from the ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY view, joining to TAG references or warehouse naming conventions as needed to attribute costs by team.
- B
Build the dashboard from INFORMATION_SCHEMA.QUERY_HISTORY because query execution time directly represents the billed compute cost for each warehouse.
- C
Build the dashboard from ACCOUNT_USAGE.STORAGE_USAGE and allocate warehouse costs proportionally based on each database's storage footprint.
- D
Build the dashboard from ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY because it provides warehouse-level hourly cost details needed for near-real-time team dashboards.
Show answer and explanation
Correct answer: A
Explanation
To monitor Snowflake costs in an operational dashboard, the administrator should start with the warehouse metering views in SNOWFLAKE.ACCOUNT_USAGE, especially WAREHOUSE_METERING_HISTORY for compute credit usage by warehouse over time. This provides the right granularity for showing which warehouses are consuming credits and allows downstream attribution to teams via naming standards, tags, or a reference table. Query history can complement the dashboard for workload analysis, but it is not the billing source of truth because compute charges are tied to warehouse metering, including idle time before suspension. STORAGE_USAGE is for storage billing only, and ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY is more appropriate for broader organization-level financial summaries than near-real-time warehouse dashboards. Relevant Snowflake documentation includes the ACCOUNT_USAGE views for warehouse metering and organization/account usage monitoring.
- A. Correct.
Correct. ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY is the primary native source for monitoring compute consumption at the warehouse level. It exposes credit usage over time and is well suited for SQL-based dashboards that show spend trends by warehouse. To attribute costs to teams, administrators commonly use warehouse naming standards, tags, or a mapping table. This aligns with Snowflake best practices for cost visibility because warehouse metering is the authoritative source for compute usage.
- B. Incorrect.
Incorrect. INFORMATION_SCHEMA.QUERY_HISTORY is useful for analyzing query activity, performance, and which users or roles are submitting workloads, but query duration is not the same as billed cost. Snowflake bills compute based on warehouse runtime and credit consumption, not simply by summing query durations. Queries may overlap, warehouses may remain running while idle, and auto-suspend settings affect cost independently of query execution time.
- C. Incorrect.
Incorrect. ACCOUNT_USAGE.STORAGE_USAGE is intended for storage consumption monitoring, not compute cost tracking. A common misconception is that storage footprint can be used to infer overall platform cost allocation, but warehouse charges come from compute credits consumed, which are independent of how much data a database stores.
- D. Incorrect.
Incorrect. ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY is useful for aggregated currency-based cost reporting across accounts in an organization, but it is daily and not designed to provide warehouse-level hourly detail for a near-real-time dashboard inside a single account. It is better suited for higher-level financial reporting than operational warehouse spend monitoring.