SnowPro Advanced: Data Engineer · Free practice question 10 of 10
Alerting on Cortex AI credit usage
A single AI_SUMMARIZE_AGG call on a large log table consumed 1,200 credits, even though it ran on a Small warehouse. The team wants a Snowflake-native automated alert whenever any Cortex AI SQL query consumes more than 300 credits, so they can review the query text and the model used. Which approach best meets that requirement?
- A.Attach a resource monitor with a 300-credit limit to the warehouse; its notification will identify the offending query.
- B.Set STATEMENT_TIMEOUT_IN_SECONDS to a value that maps to about 300 credits of runtime so long queries are terminated.
- C.Create a scheduled task that queries SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AISQL_USAGE_HISTORY for CREDITS_USED > 300, joins to QUERY_HISTORY for the SQL text and model, and sends a message via a notification integration.
- D.Alert on SNOWFLAKE.ACCOUNT_USAGE.METERING_DAILY_HISTORY where SERVICE_TYPE = 'AI_SERVICES' and TOTAL_CREDITS > 300 for the current day.
Show answer and explanation
Correct answer: C. Create a scheduled task that queries SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AISQL_USAGE_HISTORY for CREDITS_USED > 300, joins to QUERY_HISTORY for the SQL text and model, and sends a message via a notification integration.
Why: Resource monitors act on aggregate warehouse credit usage, not per-query Cortex spend. Statement timeout terminates by wall-clock time, not credits, and can't discriminate Cortex from other work. Daily aggregate views detect the problem after the day is over, when nothing can be reviewed in-flight. The purpose-built path is a scheduled task over CORTEX_AISQL_USAGE_HISTORY joined to QUERY_HISTORY, with a notification integration for delivery — exactly the pattern Snowflake recommends for per-query Cortex cost observability.
More free SnowPro Advanced: Data Engineer questions
- Snowpark lazy evaluation
- Dynamic tables with TARGET_LAG
- Snowpipe Streaming for sub-10-second latency
- Fan-in task DAGs with AFTER
- Time Travel vs Fail-safe recovery window
- Maintaining externally managed Iceberg tables
- External table partition metadata refresh
- Tag propagation across data movement
- Query Acceleration max scale factor