COF-C03 Question 350
Single answerNative AppsA software company is packaging a Snowflake Native App to distribute through the Snowflake Marketplace. The app needs to analyze customer data that remains in each consumer account, and the provider wants the installation process to require the least amount of manual setup by the consumer while still following Native App best practices. Which approach should the provider use?
- A
Package the application logic in the Native App and request access to consumer data through application roles and setup scripts defined in the app package
- B
Replicate all consumer data into the provider account before installation so the app can query it centrally without requiring any permissions in the consumer account
- C
Create a shared database from the provider account and require consumers to copy their local tables into that shared database for the app to use
- D
Deploy the app as a standard database share because Native Apps cannot include setup logic or objects that run inside the consumer account
Show answer and explanation
Correct answer: A
Explanation
The best answer is Option 1 because Snowflake Native Apps are intended to let providers distribute application logic that runs within the consumer's Snowflake environment, allowing the app to work with consumer data in place. This reduces data movement and supports security and governance controls. In practice, providers create an application package, define versioned setup content, and use application roles and object references/required privileges so consumers can grant the app only the access it needs. Options 2 and 3 are attractive distractors because they resemble older data-centralization patterns, but they are not aligned with the Native App Framework's primary design. Option 4 confuses secure data sharing with Native Apps; while both are Snowflake distribution mechanisms, Native Apps support installable application code and setup within the consumer account. See Snowflake documentation on the Native App Framework, application packages, application roles, and consumer-granted access to objects.
- A. Correct.
Correct. Snowflake Native Apps are designed so application code and objects can be installed into the consumer account and operate on data that stays in the consumer's environment. Providers can define setup scripts, application roles, and references/privilege requests so consumers can grant the app access to required objects with minimal manual work. This aligns with the Native App Framework goal of running the app in the customer's Snowflake account while preserving data locality and governance.
- B. Incorrect.
Incorrect. A core value of Snowflake Native Apps is that consumer data can remain in the consumer's Snowflake account. Requiring replication of all customer data to the provider account is not the recommended Native App model and introduces unnecessary data movement, governance concerns, and operational overhead.
- C. Incorrect.
Incorrect. A provider's shared database is used to share provider-owned data to consumers, not as a location where each consumer copies their own local data for app processing. This option also defeats the purpose of a Native App by increasing manual setup and requiring data duplication.
- D. Incorrect.
Incorrect. Native Apps are more than standard shares. They can include application packages, setup scripts, Streamlit apps, stored procedures, and other app components that are installed and run in the consumer account. Saying Native Apps cannot include setup logic is a misconception.