ADA-C01 Question 24
Single answerDetermine the use cases for custom security rolesA healthcare company uses Snowflake to support separate Data Engineering, BI, and Security Operations teams. The account has grown quickly, and administrators have been granting built-in roles such as SYSADMIN and SECURITYADMIN directly to individual users so teams can perform their work. During an audit, the company finds that many users have more privileges than required, and privilege reviews are difficult because access is assigned inconsistently. The company wants to implement a least-privilege model that simplifies audits and allows access to be granted based on job responsibilities. Which approach is the BEST use case for custom security roles in this situation?
- A
Create custom functional roles for each job function, grant only the required object privileges to those roles, and then grant the custom roles to users or higher-level roles as needed
- B
Grant ACCOUNTADMIN to team leads only, and require team leads to perform all privileged tasks on behalf of their teams
- C
Continue assigning built-in system roles directly to users, but document each exception in an internal spreadsheet for audit purposes
- D
Replace all custom access patterns with database roles only, and grant database roles directly to users for both database and account-level administration
Show answer and explanation
Correct answer: A
Explanation
The best answer is to create custom functional roles that align with business responsibilities and grant only the privileges required for each job function. In Snowflake, custom roles are commonly used to implement role-based access control in a scalable, auditable way. This is especially important when organizations outgrow direct assignment of broad built-in roles to end users. Best practice is to minimize assignment of powerful system-defined roles, use role hierarchies, and grant privileges to roles rather than users whenever possible. Snowflake documentation distinguishes account roles from database roles and emphasizes role-based privilege management to support least privilege and easier administration.
- A. Correct.
Correct. This is the primary practical use case for custom security roles in Snowflake: mapping privileges to business functions instead of assigning broad system roles directly to users. Custom roles support least privilege, simplify onboarding and offboarding, improve auditability, and make privilege reviews easier because access is standardized by job responsibility. These roles can then be granted to users or arranged in a role hierarchy.
- B. Incorrect.
Incorrect. Restricting ACCOUNTADMIN to fewer users is good in principle, but using team leads as proxies for all privileged work does not solve the underlying access design problem. It creates operational bottlenecks and still relies on an excessively powerful built-in role instead of defining narrower custom roles aligned to responsibilities.
- C. Incorrect.
Incorrect. Documentation does not compensate for poor role design. Granting built-in roles such as SYSADMIN or SECURITYADMIN directly to users often results in overprivileged access and inconsistent assignments. The audit concern here is about enforcing least privilege through role-based access control, not merely tracking exceptions manually.
- D. Incorrect.
Incorrect. Database roles are useful for managing privileges on database objects within a database, but they are not a substitute for account roles in all cases. Account-level administrative privileges, such as user, warehouse, and integration management, require account roles. Granting database roles directly to users also misses the broader role hierarchy strategy typically used for enterprise access management.