What you will be able to do
- Put stateless code in versioned schemas and stateful data in regular schemas
- List the object types that cannot live in a versioned schema
- Separate data objects from logic objects in a Declarative Native App
- Decide whether a change ships as a new version or a patch, within the release-channel limits
1.Stateless code and stateful data need different schemas
An app's setup script runs again on every upgrade. So for each object it creates, the provider has to decide whether it should be rebuilt for the new release or kept from the previous one.
Stateless objects are the app's code: stored procedures, UDFs, Streamlit apps and similar. They only need to exist for the life of a version and are recreated for each new version or patch. They belong in a versioned schema. This is a special schema that keeps a separate internal subschema for each app version. The consumer sees only the objects for the version they have installed. Queries started by an object in a versioned schema are pinned to the version that started them. If an upgrade happens during a long query, the old version moves to FINALIZING until its jobs finish.
Stateful objects have to survive upgrades. An example is a table that stores configuration in the consumer account. These belong in a regular schema, created so that they persist through both the first install and later upgrades.
CREATE SCHEMA IF NOT EXISTS stateful_object;
CREATE TABLE IF NOT EXISTS stateful_object.config (
config_param STRING,
config_value STRING,
default_value STRING,
modified_on TIMESTAMP);
ALTER TABLE stateful_object.config
ADD COLUMN IF NOT EXISTS modified_on TIMESTAMP;On a fresh install, the IF NOT EXISTS clauses create the table. On an upgrade, they leave the existing rows alone, and the ALTER TABLE adds a column that an older version didn't have. Objects in a versioned schema work the other way. The setup script recreates them with CREATE OR REPLACE or CREATE IF NOT EXISTS, because every version gets its own copies. Create the versioned schema itself with the CREATE OR ALTER form so that it stays compatible across versions and patches.
Checkpoint 1 of 6· Fill the gap
Which keyword makes this setup-script statement create a schema suited to stateless app code?
CREATE OR ALTER ? SCHEMA version_schema;Stateless objects such as procedures and UDFs go in a versioned schema, created with CREATE OR ALTER VERSIONED SCHEMA.
Source: docs.snowflake.comSources1
2.What a versioned schema cannot hold
Versioned schemas come with restrictions that shape a schema plan. They exist only inside an application object and can only be created by the setup script. Snowpark Container Services, tasks, tags, masking policies, grants and future grants aren't supported in them. They can't be the source or target of a clone, and they can't be dropped. Dropping one would remove every version's objects and break queries still running against older versions or patches.
The result is that most apps need at least two schemas: a versioned schema for code, and a regular schema for application roles, tasks, governance policies, container services and persistent data.
Checkpoint 2 of 6· Check yourself
Which object can be placed in a versioned schema?
Stored procedures are stateless code, which is what versioned schemas are for. The other three must go in a normal schema.
“Tags and masking policies are not supported in versioned schemas.”Source: docs.snowflake.com
Checkpoint 3 of 6· Exam question
A provider wants to share tables, views, and a handful of stored procedures and notebooks as one packaged data product, but wants to avoid writing and maintaining a setup script and prefers automatic privilege management and versioning. Which approach should the provider choose?
Correct answer: B — Declarative Sharing in the Native App Framework
- A. Secure Data Sharing is incorrect because it does not support bundling stored procedures or notebooks as shared code objects.
- B. Declarative Sharing is correct because it lets the provider define data and code objects like notebooks and procedures in a YAML manifest, with Snowflake automatically handling privilege management and versioning instead of a setup script.
- C. A full Native App with a setup script is incorrect because it requires exactly the setup script maintenance the provider wants to avoid, even though it could technically bundle the same objects.
- D. A container-based Native App is incorrect because it targets containerized services and workloads, which is unnecessary complexity for sharing procedures and notebooks.
Sources1
3.Data objects vs. logic objects in Declarative apps
Declarative Native Apps separate schemas along a different line: how each object reaches the consumer. Data objects are tables and views, and they are shared by reference. The consumer reads the provider's object. Logic objects are UDFs, stored procedures and Cortex Agents, and they are shared by copy. The framework requires them to be in separate schemas, for example DATA_SCHEMA for tables and views and LOGIC_SCHEMA for UDFs.
Several other naming rules affect the layout. Schema mapping isn't supported, and overlapping schema names from multiple databases aren't allowed. Every object name has to be written out, because wildcards and regular expressions aren't supported. No two shared objects can share the same domain and name. For a Cortex Agent, procedures and UDFs can sit in the agent's schema, but semantic views and Cortex Search-based tools must be in a different schema.
For privileges, Declarative apps don't need REFERENCE_USAGE grants to the application package. Every application role used in the shared content must also be defined in the manifest's roles field.
Checkpoint 4 of 6· Check yourself
In a Declarative Native App, a provider puts a table and the UDF that queries it in the same schema. What is wrong?
Declarative Sharing requires tables and views to be in a different schema from UDFs, procedures and Cortex Agents, because the two groups are shared in different ways.
“data objects (shared by reference: tables and views) and logic objects (shared by copy: UDFs, stored procedures, Cortex Agents)”Source: docs.snowflake.com
Sources2
4.New version or patch?
Providers change a published app by releasing versions and patches. A version usually contains major updates, meaning new features or changed behaviour. A patch is a smaller update, and the guidance limits patches to small changes such as security fixes. Each version and each patch needs its own manifest file and setup script.
The two have different lifecycle rules. Each release channel allows only two versions at a time. The limit applies to each channel, not to the application package as a whole. A version can have many patches, but patches can't be dropped. A new version starts at patch 0. If you add a patch without giving a number, Snowflake increments the patch number by 1.
If a channel already has two versions and you need a third, you first have to retire one of the existing versions. The release channel also affects testing. QA is limited to accounts in your own organization and doesn't trigger the automated security scan. ALPHA and DEFAULT do trigger it, and anything in DEFAULT must pass the scan.
Checkpoint 5 of 6· Exam question
A provider is designing a data product that must run complex multi-step business logic, present an interactive Streamlit-based UI, and eventually be listed for monetized consumption on the Snowflake Marketplace. Which architecture should the provider select?
Correct answer: C — A full Snowflake Native App
- A. Secure Data Sharing is incorrect because it has no mechanism for bundling interactive UI components or complex procedural logic.
- B. Declarative Sharing is incorrect here because, while it can bundle some code objects, it is designed for simpler data-plus-code products and does not target rich interactive Streamlit experiences with monetized listings the way a full app does.
- C. A full Native App is correct because it supports setup scripts, stored procedures, embedded Streamlit UIs, and Marketplace listings with monetization, matching every stated requirement.
- D. A direct share without a listing is incorrect because it provides no path to Marketplace monetization or bundled application logic.
Checkpoint 6 of 6· Put it in order
A release channel already holds two versions. Put the steps for shipping a new version in order.
- 1.Remove that version from the release channel
- 2.Upgrade the app
- 3.Ensure all consumers have upgraded off the version to be removed
- 4.Create the new version
A channel holds only two versions, so one has to be emptied of consumers and removed before the new version can be added and rolled out.
“Ensure that all consumers have upgraded off the version to be removed.”Source: docs.snowflake.com
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Persistent configuration tables should go in the versioned schema so they move along with each version.Why is that wrong?
Objects in a versioned schema are recreated per version. Data that must survive upgrades goes in a regular schema.
Covered in Stateless code and stateful data need different schemas
2.An application package can only ever have two versions.Why is that wrong?
The two-version limit applies to each release channel, not to the package as a whole.
Covered in New version or patch?
3.A broken patch can be dropped and replaced, just like a version.Why is that wrong?
Versions can be removed from a release channel once consumers have moved off them, but patches can't be dropped.
Covered in New version or patch?
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Stateless objects should be created in a versioned schema.”
↩︎ Stateless code and stateful data need different schemas“A consumer will only see objects within the versioned schema that correspond to the version of the app”
↩︎ Stateless code and stateful data need different schemas“You should always include the CREATE OR ALTER version of this command to ensure that versioned schemas are compatible across versions and patches.”
↩︎ Stateless code and stateful data need different schemas“Snowpark Container Services is not supported in versioned schemas.”
↩︎ What a versioned schema cannot hold“Dropping a versioned schema is not supported.”
↩︎ What a versioned schema cannot hold“Stateful objects should be created using a regular schema.”
↩︎ Exam trap 1“To use application roles, tasks, tags, masking policies and Snowpark Container Services within the setup script of an app”
↩︎ Prediction“Tags and masking policies are not supported in versioned schemas.”
↩︎ Checkpoint - 2.
“Schema mapping is not supported. Overlapping schema names from multiple databases are not allowed.”
↩︎ Data objects vs. logic objects in Declarative apps“Object names must be explicitly specified; wildcard or regular expression matching is not supported.”
↩︎ Data objects vs. logic objects in Declarative apps“data objects (shared by reference: tables and views) and logic objects (shared by copy: UDFs, stored procedures, Cortex Agents)”
↩︎ Checkpoint - 3.
“Unlike versions, patches should only contain small updates such as security fixes.”
↩︎ New version or patch?“Each version and patch must have its own manifest file and setup script.”
↩︎ New version or patch?“Apps published using the QA release channel are not required to run the automated security scan.”
↩︎ New version or patch?“The two-version limit applies to each release channel instead of per application package.”
↩︎ Exam trap 2“Patches cannot be dropped.”
↩︎ Exam trap 3“Ensure that all consumers have upgraded off the version to be removed.”
↩︎ Checkpoint