SnowPro Advanced: Security Engineer Question 22
Single answerSNOWFLAKE application rolesA data provider is publishing a Snowflake Native App that includes a Streamlit UI and several secure views over shared application data. The provider wants consumers to assign access in a least-privilege manner: some consumer users should only be able to use the app's read-only analytics features, while a smaller group should be able to run administrative functions exposed by the app. During testing, the provider notices that granting a normal account role in the consumer account does not correctly control access to app objects. Which approach should the provider implement to meet this requirement?
- A
Create multiple application roles inside the Native App, grant app object privileges to those application roles, and have the consumer grant the appropriate application roles to account roles in their account.
- B
Create database roles in the consumer account for read-only and admin users, and have the app automatically inherit those privileges when installed.
- C
Grant privileges on the app's secure views and Streamlit objects directly to the PUBLIC role in the consumer account, then restrict administrative features in the application code.
- D
Create system roles inside the application package and grant them directly to consumer users so the app can manage least-privilege access without account role mapping.
Show answer and explanation
Correct answer: A
Explanation
The correct design for Snowflake Native Apps is to use application roles as the app-specific privilege boundary. Providers create application roles within the app and grant object privileges, such as access to app-owned views, Streamlit components, or procedures, to those roles. Consumers then grant those application roles to account roles in their own account, allowing them to align app access with existing enterprise role structures. This supports least privilege and separation of duties. Using PUBLIC or relying only on application-side checks is weaker from a security perspective. Likewise, database roles and custom 'system roles' are not the intended mechanism for privilege delegation inside Native Apps. This aligns with Snowflake documentation on Native App Framework security and application roles, which emphasizes application roles for managing access to objects in an installed app.
- A. Correct.
Correct. Snowflake Native Apps use application roles to expose privileges on objects within the installed app to consumers. The provider defines application roles in the app, grants the necessary privileges on app objects to those application roles, and the consumer then grants the application roles to account roles in the consumer account. This is the intended least-privilege model for controlling access to app functionality such as read-only versus administrative capabilities.
- B. Incorrect.
Incorrect. Database roles are not the mechanism used to expose privileges for objects contained within a Snowflake Native App installation. A common misconception is that database roles can be substituted anywhere role-based access is needed. For Native Apps, application roles are specifically designed for this purpose. Consumer account roles can receive application roles, but the provider should not rely on consumer-created database roles as the app's privilege boundary.
- C. Incorrect.
Incorrect. Granting access broadly to PUBLIC violates least-privilege principles and shifts security enforcement into application logic, which is not a best practice when Snowflake provides native privilege controls. Snowflake security should be enforced through grants wherever possible, rather than depending on UI or code checks alone to prevent unauthorized administrative actions.
- D. Incorrect.
Incorrect. Snowflake does not support creating custom system roles inside an application package and assigning them directly to users in a consumer account. System roles are account-level constructs managed by Snowflake and the account administrator. In the Native App model, the provider defines application roles, and consumers map those to their own account roles.