What you will be able to do
- Distinguish the application package, manifest, setup script and installed application object
- Choose between Secure Data Sharing, a Declarative Native App and a full Snowflake Native App for a given requirement
- Decide when a full Native App with a setup script is justified
- Contrast provider data content shared through the package with references the consumer binds at install time
- Identify the Native App Framework limitations that rule out a design
Key concept
Application package vs. application object — The provider builds an application package that holds the app's data content, logic, manifest and setup script. The consumer installs it, and that creates a separate application object in the consumer's own account. Most design decisions come down to what goes into the package and what the setup script builds inside the installed app.
1.The building blocks: package, manifest, setup script, app
The Native App Framework uses the same provider and consumer roles as Secure Data Sharing. The provider has data and logic to share, and the consumer wants to use them. The provider never hands over loose objects. Everything goes into an application package, which holds the data content, application logic, metadata and setup script. The package also records the versions and patch levels defined for the app.
Every application package needs two files. The manifest file defines configuration and setup properties, such as where the setup script lives and which versions exist. The setup script contains SQL statements. These run when a consumer installs or upgrades the app, or when the provider installs it for testing.
The provider publishes the package through a listing. That can be a Snowflake Marketplace listing for many consumers, or a private listing for specific accounts. When a consumer installs from the listing, Snowflake creates the application object in the consumer account and runs the setup script to build the objects inside it. The consumer can then grant the privileges the app needs and turn on logging and event sharing.
Checkpoint 1 of 6· Match them up
Match each Native App Framework component to its role
Tap a term, then the definition that fits it.
The package is the provider-side container. The manifest and setup script are required files inside it. The installed app is a separate object in the consumer account.
“An application package encapsulates the data content, application logic, metadata, and setup script required by an application.”Source: docs.snowflake.com
Sources1
2.Secure Data Sharing, Declarative Native App, or full Native App
The three options cover increasing amounts of complexity.
Secure Data Sharing is the lightest option. The provider adds objects to a share and the consumer creates a read-only database from it. No data is copied. Consumers don't pay storage for shared data and pay only for the warehouses they use to query it. Shares can carry databases, tables, several kinds of views, Cortex Search services, UDFs and some model types. Stored procedures and app logic are not on that list, and consumers can't modify anything.
A Declarative Native App shares code objects as well as data. The supported types are workspaces (which can contain notebooks), stored procedures, UDFs, tables, views, Cortex Agents and streams. The provider lists them in a YAML manifest, and the framework handles privileges, object resolution and versioning without a setup script. The tradeoff is a fixed list of object types. Anything else is unsupported.
A full Snowflake Native App adds a setup script. That script builds objects inside the app in the consumer account, such as Streamlit UIs, procedures, versioned code and container services.
On cost, the sources only describe Secure Data Sharing: consumers pay compute and no storage. They don't give comparable cost figures for either Native App option, so treat cost as a reason to stay with plain sharing when data alone meets the requirement.
| Option | What it shares | Install-time logic | Consumer can modify shared objects? |
|---|---|---|---|
| Secure Data Sharing | Databases, tables, views, Cortex Search services, UDFs, some model types | None: consumer creates a read-only database from the share | No: shared objects are read-only |
| Declarative Native App | Tables, views, workspaces, stored procedures, UDFs, Cortex Agents, streams | None: declared in the manifest, no setup script | No: shared workspaces are read-only for consumers |
| Full Snowflake Native App | Data content plus business logic such as Streamlit, stored procedures and functions | Setup script runs on install and upgrade | Depends on the objects the setup script creates |
Checkpoint 2 of 6· Check yourself
A consumer needs to query a provider's reference tables. There is no provider logic involved, and the consumer wants to avoid extra storage charges. What is the lightest design that fits?
Secure Data Sharing copies no data, so the consumer pays only for compute. No app framework is needed when only data is shared.
“The only charges to consumers are for the compute resources (i.e. virtual warehouses) used to query the imported data.”Source: docs.snowflake.com
3.When a full Native App is the right call
A full Native App is worth building when the product is more than data. The framework's purpose is to share data together with the business logic that operates on it. That logic can include a Streamlit app and stored procedures or functions written with the Snowpark API, JavaScript or SQL. A full app also supports listings that can be free or paid, versions and patches for evolving the logic, and structured and unstructured event logging for troubleshooting.
The framework's own guidance gives a test for when something needs a setup script. Objects that work on provider-side content, which consumers read at query time, can be declared in the manifest. Objects that have to be built inside the app in the consumer's account need a setup script. Examples are Snowpark Container Services, stored procedures that use external access integrations, and logic that depends on consumer-side tooling. If none of your requirements fall into that second group, a lighter option is probably enough.
Checkpoint 3 of 6· Check yourself
Which requirement points directly to a setup script instead of declaring content in the manifest?
Container services have to be built inside the app environment in the consumer account, and that is the setup script's job. Views and search services read provider-side content at query time, so they can be declared in the manifest.
“Use a setup script when the object has to be built inside the app environment in the consumer’s account, such as Snowpark Container Services”Source: docs.snowflake.com
4.Provider data content vs. consumer references
An app can work with data from two directions, and the architecture has to say which one each dataset uses.
Provider data content is shared into the application package. You can't share objects that live outside the package directly with the installed app. To include a table from another database, grant REFERENCE_USAGE on that database to the package, create a view inside the package that selects from it, and then grant the schema and view to the package. Whenever you add a shared object, you also have to share the schema that contains it.
GRANT USAGE ON SCHEMA app_pkg.shared_schema
TO SHARE IN APPLICATION PACKAGE app_pkg;
GRANT SELECT ON VIEW app_pkg.shared_schema.shared_view
TO SHARE IN APPLICATION PACKAGE app_pkg;Consumer data works the other way. The provider doesn't copy it in. The manifest's optional references field lists the external objects in the consumer account that the app expects to bind to, such as tables, views, secrets or integrations. Each entry has a label, a description and the privileges it requires, so the consumer knows what to provide. Use references when the app has to work on data only the consumer owns. Use shared data content for datasets the provider owns and controls. The sources describe both mechanisms but don't state any further tradeoffs between them.
Checkpoint 4 of 6· Exam question
A provider wants to distribute a curated set of raw tables and views to several consumer accounts. Consumers only need read access to the data itself, with no bundled business logic, UI, or procedural code. Which distribution model best fits this requirement?
Correct answer: A — Secure Data Sharing
- A. Secure Data Sharing is correct because it is built for pure data-only distribution of tables and views without any packaged application logic, making it the lowest-cost and lowest-complexity option here.
- B. A full Native App with a setup script is incorrect because writing and maintaining setup script logic is unnecessary overhead when only raw tables and views need to be shared.
- C. Snowpark Container Services apps are incorrect because they exist to package containerized compute and services, which is far more complexity than a data-only distribution needs.
- D. Declarative Sharing is incorrect for this case because, while simpler than a full app, it exists to bundle code objects like notebooks or procedures alongside data, which is not required here.
Checkpoint 5 of 6· Check yourself
An app must analyse each consumer's own orders table, which the provider has no copy of. Which manifest feature supports this design?
References describe objects in the consumer account that the app requests. REFERENCE_USAGE and shared schemas only apply to provider-side objects.
“This field is required if the app requests references in the consumer account.”Source: docs.snowflake.com
5.Limitations that change the design
Some requirements can't be met at all, and you need to spot them before choosing an architecture.
General. Temporary tables and temporary stages aren't supported. Some Streamlit features aren't supported. Storage lifecycle policies and Snowflake ML functions such as Top Insights aren't available. Native Apps don't support failover for business continuity, so you can't add an application package to a replication or failover group.
With containers. An app can have at most 15 compute pools. Sessions opened from containers are limited to the application owner role. You can't set logging and trace levels for a container in the manifest. Use spec.logExporters in the service specification instead.
Regions and deployments. Department of Defense regions aren't supported. Apps with containers aren't yet supported in Azure government regions. Providers publishing from government regions can share listings only within their own organization. In Virtual Private Snowflake, Native Apps and Streamlit aren't enabled by default, only private listings are supported, and listings are managed with SQL because the Marketplace interface isn't available.
Declarative apps have their own limits. Only the supported object types can be shared, with at most 10,000 objects in the shared content section of the manifest. There are no audit trails for how consumers use the data. There is no migration path from existing data shares.
Checkpoint 6 of 6· Check yourself
A customer requires the app to be part of a failover group for business continuity. What should the architect conclude?
The limitations page rules out failover for business continuity, including adding an application package to a replication or failover group.
“Snowflake Native Apps do not support failover for business continuity.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Consumers of a Secure Data Share can add rows or change the shared tables.Why is that wrong?
Every object shared through Secure Data Sharing is read-only for the consumer. If consumers need to keep their own state, you need an app.
Covered in Secure Data Sharing, Declarative Native App, or full Native App
2.A Declarative Native App still needs a setup script to grant privileges on its shared objects.Why is that wrong?
Declarative Sharing defines everything in the YAML manifest. The framework handles privileges, object resolution and versioning without a setup script.
Covered in Secure Data Sharing, Declarative Native App, or full Native App
3.A table in another provider database can be shared directly with the installed app.Why is that wrong?
Objects outside the application package can't be shared directly. The provider grants REFERENCE_USAGE and exposes the data through a view inside the package.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“An application package requires a manifest file and a setup script.”
↩︎ The building blocks: package, manifest, setup script, app“Contains SQL statements that are run when the consumer installs or upgrades an application”
↩︎ The building blocks: package, manifest, setup script, app“The business logic of an application can include a Streamlit app, stored procedures, and functions written using Snowpark API, JavaScript, and SQL.”
↩︎ When a full Native App is the right call“A Snowflake Native App is the database object installed in the consumer account.”
↩︎ Key concept“An application package encapsulates the data content, application logic, metadata, and setup script required by an application.”
↩︎ Checkpoint - 2.
“With Secure Data Sharing, no actual data is copied or transferred between accounts.”
↩︎ Secure Data Sharing, Declarative Native App, or full Native App“All database objects shared between accounts are read-only”
↩︎ Exam trap 1“The only charges to consumers are for the compute resources (i.e. virtual warehouses) used to query the imported data.”
↩︎ Checkpoint - 3.
“share not just data, but code objects”
↩︎ Secure Data Sharing, Declarative Native App, or full Native App“the framework handles privilege management, object resolution, and versioning automatically, with no setup script required.”
↩︎ Exam trap 2“the framework handles privilege management, object resolution, and versioning automatically, with no setup script required.”
↩︎ Prediction - 4.
“All other object types are not supported for sharing in Declarative Sharing in Native Apps.”
↩︎ Secure Data Sharing, Declarative Native App, or full Native App“Migration support for switching from data shares to Declarative Sharing in the Native App framework is unavailable.”
↩︎ Limitations that change the design - 5.
“Declare it in the manifest when the object operates on provider-side content that consumers read at query time”
↩︎ When a full Native App is the right call“Use a setup script when the object has to be built inside the app environment in the consumer’s account, such as Snowpark Container Services”
↩︎ Checkpoint - 6.
“When adding a shared object to an application package, you must also share the schema that contains the object.”
↩︎ Provider data content vs. consumer references“You cannot share objects outside the application package directly with app installed in the consumer account.”
↩︎ Exam trap 3 - 7.
“This field is required if the app requests references in the consumer account.”
↩︎ Provider data content vs. consumer references - 8.
“A maximum of 15 compute pools per application is allowed.”
↩︎ Limitations that change the design“Apps with containers are not yet supported in Azure government regions.”
↩︎ Limitations that change the design“Snowflake Native Apps do not support failover for business continuity.”
↩︎ Checkpoint