ARA-C01 Question 394
Single answerQuery acceleration serviceA retail analytics team runs ad hoc queries against a 25 TB SALES_FACT table. Most queries filter on highly selective predicates such as CUSTOMER_ID, STORE_ID, and short date ranges, and then aggregate a small subset of rows. During peak periods, the team wants faster response times without simply increasing warehouse size because concurrency is already managed separately. The architect is evaluating Snowflake's Query Acceleration Service (QAS). Which action is the MOST appropriate to improve these query patterns with the least architectural change?
- A
Enable Query Acceleration Service on the virtual warehouse used by the analysts, because QAS can accelerate eligible selective scan and aggregation work by offloading portions of the query processing.
- B
Create a materialized view on the entire SALES_FACT table for all commonly queried columns, because materialized views are the required prerequisite for Query Acceleration Service to work.
- C
Convert the warehouse to a multi-cluster warehouse with a higher maximum cluster count, because QAS only works when additional clusters are available for the same warehouse.
- D
Replace the SALES_FACT table with a hybrid table, because QAS is designed primarily for OLTP-style row-based access patterns rather than large analytic scans.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to enable Query Acceleration Service on the warehouse. QAS is designed to accelerate certain eligible query workloads by offloading portions of query processing, particularly when queries scan large tables but return or aggregate a small subset of rows due to highly selective filters. This aligns closely with the scenario: a very large fact table, selective predicates, and a desire to improve latency without major architectural redesign.
Architecturally, QAS is a good fit when the issue is single-query performance for eligible scan/filter/aggregation patterns rather than warehouse concurrency. Increasing warehouse size may help, but the prompt explicitly seeks a lower-change alternative. Multi-cluster warehouses address concurrent query demand, not the acceleration of one eligible query. Materialized views can be useful for stable, repetitive patterns, but they add maintenance cost and are not required for QAS. Hybrid tables are unrelated to this analytic optimization goal.
This reflects Snowflake best practices: use QAS for eligible selective analytical queries on large tables; use multi-cluster warehouses for concurrency; and use materialized views only when the workload justifies precomputation and maintenance overhead. Candidates should also know that not every query benefits from QAS, so validating eligibility and impact with workload observation and query performance analysis is important.
- A. Correct.
Correct. Query Acceleration Service is enabled at the warehouse level and is intended to improve performance for eligible parts of scan-heavy queries, especially queries with highly selective filters and limited aggregation on large tables. In this scenario, the workload matches a common QAS use case: extracting and processing a small subset of data from a very large table without redesigning schemas or simply resizing the warehouse.
- B. Incorrect.
Incorrect. Materialized views can help certain repeated query patterns, but they are not a prerequisite for Query Acceleration Service. This option reflects a common misconception that all performance improvements in Snowflake require precomputed structures. QAS works independently of materialized views and targets eligible query fragments dynamically.
- C. Incorrect.
Incorrect. Multi-cluster warehouses are primarily used to improve concurrency by adding clusters for additional simultaneous workload capacity. They do not make QAS available, nor is QAS dependent on multi-cluster configuration. This option confuses concurrency scaling concepts with query acceleration for individual eligible queries.
- D. Incorrect.
Incorrect. Hybrid tables are intended for specific transactional-style workloads and are not the standard solution for accelerating large analytic fact-table queries. QAS is designed to help with eligible analytic queries on large datasets, not to require a migration to a different table type.