ARA-C01 Question 210
Single answerObject hierarchyA global enterprise is redesigning its Snowflake environment to support multiple business units. The architecture team wants to enforce a consistent object hierarchy so that each business unit can manage its own schemas and tables independently, while a central platform team retains control over account-level governance. The company also wants to simplify future database replication and failover planning for business-unit data. Which design choice best aligns with Snowflake object hierarchy and these requirements?
- A
Create one database per business unit, with schemas inside each database for domain-specific objects, and let the central team manage account-level objects such as roles, warehouses, and resource monitors.
- B
Create one schema per business unit inside a shared enterprise database, and let each business unit create and manage its own virtual warehouses within that schema.
- C
Create one warehouse per business unit and place schemas and tables under the warehouse so compute and storage are aligned in the same hierarchy.
- D
Create one database role per business unit and store schemas, tables, and file formats under the database role to simplify delegation.
Show answer and explanation
Correct answer: A
Explanation
The key Snowflake hierarchy concept is that account-level objects and database-level objects are distinct. Within the data object hierarchy, a database contains schemas, and schemas contain objects such as tables, views, stages, streams, tasks, and file formats. Warehouses, users, roles, resource monitors, and similar governance constructs exist at the account level and are not children of databases or schemas. For a multi-business-unit architecture, using separate databases per business unit is a strong design because it creates clear ownership boundaries, simplifies privilege delegation, and aligns well with operational patterns such as replication/failover planning and lifecycle management. This also preserves the central platform team's control over account-level governance while allowing business units to manage their own schemas and objects within their databases. This aligns with Snowflake documentation on object hierarchy, securable objects, and account-level versus database-level scope.
- A. Correct.
Correct. In Snowflake, the object hierarchy places databases above schemas, and schemas contain database objects such as tables, views, stages, and file formats. Account-level objects, including warehouses, users, roles, resource monitors, network policies, and shares, are managed at the account level rather than inside databases or schemas. Using one database per business unit creates a clean administrative and ownership boundary, supports decentralized schema and object management, and is a practical design for replication and failover because replication is commonly scoped around databases and other supported higher-level containers rather than individual schemas as the primary organizational boundary.
- B. Incorrect.
Incorrect. While using one schema per business unit inside a shared database can work for some lightweight organizational models, it weakens isolation between business units compared to separate databases. More importantly, schemas cannot contain virtual warehouses because warehouses are account-level objects, not schema-level objects. This option reflects a common misconception that compute objects belong inside the database/schema hierarchy.
- C. Incorrect.
Incorrect. Warehouses are compute resources and are not parents of schemas or tables. Snowflake separates compute from storage: databases and schemas organize stored objects, while warehouses execute workloads against them. This option incorrectly treats the warehouse as part of the storage hierarchy.
- D. Incorrect.
Incorrect. Database roles are securable objects used to manage privileges on objects within a database, but they do not contain schemas, tables, or file formats. They are part of the access control model, not the data object hierarchy. This distractor targets the misconception that security constructs can act as containers for database objects.