ARA-C01 Question 29
Single answerConfigure Role-Based Access Control (RBAC) hierarchyA company is redesigning its Snowflake access model after several audit findings. The goals are to: (1) minimize direct grants to users, (2) ensure analysts in the FINANCE department can query only curated finance reporting tables, (3) allow finance data engineers to create and manage objects in the FINANCE schema, and (4) simplify onboarding by assigning users to a small number of business roles. Which approach best implements an RBAC hierarchy that meets these requirements while following Snowflake best practices?
- A
Create access role FINANCE_REPORTING_R with SELECT on curated finance tables and functional role FINANCE_ANALYST that is granted FINANCE_REPORTING_R. Create functional role FINANCE_ENGINEER with CREATE TABLE, CREATE VIEW, and MODIFY privileges on the FINANCE schema plus USAGE on the database and schema. Grant these functional roles to users as needed, and avoid granting object privileges directly to users.
- B
Grant SELECT on curated finance tables directly to all finance analysts, and grant CREATE privileges on the FINANCE schema directly to finance engineers. Use SYSADMIN only for exceptional cases so the number of roles stays low.
- C
Create one role named FINANCE_ALL, grant it SELECT on curated finance tables and full schema-level management privileges, then grant FINANCE_ALL to both analysts and engineers to simplify administration.
- D
Grant ownership of the FINANCE schema to a FINANCE_ANALYST role so analysts can read reporting tables without additional grants. Create a separate FINANCE_ENGINEER role for engineers with no inherited roles to keep duties separated.
Show answer and explanation
Correct answer: A
Explanation
The best answer is Option 1 because it implements a layered RBAC hierarchy aligned with Snowflake best practices: grant privileges to roles, create higher-level functional or business roles that inherit lower-level access roles, and then assign users to those business roles. This approach supports least privilege, reduces direct user grants, and makes onboarding and audits easier. In Snowflake, users should generally receive access through roles rather than through direct object grants. Separating read-only access roles from object-management roles also prevents privilege creep. To enable object creation and management within a schema, the role needs appropriate privileges on the schema and USAGE on the parent database and schema context as applicable. Snowflake documentation on access control and role hierarchy emphasizes role-based privilege assignment, role inheritance, and minimizing unnecessary powerful privileges such as OWNERSHIP except where administrative control is required.
- A. Correct.
Correct. This design follows Snowflake RBAC best practices by separating object-access roles from business or functional roles and then assigning functional roles to users. FINANCE_REPORTING_R encapsulates read access to curated reporting objects, while FINANCE_ANALYST inherits only what analysts need. FINANCE_ENGINEER receives the schema-level privileges required to create and manage objects in the FINANCE schema, along with the necessary USAGE privileges on parent containers. This minimizes direct user grants, supports least privilege, and simplifies onboarding by assigning users to business-aligned roles rather than managing object grants per user.
- B. Incorrect.
Incorrect. Although this may work functionally, it violates the stated requirement to minimize direct grants to users and creates an access model that is harder to audit, maintain, and scale. Directly granting object privileges to individual users is a common anti-pattern in Snowflake because it increases administrative overhead and makes consistent access reviews difficult. The mention of SYSADMIN is also misleading because using a powerful system role does not solve the RBAC hierarchy problem.
- C. Incorrect.
Incorrect. This option simplifies administration at the cost of least privilege. Giving both analysts and engineers the same broad role means analysts receive schema management capabilities they do not need, which conflicts with the requirement that analysts should only query curated finance reporting tables. Combining read-only and object-creation privileges into a single role is a common misconception when designing RBAC, but Snowflake best practice is to model roles around distinct job functions and required access levels.
- D. Incorrect.
Incorrect. Ownership is not an appropriate mechanism for providing routine read access to analysts. In Snowflake, the OWNERSHIP privilege is powerful and transfers control of an object; assigning schema ownership to an analyst role would exceed the required permissions and create governance risk. Also, object access still requires the proper privileges, and ownership is not a substitute for a well-structured inherited role model. Keeping engineers in a separate role can be good, but the analyst role design here is fundamentally flawed.