ARA-C01 Question 5
Single answerCreate and configure Snowflake parameters based on a central account and any additional accounts.A global enterprise is implementing a Snowflake multi-account strategy. One central account is used to define organization-wide standards, and three additional accounts are used for regional workloads. The security team requires that all users authenticate with SSO, and the data platform team wants to minimize manual configuration drift when new accounts are added. Which approach should the architect recommend to meet these requirements with the least ongoing administrative effort?
- A
Configure the SSO-related account parameters and security integration separately in each regional account, because account parameters cannot be standardized from a central account.
- B
Define the authentication-related settings at the organization level from the central account so that they can be inherited by the additional accounts, and override them only when a regional exception is required.
- C
Create all users in the central account and share them to the regional accounts so that account-level authentication parameters only need to be maintained once.
- D
Set the required authentication behavior as user-level parameters in the central account, because user parameters automatically propagate across all accounts in the organization.
Show answer and explanation
Correct answer: B
Explanation
The best recommendation is to use the central organization context to define supported authentication-related standards for member accounts, rather than manually repeating configuration in every account. In Snowflake, architects should prefer centralized governance mechanisms when the requirement is to reduce configuration drift and simplify onboarding of additional accounts. This is especially relevant in organizations operating multiple Snowflake accounts for regional, business-unit, or environment isolation.
A key design principle is understanding parameter scope and inheritance. Snowflake supports parameters at multiple levels, such as organization, account, user, session, and object levels depending on the parameter type. For a multi-account architecture, settings that can be controlled centrally should be managed from the organization account when possible, while exceptions should be limited and intentional. By contrast, user-level settings are not a substitute for organization-wide account governance, and users themselves are not global objects shared across accounts.
This aligns with Snowflake best practices around centralized administration, minimizing manual per-account configuration, and using the highest appropriate scope for governance. Candidates should recognize the difference between account-scoped objects and organization-level controls, and should avoid designs that depend on repetitive configuration in each account unless no centralized option exists.
- A. Incorrect.
Incorrect. While administrators can configure settings independently in each account, this increases operational overhead and creates configuration drift risk. Snowflake supports organization-level parameter management for certain settings from the organization account, which is specifically intended to help standardize behavior across accounts. Choosing per-account configuration ignores the requirement to minimize manual administration.
- B. Correct.
Correct. In a multi-account Snowflake environment, the organization account can be used as the central place to manage certain organization-scoped settings and parameters that apply to accounts in the organization. Using central governance and inheritance is the best fit when the goal is consistent authentication behavior across multiple accounts with reduced drift. Regional accounts can still diverge only where explicitly necessary, which aligns with least-effort governance.
- C. Incorrect.
Incorrect. Snowflake users are account-scoped, not shared objects that can be created once in one account and then reused across other accounts. This option reflects a common misconception that identity objects behave like data shares or replicated objects. Authentication and user administration must still be handled within each account context, even when central governance features are used for supported parameters.
- D. Incorrect.
Incorrect. User-level parameters do not automatically propagate across multiple accounts in an organization. Users and their parameters exist within the scope of an individual account. This option confuses parameter hierarchy within an account with organization-level governance across accounts.