DAA-C01 Question 110
Single answerAnomaly DetectionA retail analytics team stores one row per day in a Snowflake table with columns DAY_DT, STORE_ID, and NET_SALES. They need to identify unusual daily sales behavior for each store over the last 18 months and refresh the results every morning before business users open their dashboards. The team wants a solution that minimizes custom model training and keeps the implementation inside Snowflake. Which approach best meets these requirements?
- A
Use Snowflake Cortex AISQL ANOMALY_DETECTION on the historical NET_SALES time series partitioned by STORE_ID, then schedule the detection query with a TASK to refresh results daily.
- B
Train a custom supervised classification model in Snowpark ML using manually labeled anomalous and non-anomalous rows, because anomaly detection in Snowflake requires labeled training data.
- C
Create a materialized view that calculates AVG(NET_SALES) by STORE_ID and flag a day as anomalous whenever NET_SALES differs from the average by more than 5%.
- D
Use SEARCH OPTIMIZATION on the NET_SALES column and query for outlier values each morning, because search optimization is designed to detect anomalies in time-series data.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake Cortex AISQL anomaly detection functionality because the scenario explicitly calls for a Snowflake-native solution with minimal custom model development. For store-level daily sales, anomaly detection should be applied to the time series separately for each STORE_ID, since each store may have its own normal behavior and seasonal patterns. Operationally, Snowflake TASKs are the standard way to schedule recurring SQL processing, making them a strong fit for a daily refresh pipeline. The other options are plausible distractors: supervised ML is more complex and requires labeled data; static average-based thresholds are simplistic and do not reflect best practices for time-series anomaly detection; and SEARCH OPTIMIZATION is a performance feature, not an analytical detection capability. This aligns with Snowflake best practices of using built-in platform features when they meet the use case and automating recurring analytical workloads with TASKs.
- A. Correct.
Correct. Snowflake Cortex AISQL provides built-in anomaly detection capabilities that are appropriate for time-series anomaly detection without requiring the team to build and train a custom model from scratch. Partitioning by STORE_ID matches the business need to detect anomalies independently for each store's sales pattern. Scheduling the SQL with a TASK is also a practical Snowflake-native way to refresh the results every morning.
- B. Incorrect.
Incorrect. This reflects a common misconception that anomaly detection must be handled as a supervised ML classification problem with labeled examples. In this scenario, the requirement is to minimize custom model training and stay inside Snowflake. Built-in anomaly detection is better aligned than creating and maintaining a supervised model, especially when labeled anomaly data may be sparse or unavailable.
- C. Incorrect.
Incorrect. A simple average-threshold rule is not robust for realistic store sales data because it ignores seasonality, trend, weekends versus weekdays, holidays, and changing baselines over 18 months. It may produce many false positives or miss meaningful anomalies. Materialized views can store precomputed query results, but they do not provide statistical anomaly detection logic by themselves.
- D. Incorrect.
Incorrect. Search optimization improves selective query performance for supported predicates, but it is not an anomaly detection feature and does not analyze temporal patterns, trends, or seasonality. It may help find rows faster after they are identified, but it does not solve the anomaly detection problem.