ADA-C01 Question 23
Single answerDetermine the use cases for custom security rolesA Snowflake administrator is redesigning access control for a company with separate Data Engineering, BI Analyst, and Security Operations teams. The company wants to follow least-privilege principles and reduce dependence on broad system roles such as SYSADMIN and SECURITYADMIN for day-to-day work. Data engineers need to create and manage pipelines in a specific database, BI analysts only need read access to curated schemas, and the Security Operations team must manage user-role assignments without being able to modify data objects. Which approach best uses custom security roles to meet these requirements?
- A
Create custom functional roles such as DATA_ENGINEER_ROLE, BI_ANALYST_ROLE, and ACCESS_ADMIN_ROLE; grant object privileges needed for each job function to those roles; then assign the roles to users and, if needed, place them in a role hierarchy under higher-level administrative roles.
- B
Grant SYSADMIN to Data Engineering and BI Analyst users, then use warehouse-level resource monitors to prevent unauthorized access to databases and schemas.
- C
Use only the built-in PUBLIC role for BI analysts and grant SECURITYADMIN to the Security Operations team because built-in system roles are preferred over custom roles for operational simplicity.
- D
Assign all users the ACCOUNTADMIN role temporarily, and rely on future grants on schemas to ensure each team only sees the objects relevant to them.
Show answer and explanation
Correct answer: A
Explanation
Custom security roles are most useful when access needs differ by job function and when an organization wants to enforce least privilege and separation of duties. In this scenario, the company has distinct operational needs: engineers manage pipeline-related objects in a limited scope, analysts consume curated data, and security staff manage access without owning data workloads. Snowflake recommends using a role-based access control model with custom roles that reflect business functions, then granting those roles the minimum required privileges on securable objects. Built-in system roles such as ACCOUNTADMIN, SYSADMIN, and SECURITYADMIN are powerful and should be assigned sparingly. PUBLIC should also be used carefully because it is inherited broadly. A role hierarchy can be used to simplify administration, but the core design should still center on narrowly scoped custom roles. See Snowflake documentation on Access Control Overview, System-Defined Roles, Role Hierarchy and Privilege Grants, and best practices for least-privilege RBAC design.
- A. Correct.
Correct. This is the recommended pattern for custom security roles in Snowflake: create roles aligned to business functions or access patterns, grant only the required privileges on databases, schemas, tables, views, stages, pipes, tasks, and warehouses as needed, and then assign those roles to users. This supports least privilege, separation of duties, and scalable administration. The Security Operations team can use a custom role for managing grants to users and roles if it is delegated the necessary role-management privileges, instead of using broader data-access roles.
- B. Incorrect.
Incorrect. SYSADMIN is a powerful system role intended for creating and managing objects, not for broad assignment to end users who only need limited functional access. Resource monitors control credit consumption, not authorization to database objects. This option confuses cost governance with access control and violates least-privilege principles.
- C. Incorrect.
Incorrect. The PUBLIC role is granted to every user and role automatically, so it should not be used as the primary mechanism for granting business-sensitive read access. Granting SECURITYADMIN directly to the Security Operations team may allow broader security administration than required. Snowflake best practice is to use custom roles to match job duties and minimize assignment of powerful built-in system roles.
- D. Incorrect.
Incorrect. ACCOUNTADMIN is the most powerful role in Snowflake and should be tightly restricted. Assigning it broadly, even temporarily, is a major security risk and contrary to best practice. Future grants simplify privilege management on new objects, but they do not replace the need to define appropriate custom roles for different teams.