COF-C03 Question 269
Single answerQuery attributionA Snowflake administrator needs to determine which workload is responsible for a recent increase in warehouse spend. Several teams use the same virtual warehouse, and many queries are submitted through shared service accounts, making USER_NAME alone unreliable for chargeback. The administrator wants to attribute query costs to the correct business workload with the least ambiguity going forward. Which approach should be implemented?
- A
Require each application or workload to set a distinct QUERY_TAG and use query history views to group and analyze usage by that tag
- B
Rely on WAREHOUSE_METERING_HISTORY only, because it directly breaks down warehouse credits by individual query
- C
Create separate databases for each team, because query costs are automatically attributed to the database where objects are stored
- D
Use LOGIN_HISTORY to attribute all warehouse consumption, because each login maps cleanly to the queries that consumed credits
Show answer and explanation
Correct answer: A
Explanation
For query attribution in Snowflake, the most practical and reliable approach is to tag workloads using QUERY_TAG and then analyze query metadata in QUERY_HISTORY or ACCOUNT_USAGE views. This is especially important when multiple teams share warehouses or use common service accounts. QUERY_TAG can be set by applications, ETL jobs, BI tools, or SQL sessions to identify the originating workload. In contrast, WAREHOUSE_METERING_HISTORY shows warehouse credit usage at a time-granular level but does not directly allocate credits to individual queries or business workloads. Best practice is to combine operational tagging standards with history views for showback/chargeback reporting and workload analysis.
- A. Correct.
Correct. QUERY_TAG is the recommended mechanism for attributing queries to applications, pipelines, teams, or business processes when users or service accounts are shared. By setting a meaningful tag at the session or statement level, administrators can analyze QUERY_HISTORY and related Account Usage views to group workloads consistently for reporting and chargeback/showback purposes.
- B. Incorrect.
Incorrect. WAREHOUSE_METERING_HISTORY provides warehouse-level credit consumption over time, not a direct per-query credit breakdown. It is useful for understanding warehouse spend patterns, but by itself it does not identify which specific workload or business process caused the spend. Candidates sometimes choose this because it contains billing data, but it lacks workload-level attribution without combining it with query metadata.
- C. Incorrect.
Incorrect. Snowflake charges compute to the virtual warehouse that executes the query, not to the database containing the data objects. Separate databases may help organize data ownership, but they do not provide reliable compute attribution for shared warehouses. A single query can also touch objects across multiple databases, making database-based attribution unsuitable for this scenario.
- D. Incorrect.
Incorrect. LOGIN_HISTORY tracks authentication events, not the business context of each query. A login session may execute many unrelated queries, and shared service accounts make this even less useful for chargeback. This option reflects the misconception that connection history is sufficient to explain compute consumption.