COF-C03 Question 349
Single answerNative AppsA software company is preparing to distribute a Snowflake Native App to multiple customers through the Snowflake Marketplace. The app needs to let each customer analyze data stored in the customer's own account while keeping the provider's application code packaged and centrally managed. The provider also wants customers to explicitly approve any access to their internal objects before the app can use them. Which approach should the provider use?
- A
Package the app as a Snowflake Native App and use references so consumers can grant the app access to specific objects in their account
- B
Create a database share from the provider account and instruct consumers to run all application logic directly against the shared database
- C
Publish a listing that copies all consumer data into the provider account so the app can process it centrally
- D
Deploy the app as a standard external application outside Snowflake and use SnowSQL connections to access consumer objects without any explicit approval flow
Show answer and explanation
Correct answer: A
Explanation
The best solution is to distribute the solution as a Snowflake Native App and use references for consumer-owned objects. Native Apps allow providers to package application code and metadata for installation in consumer accounts, which supports centralized distribution through the Snowflake Marketplace while keeping execution close to the consumer's data. When the app needs access to objects owned by the consumer, Snowflake uses references so the consumer can explicitly authorize which objects the app may use. This is the key design pattern for scenarios where the provider supplies the app but the data remains under the consumer's control. By contrast, Secure Data Sharing is primarily for sharing provider-owned data, not packaging an application. Best-practice guidance in Snowflake documentation for the Native App Framework emphasizes packaging apps for distribution and using references to enable approved access to consumer resources.
- A. Correct.
Correct. Snowflake Native Apps are designed so providers can package application logic and distribute it to consumer accounts. When the app needs to interact with consumer-owned objects, the provider can use references, which allow the consumer to explicitly bind and authorize access to specific tables, views, warehouses, or other supported objects. This matches the requirement to keep code packaged by the provider while letting each customer analyze data that remains in the customer's own account.
- B. Incorrect.
Incorrect. A database share is useful for securely sharing provider-owned data with consumers, but it does not package application logic as a Native App experience. It also does not satisfy the requirement for consumers to approve app access to their own internal objects through the Native App authorization model.
- C. Incorrect.
Incorrect. A core value of Snowflake Native Apps is that consumer data can stay in the consumer account. Requiring all consumer data to be copied into the provider account is not the intended pattern and would conflict with the scenario's requirement to analyze data stored in each customer's own account.
- D. Incorrect.
Incorrect. A standard external application using SnowSQL is not a Snowflake Native App distribution model and would not provide the built-in installation, packaging, governance, and consumer approval mechanisms expected for Marketplace-distributed Native Apps. It also bypasses the explicit object reference pattern used within Native Apps.