ARA-C01 Question 6
Single answerCreate and configure Snowflake parameters based on a central account and any additional accounts.A global enterprise is deploying a hub-and-spoke Snowflake architecture with one central account used for security and governance administration and several additional business-unit accounts for workloads. The lead architect must standardize account behavior so that all new sessions in every account use UTC for timestamps, enforce a 15-minute statement timeout for ad hoc workloads, and ensure object identifiers are not case-sensitive when users omit quotes. The company also wants each business unit to retain the ability to override some defaults later for specific roles or sessions if needed. Which approach should the architect take to meet these requirements with the least operational overhead?
- A
In each Snowflake account, configure the required values as ACCOUNT parameters, then allow lower-level overrides through USER, SESSION, or object-level parameter settings where supported.
- B
Configure the required values once in the central account; because account parameters automatically propagate to all linked Snowflake accounts in the organization, no further action is needed.
- C
Create a database in the central account containing parameter templates, and grant imported privileges to the additional accounts so they inherit those parameter values automatically.
- D
Set the required values only at the session level through client connection properties in each tool, because session parameters cannot be overridden by users after login.
Show answer and explanation
Correct answer: A
Explanation
The best practice is to set baseline behavior using ACCOUNT parameters in each Snowflake account and then use Snowflake's parameter hierarchy to permit more specific overrides where appropriate. For this scenario, the architect should configure parameters such as TIMEZONE = UTC, STATEMENT_TIMEOUT_IN_SECONDS = 900, and QUOTED_IDENTIFIERS_IGNORE_CASE as account defaults separately in the central account and in each additional business-unit account. Snowflake parameters are scoped and inherited by level; they are not automatically replicated from one account to another simply because those accounts belong to the same organization. In real-world multi-account designs, architects typically use infrastructure-as-code, SQL deployment scripts, or orchestration pipelines to keep parameter settings consistent across accounts while still allowing controlled lower-level exceptions. This aligns with Snowflake documentation on parameter hierarchy and account parameter management.
- A. Correct.
Correct. Parameters such as TIMEZONE, STATEMENT_TIMEOUT_IN_SECONDS, and QUOTED_IDENTIFIERS_IGNORE_CASE can be configured at the account level within each individual Snowflake account. Snowflake parameter inheritance allows more specific scopes, such as user or session, to override broader defaults where applicable. This matches the requirement to establish standardized defaults while preserving flexibility for business units to override certain settings later. Because parameters are not centrally pushed from one account to other accounts, the architect must apply them per account, typically using automation to reduce operational effort.
- B. Incorrect.
Incorrect. A common misconception is that a central or governance account can directly propagate account parameters across all other accounts in the organization. Snowflake Organizations provide centralized visibility and some cross-account administration capabilities, but account parameters remain scoped to each Snowflake account. The architect must configure those parameters separately in every account.
- C. Incorrect.
Incorrect. Snowflake does not support inheriting account parameter values through a shared database, imported privileges, or template objects stored in another account. Databases and shares control access to data and certain metadata, not account-level behavioral defaults like session/account parameters. This option confuses data-sharing mechanisms with account configuration.
- D. Incorrect.
Incorrect. Session-level settings can be useful for specific tools or workloads, but relying only on client-side session properties increases operational overhead and does not provide a consistent default across all users and tools. In addition, users or applications may still alter session parameters depending on privileges and connection behavior. The requirement calls for standardized defaults with optional overrides, which is better addressed using account-level parameters in each account.