SnowPro Advanced: Security Engineer Question 283
Single answerMonitor anomalous credit consumption as a critical security signal:A Snowflake security engineering team wants to detect potential account compromise by monitoring for sudden spikes in credit consumption. Their concern is that an attacker who gains access to a service account could run large compute workloads at unusual times, creating both cost impact and a security signal. Which approach BEST supports ongoing detection and investigation of this type of anomaly?
- A
Create a Resource Monitor with a low credit quota on each warehouse and rely on suspension events as the primary way to detect suspicious activity.
- B
Query ACCOUNT_USAGE views such as WAREHOUSE_METERING_HISTORY and QUERY_HISTORY on a scheduled basis, compare usage against expected baselines by warehouse/user/time window, and alert on unusual credit spikes for investigation.
- C
Enable Tri-Secret Secure so any unauthorized compute activity is automatically blocked before credits are consumed.
- D
Review LOGIN_HISTORY only, because anomalous credit consumption can be inferred from successful logins without needing warehouse or query telemetry.
Show answer and explanation
Correct answer: B
Explanation
For security engineering in Snowflake, anomalous credit consumption can be a valuable indicator of compromise, misuse, or rogue automation. The strongest approach is to use Snowflake telemetry for usage analysis rather than relying only on preventive controls or login events. In practice, teams commonly query SNOWFLAKE.ACCOUNT_USAGE views such as WAREHOUSE_METERING_HISTORY to measure warehouse credit consumption over time and QUERY_HISTORY to identify the users, roles, warehouses, and SQL statements responsible for the spike. Comparing current activity to a baseline by warehouse, workload window, or service account behavior is aligned with real-world detection engineering. Resource Monitors are important for cost governance and can trigger notifications or suspensions, but they are not a substitute for anomaly detection and investigation. Relevant Snowflake documentation includes ACCOUNT_USAGE views for warehouse metering and query history, along with Resource Monitors for cost controls.
- A. Incorrect.
Incorrect. Resource Monitors are useful for controlling spend by notifying or suspending warehouses when thresholds are reached, but they are not designed to be the primary anomaly-detection mechanism for security monitoring. They do not inherently compare current usage to behavioral baselines, correlate activity to users or query patterns, or distinguish expected batch jobs from suspicious spikes. They are a cost-control tool that can complement, but not replace, security analytics.
- B. Correct.
Correct. Monitoring anomalous credit consumption as a security signal is best done by analyzing Snowflake telemetry such as WAREHOUSE_METERING_HISTORY for credit usage and QUERY_HISTORY for the workload generating that usage. A practical security approach is to schedule queries or dashboards that compare current consumption to historical baselines by warehouse, role, user, and time-of-day, then alert when activity deviates materially from normal patterns. This supports both detection and investigation because the team can pivot from a spend anomaly to the exact queries, users, and sessions involved.
- C. Incorrect.
Incorrect. Tri-Secret Secure strengthens key management and data protection by combining customer-managed and Snowflake-managed key material, but it does not detect or block suspicious compute usage patterns. It is unrelated to monitoring warehouse credit anomalies and would not prevent an attacker with valid access from running expensive queries.
- D. Incorrect.
Incorrect. LOGIN_HISTORY can help identify suspicious sign-in behavior, such as unusual IP addresses or connection patterns, but login telemetry alone is insufficient for monitoring anomalous credit consumption. A user might log in normally and still run abusive or compromised workloads. Effective detection requires warehouse and query-level telemetry to identify the actual compute spike.