SnowPro Advanced: Security Engineer Question 11
Single answerManage hierarchical RBAC modelsA security engineer is redesigning access in Snowflake for a company with three business units: FINANCE, HR, and SALES. Each business unit has analysts who need read-only access to that unit's schemas, and data stewards who need to create and modify objects only within that unit's schemas. A central PLATFORM_ADMIN team must be able to manage grants across all business units without directly owning the business data objects. The company wants a hierarchical RBAC model that minimizes future grant maintenance as new schemas and tables are added. Which approach best meets these requirements?
- A
Create functional roles for each business unit (for example, FINANCE_ANALYST and FINANCE_STEWARD), grant object privileges on that unit's schemas and future objects to those roles, then grant those functional roles to higher-level business unit roles and grant the business unit roles to PLATFORM_ADMIN.
- B
Grant all schema and table privileges directly to individual users in each business unit, and give PLATFORM_ADMIN the ACCOUNTADMIN role so they can manage access centrally.
- C
Make PLATFORM_ADMIN the owner of all schemas and tables, then grant imported privileges from the database to analysts and stewards in each business unit.
- D
Create one global ANALYST role and one global STEWARD role for all business units, grant access to every business unit schema to both roles, and use warehouses to separate what each user can do.
Show answer and explanation
Correct answer: A
Explanation
In Snowflake, hierarchical RBAC is most effective when privileges are granted to lower-level access roles and then inherited through higher-level roles. This supports least privilege, simplifies administration, and avoids direct user grants. In this scenario, the correct design is to create business-unit-specific functional roles such as FINANCE_ANALYST and FINANCE_STEWARD, grant the required schema and object privileges to those roles, and use future grants where appropriate so that access automatically extends to new objects. Those roles can then be granted to higher-level business unit roles and, if needed for centralized governance, inherited by a PLATFORM_ADMIN role. This allows central administrators to manage role grants without becoming object owners. Snowflake documentation and best practices consistently recommend role-based privilege assignment, role hierarchies, and future grants to reduce operational overhead while maintaining clear separation of duties.
- A. Correct.
This is the best answer because it uses a hierarchical RBAC design with lower-level functional roles holding object privileges and higher-level roles aggregating access. Granting privileges on schemas and using future grants for new tables/views reduces ongoing maintenance as objects are added. Granting roles to a higher-level business unit role keeps access organized, and granting those roles upward to PLATFORM_ADMIN allows centralized access governance without requiring PLATFORM_ADMIN to own the data objects themselves. This aligns with Snowflake best practices of assigning privileges to roles rather than users and using role hierarchies to simplify administration.
- B. Incorrect.
This is incorrect because directly granting privileges to users does not scale and bypasses the advantages of RBAC inheritance. It increases maintenance and audit complexity, especially as users change roles or new objects are created. Giving PLATFORM_ADMIN the ACCOUNTADMIN role also violates least-privilege principles; ACCOUNTADMIN is highly privileged and should not be used for routine access management when a more targeted delegated model can be implemented.
- C. Incorrect.
This is incorrect because making PLATFORM_ADMIN the owner of all business data objects contradicts the requirement that the central team manage grants without directly owning the objects. Also, imported privileges are used for granting access to objects in a shared database, not as a general mechanism for internal schema/table privilege design across business units. This option mixes ownership with access administration in a way that is neither necessary nor aligned to the scenario.
- D. Incorrect.
This is incorrect because one global ANALYST role and one global STEWARD role across all business units would overgrant access. Analysts and stewards would receive access to schemas outside their own business unit, violating separation of duties and least privilege. Warehouses control compute usage, not data authorization boundaries, so they cannot be used to restrict what objects a role can access.