ADA-C01 Question 21
Single answerDetermine the use cases for, and hierarchy of, system-defined rolesA Snowflake account is being restructured to better separate operational duties. The security team wants one custom role, SECURITY_OPS, to be able to do all of the following without granting ACCOUNTADMIN directly: create and manage users and roles, view account-level usage and object metadata needed for audits, and retain the ability to grant those capabilities onward to lower-level custom roles. Which system-defined role should be granted to SECURITY_OPS to best meet these requirements while following Snowflake's intended role hierarchy?
- A
Grant USERADMIN to SECURITY_OPS
- B
Grant SECURITYADMIN to SECURITY_OPS
- C
Grant SYSADMIN to SECURITY_OPS
- D
Grant ACCOUNTADMIN to SECURITY_OPS
Show answer and explanation
Correct answer: B
Explanation
Snowflake's system-defined roles are hierarchical, and understanding their intended use is critical for least-privilege administration. In the standard hierarchy, higher roles inherit privileges from lower roles. USERADMIN is intended for user and role management. SECURITYADMIN is intended for security administration and inherits USERADMIN, making it the right built-in role when a custom role needs to manage users, roles, and grants without elevating all the way to ACCOUNTADMIN. SYSADMIN is primarily for object-level administration such as warehouses, databases, schemas, and other account objects, not as the main role for identity and access administration. ACCOUNTADMIN inherits major administrative roles and should be tightly controlled and used sparingly. This aligns with Snowflake documentation and best practices around system-defined roles, role hierarchy, and separation of duties.
- A. Incorrect.
Incorrect. USERADMIN is focused on creating and managing users and roles, but it does not sit high enough in the system-defined hierarchy to cover the broader security-administration use case described. In particular, the scenario requires a role that can manage security objects and pass those capabilities down appropriately through role grants in line with Snowflake's intended model. USERADMIN alone is too narrow for a consolidated security-operations role.
- B. Correct.
Correct. SECURITYADMIN is the system-defined role intended for security administration. It inherits the capabilities of USERADMIN and is designed to manage grants and role assignments across the account. Because higher roles inherit privileges from lower roles in the system role hierarchy, SECURITYADMIN includes USERADMIN capabilities and is the appropriate role to grant to a custom security-focused role when you want to avoid using ACCOUNTADMIN. It also aligns with the best practice of separating security administration from broader account administration.
- C. Incorrect.
Incorrect. SYSADMIN is intended primarily for creating and managing warehouses, databases, and other objects used in day-to-day platform and object administration. It is not the best fit for managing users, roles, and grants as the primary responsibility. A common misconception is that SYSADMIN is the general-purpose admin role for everything below ACCOUNTADMIN, but Snowflake separates object administration and security administration into different system-defined roles.
- D. Incorrect.
Incorrect. ACCOUNTADMIN would technically satisfy the requirements because it is the highest-level system-defined role and inherits from lower administrative roles, but the scenario explicitly states that ACCOUNTADMIN should not be granted directly. In practice, Snowflake recommends limiting ACCOUNTADMIN usage because it combines broad account, security, object, and billing-related administrative power, making it inappropriate for routine delegation when a narrower built-in role meets the need.