ARA-C01 Question 34
Single answerDatabase rolesA global retail company wants to decentralize object access management for a single shared database named ANALYTICS. The central security team should continue managing account-level access, but each data domain owner should manage privileges only within the ANALYTICS database. The company also wants a design that can be replicated cleanly across environments and minimizes direct grants to account roles. Which approach best meets these requirements?
- A
Create database roles inside ANALYTICS for each data domain, grant object privileges in ANALYTICS to those database roles, and then grant the database roles to account roles assigned to users.
- B
Create account roles for each data domain, grant all schema and object privileges in ANALYTICS directly to those account roles, and avoid database roles because they cannot be used with users.
- C
Grant OWNERSHIP on the ANALYTICS database to each domain owner account role so they can manage privileges for their own schemas without needing additional role design.
- D
Create application roles for each data domain in ANALYTICS, grant object privileges to those application roles, and then grant the application roles directly to users.
- E
Use future grants only at the account role level for all objects in ANALYTICS, because future grants cannot be assigned to database roles.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use database roles for database-scoped privilege management and then bridge those privileges to users through account roles. In Snowflake, database roles are intended to manage privileges on securable objects within a single database. They cannot be granted directly to users; instead, they are granted to account roles, which are then granted to users. This enables a layered model: database owners or domain owners manage object access inside the database, while the central security team retains control over account roles and user assignments. This is aligned with least-privilege and separation-of-duties principles and supports repeatable deployment across environments. Relevant Snowflake documentation includes the sections on access control, database roles, and role hierarchies, which describe how database roles are scoped to a database and can be granted to account roles for end-user access.
- A. Correct.
Correct. Database roles are designed to manage privileges on objects within a single database. This makes them well suited for delegating database-scoped access management to domain owners while keeping account-level user and role administration centralized. A common best practice is to grant privileges on schemas, tables, views, and other objects in ANALYTICS to database roles, then grant those database roles to account roles. Users are assigned account roles, not database roles directly, so this pattern cleanly separates database-level authorization from account-level identity and role assignment. It is also easier to reproduce consistently across DEV, TEST, and PROD because the privilege model is encapsulated within each database.
- B. Incorrect.
Incorrect. Although account roles can hold privileges on objects in any database, using only account roles does not meet the stated goal of decentralizing management within a single database while minimizing direct grants to account roles. The option also includes a misleading rationale: database roles are not granted directly to users, but they are absolutely usable by granting them to account roles, which are then granted to users. That indirection is the intended design.
- C. Incorrect.
Incorrect. Granting OWNERSHIP on the entire database to multiple domain owner account roles is not an appropriate least-privilege design and would over-delegate authority. OWNERSHIP is a powerful privilege that transfers control of the object and is broader than needed for managing access within selected schemas or objects. This would increase operational risk and does not align with the requirement to manage privileges only within appropriate parts of the database.
- D. Incorrect.
Incorrect. Application roles are associated with Snowflake Native Apps, not as a general replacement for database roles in standard database access control. They are not the correct mechanism for organizing privileges for internal data domain management in a regular shared database. The suggestion to grant them directly to users also reflects the wrong role model for this scenario.
- E. Incorrect.
Incorrect. Future grants can be granted to database roles as well as account roles, provided the privileges and object types support future grants. Therefore the statement that future grants cannot be assigned to database roles is factually wrong. In addition, using only account-role-level future grants does not address the requirement to encapsulate database-specific privilege management within ANALYTICS.