ARA-C01 Question 14
Single answerSession parametersA global analytics team uses Snowflake with shared worksheets, Python applications, and JDBC-based BI tools. The security architect needs to enforce consistent behavior for newly created sessions so that: (1) timestamps are interpreted in UTC for all users unless a team explicitly overrides it, and (2) accidental long-running queries from ad hoc users are automatically stopped after 10 minutes. The architect wants the solution to apply broadly with minimal application changes, while still allowing tighter settings for specific service accounts later. Which approach best meets these requirements?
- A
Set the TIMEZONE and STATEMENT_TIMEOUT_IN_SECONDS parameters at the ACCOUNT level, and override them at the USER level only for service accounts that need different values.
- B
Set the TIMEZONE and STATEMENT_TIMEOUT_IN_SECONDS parameters in every warehouse used by the team, because warehouses control session behavior for all clients that connect through them.
- C
Create a network policy that forces UTC timestamps and terminates queries that exceed 10 minutes for all sessions.
- D
Modify each application and BI tool connection string to pass TIMEZONE=UTC and STATEMENT_TIMEOUT_IN_SECONDS=600, because session parameters cannot be inherited from Snowflake objects.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to set session parameter defaults centrally at the ACCOUNT level and then use more specific overrides where needed, such as at the USER level for service accounts. In Snowflake, session parameters can be established through object-level parameter settings and can also be overridden within a session. This hierarchy is useful for enterprise architecture because it enables broad governance without forcing every client tool or application team to implement identical connection logic. TIMEZONE is a commonly standardized session parameter for consistent timestamp handling, and STATEMENT_TIMEOUT_IN_SECONDS is used to limit runaway queries. A practical pattern is to define organization-wide defaults at the account scope, then tighten or customize for specific users or workloads through lower-level overrides. This aligns with Snowflake documentation on parameter management and parameter hierarchy, including account, user, and session-level settings.
- A. Correct.
Correct. TIMEZONE and STATEMENT_TIMEOUT_IN_SECONDS are session parameters that can be set at multiple scopes, including the ACCOUNT level for broad defaults and the USER level for more specific overrides. This matches the requirement to apply settings widely with minimal application changes, while preserving the ability to assign different settings to selected service accounts later. Snowflake parameter hierarchy supports this kind of centralized defaulting and targeted override.
- B. Incorrect.
Incorrect. Warehouses manage compute resources and have some warehouse-level properties, but they do not control all session parameter behavior for clients connecting through them. TIMEZONE is not something you standardize by setting it on a warehouse for all sessions in the way described. This option reflects a common misconception that warehouse configuration is the main place to enforce client session semantics.
- C. Incorrect.
Incorrect. Network policies control allowed network locations and related access restrictions, not session semantics such as timestamp interpretation or query timeout behavior. They cannot be used to set TIMEZONE or STATEMENT_TIMEOUT_IN_SECONDS. This distractor targets confusion between access-control features and session configuration.
- D. Incorrect.
Incorrect. Applications can pass session parameters at connection time, but saying this is required is wrong. Snowflake supports parameter inheritance from higher-level objects such as the account and user, which is precisely the mechanism that reduces application changes. Using connection strings everywhere would increase operational overhead and make broad enforcement harder to maintain.