SnowPro Advanced: Security Engineer Question 24
Single answerUser-defined custom roles (account, database, and application)A security engineer is designing access for a Snowflake Native App used by multiple internal teams. The company wants to minimize account-level privilege exposure while allowing the app to manage objects inside its own application scope. At the same time, a separate analytics team needs read-only access to curated tables in one database without receiving broad account privileges. Which approach best meets these requirements using user-defined custom roles?
- A
Create an application role for privileges used within the Native App, and create a separate database role for read-only access to curated tables; then grant the database role to an account role assigned to the analytics team.
- B
Create one account role that contains all privileges for both the Native App and the analytics team, because account roles can be granted everywhere and simplify administration.
- C
Create a database role for the Native App's internal privileges and grant it directly to app consumers; create an application role only if warehouse usage is required.
- D
Create only database roles for both use cases, because database roles can replace account roles and application roles for least-privilege designs.
Show answer and explanation
Correct answer: A
Explanation
The best design is to use each custom role type for its intended scope: account roles for user/session-level role assignment and aggregation, database roles for privileges on securable objects within a database, and application roles for privileges within a Snowflake Native App. In this scenario, the Native App should use an application role to avoid unnecessary account-level privilege exposure. The analytics team's read-only access should be implemented with a database role containing SELECT/USAGE as needed on the curated database objects, then granted to an account role assigned to the team. This approach supports least privilege, cleaner administration, and clearer separation of duties. Snowflake documentation distinguishes these role types by scope and inheritance patterns: account roles are account-level, database roles are scoped to a database and can be granted to account roles, and application roles are specific to application authorization within Native Apps.
- A. Correct.
Correct. Application roles are designed for privileges exposed and managed within a Snowflake Native App's application context. They are the right mechanism for app-scoped access rather than broad account-level roles. For the analytics team, a database role is appropriate for read-only privileges on objects within a specific database, such as schemas and tables. Because end users are typically assigned account roles, the database role should be granted to an account role, which is then granted to users. This follows least-privilege design and aligns with Snowflake's separation of account roles, database roles, and application roles.
- B. Incorrect.
Incorrect. Although account roles are central for user assignment and can aggregate other roles, putting both Native App privileges and analytics database access into one account role increases privilege scope and weakens separation of duties. It also ignores the purpose of application roles, which are intended for app-specific access patterns. This option reflects the common misconception that account roles should directly hold every privilege in all scenarios.
- C. Incorrect.
Incorrect. Database roles are scoped to a database and are not the primary mechanism for privileges inside a Snowflake Native App. Application roles exist specifically for app-level privilege management. In addition, the statement about using application roles only when warehouse usage is required is incorrect; warehouse privileges are account-level concerns and do not define when application roles should be used. This distractor mixes role scopes incorrectly.
- D. Incorrect.
Incorrect. Database roles are useful for granting privileges on objects in a single database, but they do not replace account roles or application roles. Users are not assigned database roles directly in the same way they are assigned account roles; database roles are typically granted to account roles. Likewise, application roles are distinct and are used in application contexts. This option represents an overgeneralization of database roles.