SnowPro Advanced: Security Engineer Question 277
Single answerCredit consumption considerationsA security engineering team is rolling out account-wide access monitoring in Snowflake. They want to use a serverless ALERT to detect when users are granted powerful roles outside the approved process and immediately notify the SOC. During a pilot, finance reports a noticeable increase in Snowflake credits. The team must reduce ongoing credit consumption without weakening the control. Which action should the team take?
- A
Reduce the ALERT evaluation frequency so it runs only as often as required by the risk tolerance and incident response SLA
- B
Move the ALERT logic to a larger dedicated virtual warehouse so each evaluation completes faster and uses fewer credits overall
- C
Convert the ALERT to a TASK that continuously runs every minute on an X-Small warehouse, because user-managed compute is always cheaper than serverless compute
- D
Replace the ALERT with a masking policy on the grant history views, because policies do not consume credits when evaluating security conditions
Show answer and explanation
Correct answer: A
Explanation
The best answer is to reduce the ALERT evaluation frequency to the minimum cadence that still satisfies the organization's detection and response requirements. In Snowflake, ALERTS are designed for conditional monitoring and can use serverless compute; that convenience can increase credit consumption if checks are scheduled more often than necessary. For a security engineer, cost-aware design means balancing control effectiveness with operational efficiency. A common best practice is to tune polling schedules, simplify evaluation logic, and avoid unnecessary executions. Replacing ALERTS with unrelated security objects such as masking policies does not address the same risk, and assuming user-managed warehouses are inherently cheaper than serverless compute is not accurate. See Snowflake documentation for ALERTS, serverless compute considerations, and cost monitoring best practices.
- A. Correct.
Correct. Serverless ALERTS consume credits when they evaluate and when the triggered action executes. If the control is checking more frequently than the business actually requires, reducing the schedule frequency is the most direct and reliable way to lower credit usage while preserving the monitoring objective. This is a practical tuning step for security operations: align evaluation cadence with actual risk tolerance and response requirements instead of polling excessively.
- B. Incorrect.
Incorrect. A serverless ALERT does not use a customer-managed virtual warehouse, so moving it to a larger warehouse is not how ALERT compute is controlled. More broadly, increasing compute size is not a sound credit-optimization strategy for a lightweight grant-monitoring query. This option reflects the common misconception that all scheduled security checks run on user-managed warehouses.
- C. Incorrect.
Incorrect. TASKS can use either serverless or user-managed compute depending on configuration, but replacing an ALERT with a TASK every minute does not inherently reduce cost. In many cases, very frequent polling on a warehouse can increase or at least unpredictably shift costs rather than reduce them. Also, 'always cheaper' is false; cost efficiency depends on workload pattern, scheduling, and warehouse runtime behavior.
- D. Incorrect.
Incorrect. Masking policies protect data at query time and are unrelated to detecting unauthorized role grants in account metadata. They are not a substitute for event or condition monitoring. This distractor targets the misconception that any security feature can be swapped in to reduce compute costs; in reality, the feature must match the control objective.