ARA-C01 Question 201
Single answerSnowflake Native App FrameworkA software company is packaging a Snowflake Native App that analyzes a consumer's sales data and exposes a Streamlit UI plus SQL objects for reporting. The provider must meet these requirements: (1) consumers must be able to install the app without directly exposing their raw tables to the provider, (2) the app must process consumer data inside the consumer account, and (3) the provider wants a controlled way to request access only to the specific consumer objects needed for the app. Which design should the architect choose?
- A
Require consumers to copy their source data into a database owned by the provider account, then let the app query that provider-managed database through shared objects.
- B
Use the Snowflake Native App Framework with application roles and references so the consumer can grant the app access to specific objects, while the app's code runs in the consumer account.
- C
Publish a standard data share from the consumer to the provider and have the provider host the Streamlit application externally, calling back into Snowflake for query execution.
- D
Create the app so it automatically assumes ACCOUNTADMIN in the consumer account during installation, allowing it to discover and query the required objects without explicit grants.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use the Snowflake Native App Framework with references and application roles. Native Apps are designed so providers can distribute application code through Snowflake while consumers install and run the app in their own accounts. This supports a common architecture goal: bring the application to the data instead of moving customer data to the provider. References are especially important when the app needs access to consumer-owned objects. They provide a controlled, explicit mechanism for the consumer to bind specific objects to the app, aligning with least-privilege access and clear consent. Application roles help expose and manage app functionality for consumer users. This pattern is consistent with Snowflake Native App Framework guidance on in-account execution, secure access to consumer objects, and provider-controlled packaging with consumer-governed permissions.
- A. Incorrect.
Incorrect. This violates the requirement to avoid directly exposing raw consumer tables to the provider and moves data out of the consumer-controlled execution boundary. A core value of the Snowflake Native App Framework is that application logic can run within the consumer's Snowflake account, reducing the need to centralize customer data in the provider account.
- B. Correct.
Correct. This is the intended architecture for this scenario. In the Snowflake Native App Framework, the app is installed in the consumer account and can process data there. References allow the provider to define required object bindings so the consumer explicitly grants access to specific objects such as tables, views, or warehouses, rather than exposing broad access. Application roles are used to control what consumers can do within the app.
- C. Incorrect.
Incorrect. A standard data share is the wrong direction for this requirement because it exposes data from the consumer to the provider-side solution model. It also does not align with the requirement that the app process data inside the consumer account. While external hosting can be used for some solutions, it is not the best fit when the goal is to keep both execution and governed data access inside the consumer's Snowflake environment.
- D. Incorrect.
Incorrect. Native Apps do not automatically assume ACCOUNTADMIN or bypass least-privilege controls. The framework is designed around explicit consumer approval, governed privileges, and object access patterns such as references. Assuming elevated account-wide administrative privileges would be a serious security anti-pattern and is not how Native Apps are installed or authorized.