ARA-C01 Question 209
Single answerObject hierarchyA global enterprise is redesigning its Snowflake environment to separate workloads by business unit while centralizing governance. The platform team wants each business unit to manage its own schemas, tables, and views without affecting other units. They also want to simplify future cloning of complete business-unit data environments for testing. Which design best aligns with Snowflake object hierarchy best practices?
- A
Create one database for the entire company, and give each business unit its own warehouse and role. Store all business-unit objects in the PUBLIC schema to reduce administrative overhead.
- B
Create a separate database for each business unit, and within each database create schemas for functional areas such as raw, curated, and reporting. Delegate schema-level object management to the business unit teams.
- C
Create one schema for each business unit inside a shared database, and place raw, curated, and reporting objects for all business units into the same schema to make cross-unit queries easier.
- D
Create separate warehouses for each business unit, and rely on warehouse isolation rather than database and schema structure to separate ownership and simplify cloning.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use a separate database for each business unit and then organize schemas within each database by function. In Snowflake's object hierarchy, databases contain schemas, and schemas contain objects such as tables and views. This design creates a strong administrative and governance boundary while still allowing each business unit to manage its own lower-level objects. It also supports practical operational needs such as cloning an entire business unit environment by cloning the database. Snowflake documentation and architectural best practices emphasize using databases and schemas as logical containers for organization, privilege management, and lifecycle operations, while warehouses should be treated separately as compute resources rather than organizational boundaries for data objects.
- A. Incorrect.
Incorrect. While separate warehouses and roles can help with compute isolation and access control, placing all objects in the PUBLIC schema is a poor design choice for governance and organization. PUBLIC is a schema within a database, not a substitute for a well-planned hierarchy. A single database with all business-unit objects in PUBLIC reduces logical separation, makes delegated administration harder, and complicates cloning just one business unit's full environment.
- B. Correct.
Correct. In Snowflake, the object hierarchy places schemas inside databases and schema objects such as tables and views inside schemas. Using a separate database per business unit creates a clear top-level boundary for ownership, security administration, lifecycle management, and cloning. Organizing schemas by functional area within each database supports modular design and delegated management. This also makes it straightforward to clone an entire business unit environment at the database level when needed for testing or development.
- C. Incorrect.
Incorrect. A shared database with one schema per business unit is better than putting everything in PUBLIC, but placing raw, curated, and reporting objects together in the same schema for each unit reduces manageability and does not align well with layered data design. It can make privilege management, naming conventions, and lifecycle operations more difficult. Also, database-level cloning of an entire business unit is less clean when multiple units share the same database.
- D. Incorrect.
Incorrect. Warehouses are compute resources and are not part of the logical storage hierarchy used to organize data objects. They do not contain schemas, tables, or views, and warehouse isolation does not provide object hierarchy separation. Cloning applies to data containers such as databases and schemas, not warehouses, so this approach does not meet the stated requirement.