DEA-C01 Practice Question 37: Redshift Query Monitoring Rule

Query monitoring rules "define metrics-based performance boundaries for WLM queues and specify what action to take when a query goes beyond those boundaries"; the documentation's own example is "for a queue dedicated to short running queries, you might create a rule that cancels queries that run for more than 60 seconds." query_execution_time is elapsed execution time in seconds, excluding queue wait, and the abort action logs the action and cancels the query. WLM evaluates metrics every 10 seconds, so the cancellation is prompt and needs no DBA. Every triggered rule writes a row to STL_WLM_RULE_ACTION, which is the audit record the team asked for. Because "the rules in a given queue apply only to queries running in that queue", the ETL queue is untouched. AWS explicitly recommends this over WLM timeout: "To limit the runtime of queries, we recommend creating a query monitoring rule instead of using WLM timeout."

Option A is an unreliable proxy for a time limit. A cross join that returns few columns can spill to disk and grind on for hours without ever exhausting memory, while legitimate large aggregations would start failing. It also degrades every query in the queue.

Option B changes routing, not termination. Short query acceleration gets short queries past the long one faster, but the runaway query keeps consuming cluster resources indefinitely and nothing is logged or cancelled.

Option C buys capacity to run more queries alongside the problem query. The runaway still runs for hours, the cluster now pays for transient capacity to work around it, and no record of the offending query's termination exists because it is never terminated.

Reference: WLM query monitoring rules