ARA-C01 Question 33
Single answerDatabase rolesA global enterprise is redesigning access controls for a shared Snowflake account used by multiple business units. The security architect wants each application team to manage object privileges only within its own database, without requiring ACCOUNTADMIN or SECURITYADMIN for day-to-day administration. The architect also wants the solution to scale as new schemas and objects are added to each database. Which approach best meets these requirements while maintaining least privilege?
- A
Create a database role in each database, grant the required schema and object privileges to that database role, grant the database role to an account role used by the application team, and grant the database role OWNERSHIP on future schemas and objects where appropriate.
- B
Create account roles for each application team, grant all required privileges directly to those account roles, and avoid database roles because they cannot be assigned to users through role hierarchy.
- C
Grant SECURITYADMIN to each application team lead so they can manage grants within their database, and use future grants to reduce operational effort.
- D
Create a database role in each database, grant object privileges to the database role, grant that database role to an account role for the application team, and use future grants on schemas and objects so new objects inherit the intended access model.
Show answer and explanation
Correct answer: D
Explanation
The best answer is to use database roles for database-scoped privilege management and then bridge them into the broader access model by granting them to account roles. In Snowflake, database roles are intended to simplify management of privileges on securable objects within a database. They cannot be granted directly to users, but they can be granted to account roles, which are then assigned to users or other account roles. This makes database roles well suited for decentralized administration patterns where teams manage access inside their own database boundaries.
To satisfy the requirement that the design scales as new schemas and objects are added, future grants should be used where appropriate. Future grants help ensure that newly created schemas, tables, views, and similar objects automatically receive the intended privileges. This avoids repeated manual grant operations and supports consistent access control over time.
The key architectural principle is least privilege: avoid assigning powerful system roles such as SECURITYADMIN when database-level delegation is sufficient. Also avoid overusing OWNERSHIP as a substitute for a proper privilege model. Snowflake documentation on access control, role hierarchy, and database roles supports this pattern: database roles for database-local privileges, account roles for user assignment and enterprise-wide role composition, and future grants for scalable privilege administration.
- A. Incorrect.
Incorrect. This starts in the right direction by using database roles and granting them to account roles, which is the recommended pattern for delegating database-scoped access. However, granting a database role OWNERSHIP on future schemas and objects is not the appropriate general solution for routine access delegation. OWNERSHIP is a powerful privilege and should be granted carefully because it confers full control and affects grant management. For scalable access to newly created objects, future grants are the intended mechanism rather than broadly assigning OWNERSHIP.
- B. Incorrect.
Incorrect. Account roles can certainly be used, but the claim about database roles is false and reflects a common misconception. Database roles cannot be granted directly to users, but they can be granted to account roles, and users can then be assigned the account roles. This is exactly how database roles are typically used to encapsulate database-specific privileges while integrating with the account-level role hierarchy.
- C. Incorrect.
Incorrect. Granting SECURITYADMIN to application team leads violates least-privilege principles and gives them broad account-level authority beyond a single database. Even if future grants reduce effort, SECURITYADMIN is intended for centralized security administration, not for routine delegated management within one database. The scenario specifically requires avoiding powerful system roles for day-to-day administration.
- D. Correct.
Correct. This approach aligns with Snowflake best practices for database roles. Database roles are designed to manage privileges on objects within a single database. By granting object privileges to a database role and then granting that database role to an account role, the organization can delegate database-scoped access cleanly without exposing broader account-level administrative privileges. Using future grants on schemas and objects allows the model to scale as new objects are created, reducing ongoing administrative overhead while preserving least privilege.