SnowPro Advanced: Security Engineer Question 23
Single answerUser-defined custom roles (account, database, and application)A security engineer is designing access for a Snowflake Native App used by multiple business units. The app package includes application roles such as APP_READ_ONLY and APP_ADMIN to control access to objects inside the app. Separately, the account already uses custom account roles for warehouse usage and environment-wide governance, and one database contains database roles used to group schema-level privileges for shared reporting objects. The engineer must let analysts use the app's read-only features while preserving least privilege and keeping role boundaries clear. Which approach should the engineer use?
- A
Grant the APP_READ_ONLY application role directly to the analysts' account role, and let that account role inherit warehouse privileges separately.
- B
Grant the APP_READ_ONLY application role to individual users, because application roles cannot be assigned through account roles.
- C
Convert the APP_READ_ONLY application role into a database role so it can be granted to account roles in the same way as other custom roles.
- D
Grant the analysts' account role to the APP_READ_ONLY application role so the application role can inherit warehouse and governance privileges.
Show answer and explanation
Correct answer: A
Explanation
The key distinction is scope: account roles are the primary mechanism for assigning privileges across the account, including warehouses and many securable objects; database roles are limited to privileges within a specific database; and application roles are specific to Snowflake Native Apps and control access to app-contained objects and functionality. In a least-privilege design, keep application entitlements in application roles and grant those application roles to appropriate account roles used by end users. Then manage warehouse and other account-wide privileges separately through account roles. This follows Snowflake role-based access control best practices and preserves clear role boundaries instead of misusing one role type to replace another. Relevant Snowflake documentation covers account roles, database roles, and application roles, including the supported grant relationships and their intended scopes.
- A. Correct.
Correct. Application roles are designed to control access to objects within a Snowflake Native App, and they can be granted to account roles. This lets the organization keep application-specific entitlements inside the app while continuing to use account roles for broader privileges such as warehouse usage, monitoring, or other account-level access. This is the cleanest least-privilege design because it preserves separation between application roles and account roles instead of trying to merge them.
- B. Incorrect.
Incorrect. This reflects a common misconception. Application roles are not limited to direct user assignment. In practice, granting an application role to an account role is the preferred pattern because users typically activate account roles, and role-based administration scales better than assigning access one user at a time.
- C. Incorrect.
Incorrect. Database roles and application roles serve different scopes and purposes. A database role applies within a database, while an application role applies within a Snowflake Native App. You do not convert an application role into a database role to make it assignable. Snowflake supports granting application roles to account roles directly, so conversion is unnecessary and would break the intended security model.
- D. Incorrect.
Incorrect. The grant direction is wrong. An application role can be granted to an account role, not the reverse, when the goal is to allow account principals to use app functionality. Also, application roles should not be used as containers for broad account-level privileges like warehouse access. Those remain the responsibility of account roles.