ARA-C01 Question 30
Single answerConfigure Role-Based Access Control (RBAC) hierarchyA Snowflake architect is redesigning RBAC for a company with three business units: Finance, Sales, and Operations. Each business unit has analysts who need read access only to their own schema, and a small group of data stewards who must manage objects within their unit's schema. A central platform team must retain ownership of warehouses and account-level administration, while minimizing direct grants to individual users. The architect wants a scalable hierarchy that supports least privilege and simplifies onboarding. Which approach should the architect implement?
- A
Create functional roles for each business unit (for example, FINANCE_ANALYST and FINANCE_STEWARD), grant object privileges to those roles, then grant those roles to higher-level business unit roles and finally to users as needed; keep account-level administrative roles separate from business data access roles.
- B
Grant all schema-level privileges directly to individual users in each business unit, and reserve roles only for the platform team so user access can be managed more precisely.
- C
Grant SYSADMIN to all data stewards because they need to manage objects in their schemas, and rely on database and schema ownership to limit their access to only their own business unit.
- D
Create one shared ANALYST role and one shared STEWARD role for all business units, grant both roles access to all three schemas, and use future grants to simplify administration.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to build a layered RBAC hierarchy using business-unit-specific functional roles and separate administrative roles. In Snowflake, best practice is to grant privileges to roles and grant roles to users, avoiding direct user grants wherever possible. A common enterprise design is to create access roles that hold object privileges, then grant those to higher-level functional or business roles. This supports least privilege, easier auditing, and simpler onboarding/offboarding. System-defined administrative roles such as SYSADMIN should be tightly controlled and not used for routine business-unit stewardship. Snowflake documentation on access control and role hierarchy emphasizes role-based privilege assignment, role inheritance, and separation of duties between administrative and data-access responsibilities.
- A. Correct.
Correct. This design follows Snowflake RBAC best practices by assigning privileges to roles, not users, and using a role hierarchy to aggregate permissions cleanly. Separate functional roles per business unit support least privilege because Finance users do not automatically inherit Sales or Operations access. Stewards can receive elevated privileges only within their unit's schema, while platform administrators retain separate account-level roles such as SYSADMIN or custom admin roles. This approach also scales well for onboarding because new users are granted the appropriate business role instead of receiving many direct object grants.
- B. Incorrect.
Incorrect. Directly granting privileges to users is not a recommended scalable RBAC design in Snowflake. It increases administrative overhead, makes audits harder, and weakens the role hierarchy model Snowflake is designed around. Although some administrators may think direct user grants provide precision, the better practice is to encapsulate privileges in roles and then grant roles to users.
- C. Incorrect.
Incorrect. SYSADMIN is a powerful system-defined role intended for broad object management across the account, not limited stewardship within one schema. Granting SYSADMIN to data stewards would violate least privilege and create excessive access. Ownership and container structure do not safely constrain SYSADMIN to only one business unit's objects.
- D. Incorrect.
Incorrect. A single shared ANALYST and STEWARD role across all business units would overgrant access because analysts and stewards would be able to access all three schemas instead of only their own. Future grants can simplify administration, but they do not solve the core least-privilege problem when the role design is too broad.