ARA-C01 Question 10
Single answerAccount parametersA global enterprise is standardizing Snowflake session behavior across hundreds of users and service accounts. Security requires all new sessions in the account to use UTC unless a workload explicitly overrides it, and the architecture team also wants to minimize per-user administration. An architect proposes changing an account parameter rather than updating every user individually. Which action best meets these requirements?
- A
Execute ALTER ACCOUNT SET TIMEZONE = 'UTC'; so UTC becomes the default for new sessions unless a lower-level setting overrides it
- B
Execute ALTER SESSION SET TIMEZONE = 'UTC'; so all future sessions in the account inherit UTC automatically
- C
Execute ALTER USER SET TIMEZONE = 'UTC'; once at the account level so every existing and future user inherits UTC
- D
Execute ALTER WAREHOUSE SET TIMEZONE = 'UTC'; because session defaults are inherited from the virtual warehouse used
- E
Execute ALTER DATABASE SET TIMEZONE = 'UTC'; because object-level parameters take precedence over users and sessions
Show answer and explanation
Correct answer: A
Explanation
The best solution is to set the TIMEZONE account parameter using ALTER ACCOUNT SET TIMEZONE = 'UTC'. Snowflake parameters are scoped and inherited based on the parameter type. For session-related parameters such as TIMEZONE, the effective value is typically determined from the most specific level available, with session-level settings overriding user-level settings, and user-level settings overriding account-level defaults. This makes the account parameter the right place to establish a broad standard while preserving flexibility for exceptional workloads that explicitly need a different timezone. This approach also reduces administrative effort compared to configuring each user individually. In Snowflake documentation, this behavior is described under account, user, and session parameters, including the use of ALTER ACCOUNT, ALTER USER, and ALTER SESSION to manage parameter defaults and overrides.
- A. Correct.
Correct. TIMEZONE is a parameter that can be set at the account, user, and session levels. Setting it with ALTER ACCOUNT establishes the account-wide default for sessions, which is the most scalable approach when the goal is to standardize behavior across many users while still allowing explicit overrides at lower levels such as user or session.
- B. Incorrect.
Incorrect. ALTER SESSION affects only the current session in which the command is executed. It does not change the default for other current or future sessions created by other users or services, so it does not satisfy the enterprise-wide requirement.
- C. Incorrect.
Incorrect. ALTER USER is valid only for a specific user, not for all users collectively in a single command. While user-level settings can override the account default, using ALTER USER for every user would increase administrative overhead and does not help with future users unless additional automation is built.
- D. Incorrect.
Incorrect. TIMEZONE is not inherited from a warehouse. Warehouses control compute resources and certain warehouse-specific behaviors, but session parameters such as TIMEZONE are governed by parameter hierarchy like account, user, and session levels, not warehouse defaults.
- E. Incorrect.
Incorrect. TIMEZONE is not established as a database-level default for user sessions. Databases have their own applicable parameters, but session behavior like TIMEZONE is not managed through ALTER DATABASE in the way described here. This option reflects a common misconception that all parameters can be set on any object.