ARA-C01 Question 25
Single answerIdentify use cases that are appropriate for account strategiesA global enterprise is redesigning its Snowflake environment. It has three major requirements: 1) the finance team must operate under stricter account-level governance and separate billing visibility from other departments, 2) a regulated healthcare workload must use a different cloud region to satisfy data residency requirements, and 3) several internal development teams need isolated sandboxes but should still share the same enterprise security integrations and centrally governed production data. Which approach best matches Snowflake account strategy best practices?
- A
Use a single Snowflake account with separate virtual warehouses, databases, and roles for all workloads because account-level separation is rarely needed when RBAC is implemented correctly.
- B
Create separate Snowflake accounts for finance and the regulated healthcare workload, and use additional accounts selectively for development sandboxes where strong isolation is needed; connect them through organization-level administration and secure data sharing/replication patterns as appropriate.
- C
Create one account per department, project, and environment so every workload has its own full isolation boundary, regardless of governance, cost, or operational overhead.
- D
Keep production in one account and move only the healthcare schemas into a different database, since databases provide the same residency and billing isolation benefits as separate accounts.
Show answer and explanation
Correct answer: B
Explanation
The key architectural skill is knowing when multiple Snowflake accounts are warranted versus when a single account with logical isolation is sufficient. Appropriate use cases for account strategies include distinct regulatory or governance boundaries, separate billing/administrative ownership, and workloads that must reside in different cloud regions or clouds. In contrast, using separate warehouses, databases, schemas, and RBAC inside one account is often sufficient for many internal isolation needs. Snowflake best practices generally favor avoiding unnecessary account sprawl while using multiple accounts deliberately for stronger isolation and region-specific deployment requirements. Relevant Snowflake documentation areas include Organizations and accounts, replication and failover/group-based cross-account patterns, secure data sharing, and guidance on multi-account strategies for governance and regional deployment.
- A. Incorrect.
Incorrect. A single account can isolate many workloads using roles, databases, schemas, and warehouses, but it does not satisfy all account-strategy use cases. Separate billing visibility at an account boundary, stricter account-level governance, and especially different cloud region requirements are common reasons to use multiple accounts. RBAC alone does not replace account-level isolation when regulatory, regional, or administrative separation is required.
- B. Correct.
Correct. This option aligns with recommended account-strategy thinking: use multiple accounts when there is a clear need for stronger isolation, separate administration/billing boundaries, or deployment in different regions/clouds. Finance may justify a separate account for governance and chargeback visibility, the healthcare workload requires a separate account because region placement is an account-level deployment decision, and development sandboxes may use separate accounts when isolation is important. Snowflake Organizations, account-level administration, replication, and secure sharing are commonly used to manage and connect these accounts.
- C. Incorrect.
Incorrect. This is an over-segmentation anti-pattern in many cases. Although multiple accounts can be useful, creating an account for every department, project, and environment introduces unnecessary administrative complexity, more complicated data movement/sharing patterns, and higher operational overhead. Best practice is to use additional accounts only when there is a justified need such as regulatory separation, regional constraints, or distinct administrative boundaries.
- D. Incorrect.
Incorrect. Databases and schemas are logical containers inside an account; they do not change the account's region or create account-level billing/governance boundaries. If a workload must run in a different cloud region for residency or sovereignty reasons, that generally requires a separate Snowflake account deployed in that region. This option reflects a common misconception that object-level separation can substitute for account-level deployment decisions.