ARA-C01 Question 202
Single answerSnowflake Native App FrameworkA software company is packaging a Snowflake Native App that analyzes a consumer's account data and stores derived metrics in objects created inside the consumer's account. The app also needs to include a small set of provider-owned reference tables that are updated weekly and must be available to every installed app instance without copying them into each consumer account. The provider wants to minimize data duplication, allow weekly updates to become visible to installed apps, and keep consumers from directly modifying the provider-owned reference data. Which design should the architect choose?
- A
Create the reference tables as shared content and expose them to the app through the package so installed app instances can read provider-owned data while storing consumer-specific derived data in application objects within the consumer account.
- B
Replicate the provider reference tables into each consumer account during installation by using setup scripts so the app can query them locally and consumers can manage access with their own roles.
- C
Store the reference tables in an external stage and have the app load them into temporary tables every time a consumer opens the app, because Native Apps cannot access provider-owned database objects after installation.
- D
Place the reference tables in a database created by the app inside each consumer account and use application roles to prevent consumers from modifying the data, since application roles can secure copied provider data more effectively than shared content.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake Native App Framework, a key architectural choice is deciding what remains provider-owned versus what is created inside the consumer account. When the provider must centrally manage common datasets such as reference tables and publish updates that should be available to all installed app instances, shared content in the application package is the recommended pattern. This allows the app to query provider-owned data without physically copying it into each consumer account. By contrast, consumer-specific outputs, derived metrics, and operational state are commonly stored in application objects created in the consumer account during installation or upgrade.
This pattern aligns with Snowflake Native App Framework guidance around application packages, shared content, setup scripts, and application roles. Shared content is intended for provider-owned objects that consumers can use through the app, while application roles govern access within the installed app. The main architectural benefit here is separation of concerns: centrally governed, reusable provider data remains shared; tenant-specific data lives in the consumer account. That delivers lower duplication, easier updates, and better maintainability.
- A. Correct.
Correct. In the Snowflake Native App Framework, providers can include shared content in the application package so consumers' installed app instances can access provider-owned data without copying it into each consumer account. This is the appropriate pattern for centrally maintained reference data that must be updated by the provider and made visible across installations. At the same time, the app can create application objects in the consumer account to store derived or consumer-specific results. This design minimizes duplication, supports centralized updates, and prevents consumers from directly changing the provider-owned source data.
- B. Incorrect.
Incorrect. Copying the reference tables into every consumer account increases storage duplication and creates operational complexity for weekly refreshes. It also undermines the requirement that provider updates become visible centrally without redistributing data into every installation. While setup scripts can create objects during installation, they are not the best mechanism for maintaining shared provider-owned reference data across all consumers.
- C. Incorrect.
Incorrect. Native Apps can expose provider-owned shared content to consumers through the application package, so loading from an external stage into temporary tables is unnecessary and inefficient for this scenario. This option also adds repeated ingestion overhead and weakens the central-update requirement because the data would need to be reloaded per session or on some schedule rather than consumed directly as provider-managed shared content.
- D. Incorrect.
Incorrect. Creating a separate copy of the provider reference data in each consumer account still causes unnecessary duplication and weekly refresh challenges. Application roles control access to objects within the app, but they do not make per-consumer copied data a better design than shared content when the goal is centralized provider maintenance. The misconception is that access control alone solves the lifecycle and update-distribution problem.