SnowPro Advanced: Security Engineer Question 383
Single answerDomain 5.0: Securing Snowflake Services and Features for AI/ML and Applications (12%)A financial services company is deploying a customer-facing application using Snowflake Native App Framework. The provider wants the app to process sensitive account data that remains in each consumer's Snowflake account, while also allowing the app to create required application objects during installation. The security team requires that the app follow least-privilege principles and that consumers explicitly approve any access to their data. Which approach should the provider implement to meet these requirements?
- A
Package the app so it requests application roles and references, allowing consumers to grant access to specific objects the app needs at install or setup time.
- B
Grant the app OWNER rights on the consumer's database so the setup script can automatically discover and access all required tables.
- C
Require consumers to share their data to the provider account first, then have the app query the shared data from the provider side to simplify permissions.
- D
Use a setup script that runs with unrestricted ACCOUNTADMIN privileges in the consumer account so the app can create objects and read data without additional grants.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use application roles and references in the Snowflake Native App Framework so consumers explicitly approve access to only the specific data objects the app requires. This is the recommended pattern for secure app deployment because it preserves the consumer's control over sensitive data, keeps data in the consumer account, and enforces least privilege. In practice, providers package the app with setup logic for application objects and define references for external objects the consumer must bind during installation or configuration. Broad privileges such as OWNER on consumer databases or ACCOUNTADMIN-like access are inconsistent with Snowflake security best practices. Likewise, copying or sharing sensitive data back to the provider account is unnecessary when the Native App can execute within the consumer environment under consumer-approved permissions. This reflects Snowflake guidance for Native Apps: use consumer-granted access, application roles, and references to securely access consumer resources while minimizing privilege.
- A. Correct.
Correct. In the Native App Framework, providers should use application roles to expose app functionality and references so consumers can explicitly bind the app to specific objects in their own account. This supports least privilege because the consumer grants only the minimum required access to named objects rather than broad account-level permissions. It also aligns with the requirement that sensitive data remain in the consumer account while the app still creates its own application objects during installation.
- B. Incorrect.
Incorrect. Granting OWNER rights on a consumer database is far broader than necessary and violates least-privilege principles. Native Apps are designed to operate with consumer-approved privileges and object references, not blanket ownership over consumer data assets. A candidate might choose this because it seems operationally simple, but it creates unnecessary risk and is not the recommended security model.
- C. Incorrect.
Incorrect. Sharing data back to the provider account changes the trust boundary and contradicts the stated requirement that sensitive account data remain in the consumer's Snowflake account. While data sharing is a valid Snowflake capability, it is not the right design here because it increases data exposure and removes the consumer-controlled access pattern expected for secure Native App deployments.
- D. Incorrect.
Incorrect. Native Apps do not rely on unrestricted ACCOUNTADMIN execution in the consumer account as a normal security model. This would violate least privilege and consumer approval requirements. A setup script can create app-related objects within the app's allowed context, but access to consumer data must still be explicitly authorized through the mechanisms supported by the framework, such as references and granted privileges.