ADA-C01 Question 22
Single answerDetermine the use cases for, and hierarchy of, system-defined rolesA Snowflake account is being prepared for production. The security team wants to follow least-privilege and keep duties separated. They have asked for the following:
- create and manage users, roles, and network policies,
- create warehouses and resource monitors,
- create databases and shares for data distribution,
- avoid using ACCOUNTADMIN for routine administration.
Which combination of system-defined roles should be granted to an administrative user so the user can perform all requested tasks while aligning with Snowflake best practices?
- A
Grant only ACCOUNTADMIN, because it inherits the capabilities of the other system-defined administrative roles and is the standard role for all account administration tasks.
- B
Grant SECURITYADMIN, SYSADMIN, and USERADMIN, because together they cover security administration, object administration, and user/role management without requiring routine use of ACCOUNTADMIN.
- C
Grant ORGADMIN and SECURITYADMIN, because ORGADMIN can manage account-level objects such as warehouses, databases, and shares across the organization, while SECURITYADMIN handles users and roles.
- D
Grant USERADMIN and PUBLIC, because USERADMIN can create users and roles, and PUBLIC provides inherited access needed to create warehouses, databases, and shares.
Show answer and explanation
Correct answer: B
Explanation
Snowflake system-defined roles have distinct use cases and a hierarchy that supports separation of duties. USERADMIN is focused on users and roles. SECURITYADMIN is focused on security operations and can manage grants and certain security policies. SYSADMIN is the recommended owner of account objects and is the primary role for creating and managing warehouses, databases, and shares. ACCOUNTADMIN sits at the top of the account-level administrative hierarchy and inherits SYSADMIN and SECURITYADMIN, but Snowflake recommends restricting its use to limited, high-level administrative tasks rather than routine operations. ORGADMIN is separate and intended for organization-level management, not day-to-day administration within an account. This question tests the practical application of assigning the right combination of system-defined roles instead of defaulting to the most powerful role. See Snowflake documentation on access control, system-defined roles, and role hierarchy for the recommended responsibilities of USERADMIN, SECURITYADMIN, SYSADMIN, ACCOUNTADMIN, and ORGADMIN.
- A. Incorrect.
Incorrect. ACCOUNTADMIN is the most powerful system-defined role and inherits privileges from SYSADMIN and SECURITYADMIN. Although it could perform these tasks, Snowflake best practice is to limit ACCOUNTADMIN to a small number of users and avoid using it for routine operational administration. The scenario explicitly asks to avoid ACCOUNTADMIN for day-to-day tasks.
- B. Correct.
Correct. USERADMIN is intended for creating and managing users and roles. SECURITYADMIN manages security-related functions such as grants and can manage network policies. SYSADMIN is responsible for creating and managing most account objects, including warehouses, databases, and shares, and also has the role hierarchy needed for object administration. This combination satisfies the requested duties while avoiding routine use of ACCOUNTADMIN.
- C. Incorrect.
Incorrect. ORGADMIN is for organization-level administration, such as managing accounts in an organization, not for routine object administration inside a specific account. It does not replace SYSADMIN for creating warehouses, databases, or shares within an account. SECURITYADMIN alone also does not cover the full set of requested object-creation tasks.
- D. Incorrect.
Incorrect. USERADMIN can create and manage users and roles, but it does not provide the broad object-creation capabilities needed for warehouses, databases, resource monitors, and shares. PUBLIC is a pseudo-role granted to all users and roles, but it does not provide administrative capabilities for these tasks. This option reflects a common misconception that PUBLIC can be used to bridge missing admin privileges.