SnowPro Advanced: Security Engineer Question 282
Single answerMonitor anomalous credit consumption as a critical security signal:A Snowflake security engineer is investigating a possible compromise after the finance team reports a sudden overnight spike in credits consumed by a shared analytics warehouse. The organization wants to treat unusual credit usage as a potential security signal, not just a cost issue. The engineer needs an approach that helps detect suspicious activity quickly and identify which principals and workloads caused the spike. Which action should the engineer take?
- A
Query ACCOUNT_USAGE views such as WAREHOUSE_METERING_HISTORY and QUERY_HISTORY together, correlate the time window of the spike with the users, roles, clients, and query patterns involved, and alert on deviations from an established baseline
- B
Rely only on RESOURCE MONITORS to identify compromised users, because resource monitors provide user-level attribution for anomalous warehouse consumption
- C
Review LOGIN_HISTORY only, because if authentication succeeded then the associated credit spike can be fully explained without analyzing warehouse or query activity
- D
Increase AUTO_SUSPEND on the warehouse so that future anomalous activity is automatically classified as malicious and blocked without further investigation
Show answer and explanation
Correct answer: A
Explanation
The best answer is to correlate Snowflake usage telemetry to detect and investigate anomalies. For security purposes, unusual credit consumption can indicate compromised credentials, abused service accounts, runaway ETL jobs, exfiltration attempts using large scans, or unauthorized use of large warehouses. In practice, a security engineer should establish a baseline for expected warehouse consumption and query behavior, then use ACCOUNT_USAGE views such as WAREHOUSE_METERING_HISTORY, QUERY_HISTORY, and often LOGIN_HISTORY to investigate deviations.
WAREHOUSE_METERING_HISTORY helps answer when and where credits were consumed. QUERY_HISTORY helps answer what workload caused it, including the user, role, warehouse, query text characteristics, execution timing, and client/application context. LOGIN_HISTORY is complementary for authentication context, but not sufficient on its own. RESOURCE MONITORS are valuable for threshold-based notifications and limiting spend, but they do not provide the detailed attribution needed for root-cause analysis.
This aligns with Snowflake best practices of combining operational monitoring with account usage telemetry for security investigations. Relevant Snowflake documentation includes ACCOUNT_USAGE views such as QUERY_HISTORY, WAREHOUSE_METERING_HISTORY, and LOGIN_HISTORY, as well as documentation on RESOURCE MONITORS for spend governance rather than forensic attribution.
- A. Correct.
Correct. Monitoring anomalous credit consumption as a security signal requires both cost telemetry and activity attribution. WAREHOUSE_METERING_HISTORY helps identify when compute spend increased, while QUERY_HISTORY helps determine what statements ran, who ran them, what warehouse was used, and what client/application patterns appeared during the spike. Correlating these with roles, users, timing, and normal usage baselines is the most effective way to distinguish legitimate batch processing from suspicious behavior such as credential misuse, abusive BI extracts, or unexpected large-scale data scans. This reflects a practical security engineering workflow in Snowflake.
- B. Incorrect.
Incorrect. RESOURCE MONITORS are useful for controlling or notifying on warehouse credit usage thresholds, but they are not designed to provide detailed user-level forensic attribution of who caused the spend. They can help limit blast radius or trigger alerts, but they do not replace analysis of ACCOUNT_USAGE telemetry such as query and warehouse metering history. A common misconception is treating resource monitors as an investigation tool rather than a governance and spend-control mechanism.
- C. Incorrect.
Incorrect. LOGIN_HISTORY can help identify unusual sign-ins, source IPs, or authentication patterns, and it is valuable in a broader investigation. However, login events alone do not explain what consumed the credits. A user may authenticate successfully and perform no meaningful work, or a service account may run highly expensive queries after a normal login. To investigate anomalous consumption, warehouse and query activity must be analyzed directly.
- D. Incorrect.
Incorrect. Increasing AUTO_SUSPEND may reduce idle warehouse cost, but it does not classify activity as malicious and does not stop expensive queries that are actively running. This option confuses cost optimization with security detection and response. AUTO_SUSPEND is a warehouse behavior setting, not an anomaly-detection or incident-response control.