ARA-C01 Question 4
Single answer1.1 Design a Snowflake account and database strategy, based on business requirements.A global company is redesigning its Snowflake environment after several acquisitions. It has three business units: Retail, Healthcare, and Financial Services. Each business unit has its own data engineering team, separate chargeback requirements, and distinct security policies. Healthcare data is subject to strict regulatory controls, and the company wants to minimize the risk of accidental cross-unit access. At the same time, the enterprise analytics team needs to consume curated data from all three business units for corporate reporting. The company wants an architecture that supports strong isolation, delegated administration, and clear cost attribution while still enabling governed data sharing across the enterprise. Which design approach best meets these requirements?
- A
Create a single Snowflake account with one database per business unit, and use database roles plus schemas to separate administration, security, and chargeback across units.
- B
Create separate Snowflake accounts for each business unit, and use Secure Data Sharing or shares to publish approved datasets to a central enterprise analytics account.
- C
Create one Snowflake account for Retail and Financial Services, and a separate account for Healthcare only, because only regulated data requires account-level isolation.
- D
Create separate virtual warehouses for each business unit in a single account, and use warehouse-level resource monitors as the primary mechanism for security isolation and cost attribution.
Show answer and explanation
Correct answer: B
Explanation
For SnowPro Advanced Architect, candidates should recognize when business requirements justify a multi-account strategy instead of only using databases and schemas inside a single account. Snowflake best practices generally favor separate accounts when organizations need stronger isolation, decentralized administration, distinct security postures, clearer billing/chargeback boundaries, or regional/compliance separation. In this scenario, each business unit has its own team, policies, and cost accountability, and the company wants to reduce accidental cross-unit exposure. A multi-account design addresses those needs more effectively than a single-account model. To still enable enterprise-wide analytics, Snowflake Secure Data Sharing is an appropriate mechanism to publish curated datasets from producer accounts to a consumer analytics account. This approach supports governed sharing without relying on broad cross-unit privileges in one shared account. Relevant Snowflake documentation and architecture guidance include account strategy considerations, organization/account design, and Secure Data Sharing for cross-account data access.
- A. Incorrect.
This approach provides logical separation at the database level, but it does not best satisfy the stated need for strong isolation, delegated administration by independent business units, and minimized risk of accidental cross-unit access. In a single account, some administration and governance boundaries remain shared at the account level. Although database roles, schemas, masking policies, and row access policies can help with internal separation, they are not the strongest design choice when business units require distinct security policies, separate administration, and clear chargeback with reduced blast radius.
- B. Correct.
This is the best answer. Separate Snowflake accounts per business unit provide stronger isolation boundaries, support delegated administration, and simplify cost attribution at the account level. This model is well aligned to organizations with separate business entities, compliance differences, and autonomous platform teams. Secure Data Sharing enables the enterprise analytics account to consume governed datasets without copying data unnecessarily, preserving producer control while supporting enterprise reporting. This design is commonly recommended when isolation, administrative autonomy, and controlled sharing are key requirements.
- C. Incorrect.
This option is partially attractive because Healthcare has strict regulatory requirements, but it does not fully meet the broader business requirement that all three units have separate chargeback, distinct security policies, and independent data engineering teams. Retail and Financial Services would still share account-level administrative boundaries and a larger accidental access surface. The scenario explicitly calls for strong isolation and delegated administration across all business units, not only the regulated one.
- D. Incorrect.
Warehouses are compute constructs, not security or governance boundaries for data isolation. Separate warehouses can help with workload isolation and cost tracking, but they do not prevent cross-unit access to data in the same account if privileges are granted incorrectly. Resource monitors help control or observe credit consumption, but they are not a substitute for account and data-domain design. This option addresses compute management more than account and database strategy.