ARA-C01 Question 37
Single answerFunctional roles compared to access rolesA global retailer is redesigning Snowflake RBAC after several audit findings. Today, analysts are granted object privileges directly through team-specific roles such as SALES_DB_RW and FINANCE_WH. As employees move between projects, administrators frequently add and remove these roles from users, causing role sprawl and inconsistent access reviews. The security architect proposes separating job-function roles from data-access roles so that user assignments reflect business responsibilities while object privileges remain modular. Which approach best meets this requirement while aligning with Snowflake best practices?
- A
Create functional roles such as ANALYST and DATA_ENGINEER, assign users to those roles, and grant access roles such as SALES_DATA_RO and ETL_WH_USG to the functional roles.
- B
Grant all required database, schema, table, and warehouse privileges directly to users, then use functional roles only for query tagging and session settings.
- C
Create one role per user job title, grant all object privileges directly to that role, and avoid role hierarchies so audits can review each role independently.
- D
Assign access roles directly to users and reserve functional roles only for ownership of databases and warehouses.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to separate functional roles from access roles. In Snowflake, roles can be granted to other roles, enabling a hierarchy where functional roles model business responsibilities and access roles contain the actual privileges on databases, schemas, tables, views, warehouses, and other securable objects. This pattern improves manageability, supports least privilege, and reduces role sprawl because user membership changes occur at the functional layer while underlying access bundles remain reusable. It also simplifies audits because reviewers can validate whether a user should have a given business role and then separately validate what each access role permits. Snowflake documentation and best-practice guidance for access control emphasize using role hierarchies and granting privileges to roles rather than directly to users.
- A. Correct.
Correct. This is the recommended separation-of-duties design in Snowflake RBAC: functional roles represent who the user is in the organization, while access roles encapsulate privileges to data objects or compute resources. Users are assigned functional roles, and those functional roles inherit access roles. This reduces churn when users change responsibilities, improves reviewability, and promotes reusable privilege bundles.
- B. Incorrect.
Incorrect. Granting privileges directly to users is contrary to RBAC best practices in Snowflake and makes access governance harder to scale. Functional roles are not intended merely for session behavior; they are used to model business functions and can inherit access roles that hold object privileges.
- C. Incorrect.
Incorrect. Although role-per-job-title may sound organized, granting all object privileges directly to those roles tightly couples business function and resource access. This increases duplication and makes privilege management less modular. Snowflake role hierarchies are specifically useful for composing reusable access patterns and simplifying administration.
- D. Incorrect.
Incorrect. Assigning access roles directly to users does not address the stated governance problem because users would still accumulate many object-specific roles over time. Functional roles are not primarily meant to own objects; ownership is usually handled carefully through administrative or object-owner roles. The key pattern is assigning users to functional roles and granting access roles to those functional roles.