ARA-C01 Question 203
Single answer2.4 Given a scenario, outline how objects exist within the Snowflake object hierarchy and how the hierarchy impacts an architecture.A global enterprise is redesigning its Snowflake environment to support three business units in a single account. Each business unit needs its own schemas and tables, but all units must share a common set of secure views and UDFs maintained by a central data engineering team. The architects also want to minimize future refactoring if one business unit is later moved to a different database for legal reasons. Which design best aligns with Snowflake's object hierarchy and reduces architectural risk?
- A
Create one database per business unit, and place the shared secure views and UDFs in a central schema inside one of the business unit databases so all teams can reference them.
- B
Create separate schemas for each business unit within a single database, and place the shared secure views and UDFs in a dedicated shared schema in that same database.
- C
Create one schema per business unit directly under the account, and grant cross-schema access to the shared secure views and UDFs.
- D
Create separate warehouses for each business unit and store the shared secure views and UDFs in the warehouse used by the central data engineering team.
Show answer and explanation
Correct answer: B
Explanation
Snowflake's core hierarchy for data objects is account -> database -> schema -> objects such as tables, views, stages, and functions. Compute resources such as virtual warehouses are separate from this logical container hierarchy. A strong architecture should place related business objects in valid hierarchy locations and avoid unnecessary coupling that increases future migration effort. In this scenario, the requirement to support separate business unit objects while maintaining a centrally managed reusable layer is best met by using separate schemas for each business unit plus a dedicated shared schema in the same database. This keeps shared objects independent from any one business unit schema and avoids invalid assumptions such as schemas existing directly under an account or logical objects being stored in warehouses. This approach is consistent with Snowflake documentation on object hierarchy, databases and schemas, and the distinction between storage/database objects and compute resources.
- A. Incorrect.
Incorrect. Although Snowflake allows objects in one database to reference objects in another database with fully qualified names, placing shared logical objects inside a business unit's database creates an architectural dependency on that database. If that business unit is later moved to a different database or restructured, the shared objects remain tied to the original database hierarchy and may require broader refactoring. This design also weakens separation of ownership because centrally managed shared assets should not reside inside a single business unit's database.
- B. Correct.
Correct. In Snowflake, schemas exist inside databases, and tables, views, and UDFs exist inside schemas. Placing each business unit in its own schema and storing centrally managed shared secure views and UDFs in a dedicated shared schema within the same database respects the object hierarchy while reducing cross-database dependencies. If a business unit later needs to move to a different database, the shared assets remain logically centralized and not embedded in that business unit's schema. This is often a practical design when common semantic or governance objects are broadly consumed across closely related domains.
- C. Incorrect.
Incorrect. Schemas cannot exist directly under the account in Snowflake. The hierarchy requires schemas to be contained within a database. This option reflects a common misconception about Snowflake object hierarchy. Because the proposed structure is invalid, it cannot be the right architectural choice.
- D. Incorrect.
Incorrect. Warehouses are compute resources, not containers for database objects. Views and UDFs are database objects that must exist within a schema, which itself must exist within a database. This option confuses storage/logical object hierarchy with compute isolation.