A new analytics team needs a custom role that can create databases, warehouses, and schemas, and own the objects it builds. The administrator wants the role to inherit into the normal administrative hierarchy so that an existing senior operations role can manage everything the new team produces. Under which system-defined role should the new custom role be granted so it sits correctly in the standard hierarchy?
- AACCOUNTADMIN, because every custom role that creates objects must report to the top role so account-level settings stay consistent across the whole account
- BPUBLIC, because PUBLIC is automatically granted to every user and therefore guarantees the new role reaches the senior operations role through inheritance
- CSYSADMIN, because granting the custom role to SYSADMIN places it in the object-management branch so any role above SYSADMIN can manage the new team's objects Correct
- DSECURITYADMIN, because SECURITYADMIN manages object grants and so should sit directly above any role that creates and owns databases and warehouses
Why A is wrong: Granting custom roles directly under ACCOUNTADMIN concentrates excessive privilege at the top and is discouraged, so this breaks least privilege rather than following the standard pattern.
Why B is wrong: PUBLIC sits at the bottom of the hierarchy and is held by all users, so granting a privileged role under PUBLIC would expose object management to everyone instead of the senior role.
Why C is correct: SYSADMIN owns the recommended object-creation branch, so granting the custom role to SYSADMIN lets it create objects and lets higher roles manage them, which is the standard pattern.
Why D is wrong: SECURITYADMIN manages users, roles, and grants rather than the object-creation branch, so custom object-owning roles belong under SYSADMIN, not SECURITYADMIN.