ARA-C01 Question 7
Single answerParameters (all levels)A Snowflake architect is standardizing how query execution time limits are enforced across a multi-tenant environment. The company wants these behaviors: all users should inherit a 10-minute statement timeout by default, the FINANCE role should use a stricter 5-minute timeout for its sessions, and one critical ETL user should be allowed up to 30 minutes regardless of the role they are using. The architect wants to implement this using the minimum number of changes while respecting Snowflake parameter precedence. Which configuration will meet the requirement?
- A
Set STATEMENT_TIMEOUT_IN_SECONDS = 600 at the account level, set STATEMENT_TIMEOUT_IN_SECONDS = 300 on the FINANCE role, and set STATEMENT_TIMEOUT_IN_SECONDS = 1800 on the ETL user.
- B
Set STATEMENT_TIMEOUT_IN_SECONDS = 600 at the account level, set STATEMENT_TIMEOUT_IN_SECONDS = 300 on all FINANCE warehouses, and set STATEMENT_TIMEOUT_IN_SECONDS = 1800 on the ETL user's default warehouse.
- C
Set STATEMENT_TIMEOUT_IN_SECONDS = 600 at the account level, set STATEMENT_TIMEOUT_IN_SECONDS = 300 on the FINANCE database, and set STATEMENT_TIMEOUT_IN_SECONDS = 1800 on the ETL schema.
- D
Set STATEMENT_TIMEOUT_IN_SECONDS = 600 at the account level, set STATEMENT_TIMEOUT_IN_SECONDS = 300 in the FINANCE users' session initialization SQL, and set STATEMENT_TIMEOUT_IN_SECONDS = 1800 at the account level during ETL windows.
Show answer and explanation
Correct answer: A
Explanation
Snowflake supports parameters at different levels, and the effective value is determined by parameter hierarchy and object applicability. For session-related behavior such as STATEMENT_TIMEOUT_IN_SECONDS, architects should prefer centralized configuration at the highest practical level, then override only where business requirements justify it. In this scenario, the account-level parameter provides the organization-wide default, the role-level parameter tightens behavior for FINANCE sessions, and the user-level parameter gives the ETL user a more specific exception. This aligns with Snowflake best practices for using account, role, user, and session parameter scopes rather than relying on less-governable client-side session SQL or unrelated object scopes such as databases and schemas. Refer to Snowflake documentation on parameter hierarchy and the STATEMENT_TIMEOUT_IN_SECONDS parameter for the supported levels and precedence behavior.
- A. Correct.
Correct. STATEMENT_TIMEOUT_IN_SECONDS can be set at multiple levels, including account, user, and session, and Snowflake applies parameter precedence so more specific settings override broader defaults. Setting 600 at the account level establishes the default for everyone. Setting 300 on the FINANCE role provides a stricter limit for sessions using that role. Setting 1800 on the ETL user gives that user a more specific override than the role-level setting, allowing the ETL user to run longer statements regardless of which role is active. This satisfies the requirement with minimal administrative changes.
- B. Incorrect.
Incorrect. Although warehouse-level parameters exist for some settings, using warehouses here does not reliably implement a role-based timeout policy. The requirement is tied to users and roles, not to where workloads happen to run. If FINANCE users run on multiple warehouses, or if non-FINANCE users share those warehouses, the behavior would not match the intended policy. In addition, setting a longer timeout only on the ETL user's default warehouse would not guarantee the override if that user executes statements on another warehouse.
- C. Incorrect.
Incorrect. Database and schema parameters are used for parameters that apply to objects within those scopes, but statement timeout is not managed to enforce role-specific session behavior via database or schema settings. The requirement is about session/query execution limits by principal context, so account, role, user, or session scopes are the relevant mechanisms. Choosing database and schema scopes reflects a misunderstanding of parameter applicability.
- D. Incorrect.
Incorrect. Using session initialization SQL for FINANCE users is operationally fragile and not the minimum-change approach, because it depends on consistent client behavior and user configuration rather than centralized governance. Temporarily changing the account-level timeout during ETL windows is also risky because it affects all sessions that inherit the account default at that time, not just the ETL user. This approach does not provide a clean, deterministic override model.