What you will be able to do
- Tell versions from patches and decide which kind of change belongs in each
- Plan around the two-version limit per release channel, including how to retire a version
- Apply the n/n-1 compatibility rule when planning upgrade paths
- Protect running work and data during an upgrade, including apps with containers
1.Versions, patches and the two-version limit
Every Snowflake Native App release is either a version or a patch, and each one ships with its own manifest file and setup script. Versions usually carry major updates: new features and changed behavior. Patches carry smaller updates, such as security fixes. On the consumer side, patches are typically used for bug fixes and improvements that do not need schema changes.
Versions and patches are defined in a release channel. The framework has three. QA is for testing inside the provider's organization: releases must be targeted to specific accounts, and they don't trigger the automated security scan. ALPHA can go to consumers outside the organization and does trigger the scan. DEFAULT is the production channel, and everything in it must pass the scan.
Checkpoint 1 of 7· Exam question
A provider's setup script creates a stored procedure using CREATE OR REPLACE PROCEDURE. During a customer's upgrade, the script fails after this statement runs but before granting usage to the application role, and Snowflake reruns the script from the beginning. The provider wants to guarantee the application role never loses access to the procedure across any rerun. Which approach should the provider use?
Correct answer: A — Keep CREATE OR REPLACE PROCEDURE and re-issue the GRANT USAGE statement immediately after every occurrence of the procedure definition in the setup script
- A. CREATE OR REPLACE drops and recreates the object, clearing previously granted privileges, so re-issuing the grant immediately after every recreate guarantees the application role's access survives any rerun.
- B. Never modifying the procedure body across upgrades defeats the purpose of shipping updated logic in a new version, so this is the wrong tool even though it avoids the grant issue.
- C. Privileges do not persist automatically through a recreate; the underlying object identity changes, so previously granted privileges are lost and must be reapplied.
- D. Setup scripts do not support wrapping statements in a manual transaction to preserve grants this way; grants must be explicitly re-issued after each recreate.
The limit that shapes all upgrade planning is that each release channel can hold only two versions at a time. The limit applies per release channel, not per application package. A single version can have many patches, and patches cannot be dropped. A new version starts at patch 0. When you add a patch without specifying a number, Snowflake increments it by 1. To add a third version to a channel, the provider has to retire one first, in a fixed sequence.
Checkpoint 2 of 7· Put it in order
A release channel already holds two versions. Put the provider's steps for introducing a new version in order.
- 1.Upgrade the app
- 2.Ensure that all consumers have upgraded off the version to be removed
- 3.Remove the version from the release channel
- 4.Create a new version
A version can only be removed once no consumer is still on it. Removing it frees the slot for the new version, which is then rolled out as an upgrade.
“Ensure that all consumers have upgraded off the version to be removed.”Source: docs.snowflake.com
Sources1
2.Planning upgrade paths with the n/n-1 compatibility window
The two-version limit also sets the provider's compatibility obligation. To release version 3, a provider must first move every consumer account off version 1. That means the provider only ever has to reason about compatibility with the version immediately before the current one.
The rule works like this. Version n can change something from n-1, but it must stay compatible with n-1 and perform any migration needed. In n+1, compatibility with n-1 is no longer required, because the n-1 to n migration is finished and nobody expects to upgrade straight from n-1 to n+1. This lets providers change their schema step by step: add a column in one version, and drop support for the old shape in the next.
Patches are held to a stricter standard. A patch must be compatible with code running from every other patch of the same version, and it must not bring in state changes that differ from earlier patches. Providers should keep changes such as adding or altering tables or columns to a minimum in patches. State changes belong in a new version only. In practice, a schema migration means a new version, while a bug fix means a patch.
| Release type | Must be compatible with | State (schema) changes |
|---|---|---|
| Patch | Code running from all other patches of the same version | Should be avoided; patches focus on bug fixes or minor features |
| New version n | The immediately prior version n-1, including migrating its state | Allowed; state changes should only be made in a new version |
| Version n+1 | Version n only; not n-1 | Allowed, with migration from n |
Checkpoint 3 of 7· Check yourself
A provider needs a new column in a stateful table to support a feature. Which release plan follows Snowflake's guidance?
State changes belong in versions, not patches, and version n must remain compatible with n-1 while it migrates. Compatibility with older versions is not required, and patches cannot be dropped.
“State changes should only be made when updating the version of an app.”Source: docs.snowflake.com
Sources2
3.Data integrity safeguards while an upgrade is in flight
Compatibility rules decide what a new release may change. Integrity safeguards protect the data and the running work while the change is being applied. The first safeguard is version pinning in versioned schemas. When an object in a versioned schema runs a query, that query is tied to the app version that started it. If v1 is running a long query when the upgrade happens, the app's upgrade state can move to COMPLETE on v2, while the previous version moves to FINALIZING until all v1 jobs have finished. Consumers see the same thing: a long-running procedure finishes on the version it started on, with no switch partway through.
Checkpoint 4 of 7· Exam question
Which statements accurately describe the difference between CREATE OR REPLACE and CREATE IF NOT EXISTS when used in a Native App setup script? (Select all that apply)(Select 3)
Correct answers: A, B, E — CREATE OR REPLACE recreates the object every run, discarding previously granted privileges; CREATE IF NOT EXISTS leaves an already-existing object untouched, preserving its current privileges and data; Using CREATE OR REPLACE on a procedure requires re-granting privileges afterward to restore consumer access
- A. Correct: recreating the object each run means any privileges granted on the prior instance of the object are lost and must be reapplied.
- B. Correct: because the object is skipped when it already exists, its current grants and data remain intact across reruns.
- C. Incorrect: Snowflake also recommends CREATE IF NOT EXISTS and CREATE OR ALTER as idempotent forms, so CREATE OR REPLACE is not the only option.
- D. Incorrect: because the statement is skipped entirely when the object exists, any changes to the body in a new version are never applied through this form.
- E. Correct: since CREATE OR REPLACE recreates the object and clears prior grants, the setup script must re-grant privileges to restore consumer access.
The second safeguard is rollback for versioned objects. If an error occurs during the upgrade of a basic app, the objects in the versioned schema revert to the previous version. Stateful tables in regular schemas have no per-version copies, so the old code and the new code both see the same data. That leads to two more rules. Always define views on shared content in a versioned schema, so code reading the view during an upgrade sees a consistent definition, and use a versioned schema when adding or removing columns or other attributes. If the script has to do very long operations, such as upgrading large state tables, make sure the changes still work with code from the previous version that is still running. What carries over: tables inside the app, objects the app created outside its boundary, and the consumer's existing privilege grants to the app.
Checkpoint 5 of 7· Check yourself
A v1 query is still running when the app upgrades to v2. Which outcome matches the documented behavior of versioned schemas?
Version pinning keeps the query on v1. The app moves to v2 while the old version stays in FINALIZING until its work is done.
“The previous version state changes to FINALIZING until all jobs from version v1 have completed.”Source: docs.snowflake.com
4.Keeping services in step: apps with containers
Rollback of versioned objects has a gap that matters for apps with containers. Services cannot live in versioned schemas, so a service is upgraded the moment CREATE SERVICE or ALTER SERVICE succeeds. If the setup script fails later, the versioned objects revert to the previous version but the services stay on the new version. Both commands are also asynchronous, so the new service may not be available yet even after the upgrade finishes.
Checkpoint 6 of 7· Exam question
Which of the following are command forms Snowflake recommends for writing idempotent setup script statements that can run safely across multiple installation and upgrade attempts? (Select all that apply)(Select 3)
Correct answers: A, B, C — CREATE OR REPLACE; CREATE IF NOT EXISTS; CREATE OR ALTER
- A. Correct: recreating the object each run is one of the recommended idempotent forms, provided grants are reapplied afterward.
- B. Correct: skipping creation when the object already exists is a recommended idempotent form for objects that should not change.
- C. Correct: modifying an existing object in place while preserving it is a recommended idempotent form, notably for versioned schemas.
- D. Incorrect: dropping objects with cascade in a setup script is destructive and not part of Snowflake's idempotency recommendations.
- E. Incorrect: truncating data on every run would destroy state each time the script executes and is not an idempotency recommendation.
- F. Incorrect: this form recreates a table from a query result each run, which is not among the recommended idempotent create forms for setup scripts.
The framework gives providers two tools for this. The first is SYSTEM$WAIT_FOR_SERVICES, called after creating or altering a service. It pauses the setup script until all named services are READY, any of them is FAILED, or the timeout runs out. Pick the timeout carefully, because a value that is too long can break other parts of the app that expect the service to be up. The second is the version initializer, a callback stored procedure declared in the manifest. Snowflake recommends starting or upgrading services there instead of in the setup script, and using it to roll services back to the previous version if the upgrade fails. Create the version initializer in a versioned schema, or it may not exist from one version to the next. It does not need to be granted to an application role.
SELECT SYSTEM$WAIT_FOR_SERVICES(600, 'services.web_ui', 'services.worker', 'services.aggregation');Checkpoint 7 of 7· Check yourself
A container app's setup script runs ALTER SERVICE successfully, then fails on a later statement. What state is the app left in?
Services are outside versioned schemas, so they don't revert with versioned objects. This mismatch is why Snowflake recommends managing services in the version initializer.
“a service is upgraded as soon as the CREATE SERVICE or ALTER SERVICE command run successfully.”Source: docs.snowflake.com
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A new version must stay backward compatible with every version that came before it.Why is that wrong?
Compatibility is only required with the immediately prior version, because only two versions can exist at once.
Covered in Planning upgrade paths with the n/n-1 compatibility window
2.The two-version limit applies to the whole application package.Why is that wrong?
The limit applies to each release channel separately.
Covered in Versions, patches and the two-version limit
3.A failed upgrade rolls back the whole app, including its services.Why is that wrong?
Only versioned-schema objects revert. Services are already on the new version, so the version initializer has to roll them back.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“each release channel only allows two versions of an app at a time.”
↩︎ Versions, patches and the two-version limit“Patches cannot be dropped.”
↩︎ Versions, patches and the two-version limit“Apps published using the QA release channel are not required to run the automated security scan.”
↩︎ Versions, patches and the two-version limit“The two-version limit applies to each release channel instead of per application package.”
↩︎ Exam trap 2“Ensure that all consumers have upgraded off the version to be removed.”
↩︎ Checkpoint - 2.
“they must first upgrade all consumer accounts off the oldest version”
↩︎ Planning upgrade paths with the n/n-1 compatibility window“it must still maintain compatibility with n-1 and perform whatever migration is needed.”
↩︎ Planning upgrade paths with the n/n-1 compatibility window“A patch must be compatible with the code running from all other patches of the same version.”
↩︎ Planning upgrade paths with the n/n-1 compatibility window - 3.
“the objects within the versioned schema revert back to the previous version of the app.”
↩︎ Data integrity safeguards while an upgrade is in flight“Snowflake recommends creating the version initializer stored procedure within a versioned schema.”
↩︎ Keeping services in step: apps with containers“version v3 does not have to be compatible with version v1.”
↩︎ Exam trap 1“Use the version initializer function to rollback service upgrades to the previous version if the upgrade fails.”
↩︎ Exam trap 3“version v3 does not have to be compatible with version v1.”
↩︎ Prediction“State changes should only be made when updating the version of an app.”
↩︎ Checkpoint“a service is upgraded as soon as the CREATE SERVICE or ALTER SERVICE command run successfully.”
↩︎ Checkpoint - 4.
“Always define views on shared content in a versioned schema”
↩︎ Data integrity safeguards while an upgrade is in flight“ensure that these updates are compatible with existing running code from the previous version.”
↩︎ Data integrity safeguards while an upgrade is in flight
Also cited
“The previous version state changes to FINALIZING until all jobs from version v1 have completed.”
↩︎ Checkpoint