nerdexam
Snowflake

SOL-C01 · Question #89

You are working with a Snowflake environment where cost optimization is critical. You need to limit the amount of data scanned by a specific query executed by a user with the 'ANALYST role. Which of t

The correct answer is B. Set the `STATEMENT _ parameter for the 'ANALYST role to limit the execution time of queries, D. Use resource monitors to set credit quotas at the warehouse level. Enforce the usage of the 'LIMIT. STATEMENT_TIMEOUT_IN_SECONDS (option B) is a Snowflake parameter that can be set at the role or user level - when a query exceeds the time limit (often caused by scanning excessive data), Snowflake automatically cancels it. This is a legitimate query-level guardrail for the ANALY

Virtual Warehouses

Question

You are working with a Snowflake environment where cost optimization is critical. You need to limit the amount of data scanned by a specific query executed by a user with the 'ANALYST role. Which of the following options represent valid methods to achieve this, considering both query- level and account- level settings?

Options

  • ASet the parameter for the 'ANALYST role to a low value to reduce resource consumption and,
  • BSet the `STATEMENT _ parameter for the 'ANALYST role to limit the execution time of queries,
  • CSet the parameter for the database to a low value. Also, limit the number of columns selected
  • DUse resource monitors to set credit quotas at the warehouse level. Enforce the usage of the 'LIMIT
  • EImplement row-level security policies and data masking to reduce the amount of data visible to the

How the community answered

(42 responses)
  • A
    5% (2)
  • B
    67% (28)
  • C
    19% (8)
  • E
    10% (4)

Explanation

STATEMENT_TIMEOUT_IN_SECONDS (option B) is a Snowflake parameter that can be set at the role or user level - when a query exceeds the time limit (often caused by scanning excessive data), Snowflake automatically cancels it. This is a legitimate query-level guardrail for the ANALYST role. Resource monitors (option D) are the standard warehouse-level tool for capping credit consumption; when combined with enforcing a LIMIT clause in queries, they address both preventive spending caps and result-set scoping.

Why the distractors fail:

  • A is vague and describes no real Snowflake parameter that directly limits data scanned - reducing concurrency or queue time doesn't restrict scan volume.
  • C is misleading: while selecting fewer columns does reduce scans in a columnar DB, there is no standard Snowflake database-level parameter you set to enforce this; it's also an incomplete control.
  • E - row-level security and data masking restrict visibility of data, but Snowflake's engine may still scan the underlying data; these are access controls, not cost controls.

Memory tip: Think of it as two layers - the query layer (B: timeout kills runaway scans) and the warehouse layer (D: resource monitors kill runaway spending). Snowflake cost controls map cleanly to those two layers; anything about "visibility" (masking, RLS) is a security concern, not a cost concern.

Topics

#Cost optimization#Resource monitors#Warehouse quotas#Query parameters

Community Discussion

No community discussion yet for this question.

Full SOL-C01 Practice