What you will be able to do
- Set, modify and remove default and custom release directives on a release channel
- Schedule automated upgrades with UPGRADE_AFTER, or with maintenance windows and a deadline
- Apply the version assignment constraints that control upgrades and version removal
- Configure the account-level auto-fulfillment refresh that carries upgrades to remote regions
- Query release metadata, upgrade state and per-consumer usage
1.Default and custom release directives
A release directive tells Snowflake which version and patch a release channel delivers. Each channel can have two kinds. The default release directive covers every consumer of the channel. A custom release directive is named and lists specific accounts, so you can move a subset of consumers to a different version or patch, for example to roll out a fix to one customer first.
Checkpoint 1 of 8· Fill the gap
Complete this command so it sets the release directive that applies to every consumer of the ALPHA channel.
ALTER APPLICATION PACKAGE my_app_package
MODIFY RELEASE CHANNEL ALPHA
SET ? RELEASE DIRECTIVE VERSION=v1 PATCH=10;SET DEFAULT RELEASE DIRECTIVE sets the channel-wide directive. A custom directive is set with SET RELEASE DIRECTIVE plus a name and an ACCOUNTS list.
Source: docs.snowflake.comALTER APPLICATION PACKAGE my_app_package
MODIFY RELEASE CHANNEL ALPHA
SET RELEASE DIRECTIVE my_custom_release_directive
VERSION=V1 PATCH=11 ACCOUNTS=(ORG1.ACCOUNT1);Once a custom directive exists, MODIFY RELEASE DIRECTIVE <name> changes its version and patch, and UNSET RELEASE DIRECTIVE <name> removes it from the package. A directive can only point at a version that has already been added to that channel. This syntax applies only to packages that use release channels; packages without channels use the legacy ALTER APPLICATION PACKAGE … RELEASE DIRECTIVE command.
Checkpoint 2 of 8· Exam question
A provider runs `ALTER APPLICATION PACKAGE my_pkg ADD VERSION v2 USING '@my_pkg.stage.files/v2/'`. What is the purpose of the USING clause in this statement?
Correct answer: A — It specifies the stage location containing the application files that make up the new version being registered
- A. The USING clause points to the stage path holding the manifest, setup script, and other files for the version being added, which is exactly how a provider registers a new version's content.
- B. This is incorrect because granting consumer access is handled separately through release directives, not through the stage path used when adding a version.
- C. This is incorrect because a newly added version is not automatically placed on any release channel; it must be explicitly added to a channel afterward.
- D. This is incorrect because there is no warehouse compilation step tied to this clause; the setup script is parsed and validated directly from the staged files.
Sources1
2.Scheduling when an automated upgrade starts
Changing a release directive is what starts an upgrade. When the directive points to a new version or patch, Snowflake queues every installed instance on the current version and upgrades each one as resources become available. Providers can also ask consumers to upgrade manually for a faster rollout. Three optional parameters on the directive statement control when the automated upgrade begins.
ALTER APPLICATION PACKAGE <name>
MODIFY RELEASE CHANNEL <release_channel>
SET DEFAULT RELEASE DIRECTIVE
VERSION = <version_identifier>
PATCH = <patch_num>
[ UPGRADE_AFTER = '<timestamp>' ]
[ UPGRADE_IN_MAINTENANCE_WINDOW = { TRUE | FALSE } ]
[ UPGRADE_DEADLINE = '<timestamp>' ]UPGRADE_AFTER sets the earliest time the automated upgrade can begin. The actual start can be later, depending on how many apps and consumer accounts are being upgraded. Consumers can still upgrade manually before that time. It works on both default and custom directives, but only in a statement that also sets the version and patch. You cannot use it to change just the time.
UPGRADE_IN_MAINTENANCE_WINDOW = TRUE makes the upgrade respect consumer maintenance policies. Each upgrade is delayed until the consumer's next maintenance window or until the deadline, whichever comes first. Setting it to TRUE makes UPGRADE_DEADLINE required, because after the deadline the app is upgraded regardless of the consumer's policy. UPGRADE_AFTER and UPGRADE_IN_MAINTENANCE_WINDOW cannot be used in the same statement.
Checkpoint 3 of 8· Check yourself
A provider wants an upgrade to run inside each consumer's maintenance window instead of at a fixed time. Which parameter combination is valid?
Maintenance-window upgrades require a deadline and cannot be combined with UPGRADE_AFTER.
“When this parameter is set to TRUE, the UPGRADE_DEADLINE parameter is required.”Source: docs.snowflake.com
3.Version assignment constraints during upgrades
Snowflake limits which versions can be live at once. Before consumers can move to v3, every install must already be on v2, so only the previous version is ever active. As a result, the setup script only has to handle differences between two consecutive versions. Patches have no such limit, so many patches can be running at once. That is why providers should not make state changes, such as new tables or columns, in a patch.
The previous version cannot be removed from a channel while any code from it is still running in any consumer account. Dropping a version from a channel is asynchronous: it only completes after every consumer has been upgraded off it. If even one upgrade fails, the provider must fix the cause before the version can be removed. Deregistering has its own rule: the version must not be in any channel and no installed instances can be running on it.
Checkpoint 4 of 8· Put it in order
Put the documented provider upgrade workflow in order.
- 1.Update the release directive to start the automated upgrade
- 2.Update the app to include the new features
- 3.Test the new version by installing it in a test account
- 4.If two versions already exist, make sure no consumers are running the one being replaced, then drop it
- 5.Create the new version or patch in the release channel
The release directive comes last because changing it is what starts upgrades for every installed instance.
“Update the release directive for the version or patch. This initiates an automated upgrade”Source: docs.snowflake.com
Checkpoint 5 of 8· Check yourself
A provider runs MODIFY RELEASE CHANNEL QA DROP VERSION V1 while some consumers are still on V1. What happens?
Dropping a version from a channel is asynchronous and finishes only after every consumer on it has been upgraded.
“Dropping a version from a release channel is asynchronous and will only be truly dropped once all consumers have been upgraded off that version.”Source: docs.snowflake.com
4.Auto-fulfillment settings for remote regions
If an app is listed with Cross-Cloud Auto-Fulfillment, upgrades in remote regions follow replication rather than happening right away. The new release directive is first propagated to the application package in each remote region. When most apps in the primary region have been upgraded, Snowflake signals the remote regions to start. How long this takes depends on the refresh schedule, the number of installed instances and the number of regions. Until a refresh reaches a remote region, consumers there might not see the change.
For application packages, the refresh is set at the account level, not per listing, and it applies to every application package the account publishes. Listings with shares attached are not affected. A user with the ACCOUNTADMIN role can change it in Snowsight or with SQL.
ALTER ACCOUNT SET LISTING_AUTO_FULFILLMENT_REPLICATION_REFRESH_SCHEDULE = '60 MINUTES'For an urgent fix, the provider can shorten the refresh interval, but the documentation warns that a more frequent refresh can raise replication costs. Two other options: providers can trigger an on-demand refresh, or use the LISTING_AUTO_REFRESH clause of ALTER APPLICATION PACKAGE so the package refreshes every time the release directive changes. The schedule in each region starts from the time a consumer there first requested the data product.
Checkpoint 6 of 8· Exam question
What is the maximum length allowed for a version_identifier when registering a new version on an application package?
Correct answer: A — 30 characters
- A. A version identifier is limited to 30 characters, which providers must account for when naming versions in the manifest or in the ADD VERSION statement.
- B. This is incorrect; 16 characters is too short and is not the documented limit for a version identifier.
- C. This is incorrect; 64 characters exceeds the actual documented limit for a version identifier.
- D. This is incorrect; 128 characters is far beyond the documented limit and is not the constraint that applies here.
Checkpoint 7 of 8· Check yourself
A provider wants remote-region consumers of all their Native Apps to receive upgrades more often. Where is this refresh configured?
Application packages use one account-level refresh setting that applies to every package the account publishes.
“set a data refresh at the account level that applies to every application package available from your account”Source: docs.snowflake.com
5.Viewing release metadata and usage metrics
Providers have several read-only views of what they have released. SHOW RELEASE CHANNELS IN APPLICATION PACKAGE lists a package's channels, and SHOW RELEASE CHANNELS IN LISTING does the same for a listing. SHOW RELEASE DIRECTIVES lists directives, optionally filtered to one channel. Its output includes name (DEFAULT for the default directive), target_type (DEFAULT or ACCOUNT) and target_name.
SHOW RELEASE DIRECTIVES [ LIKE '<pattern>' ]
IN APPLICATION PACKAGE <name>
[ FOR RELEASE CHANNEL <release_channel> ]To see installed instances, query SNOWFLAKE.DATA_SHARING_USAGE.APPLICATION_STATE. Its current_release_channel_name column shows which channel each instance uses, and other columns show the upgrade state and the region where the app is deployed. If an upgrade is still not complete more than a day after the first refresh that follows it, the documentation advises contacting Snowflake Support.
| State | Meaning |
|---|---|
| DISABLED | The app is disabled and not eligible for upgrade |
| QUEUED | Waiting in the upgrade queue |
| UPGRADING | Upgrade in progress |
| COMPLETED | Upgraded successfully |
| QUEUED_RETRY | The setup script or another check failed; the app is back in the queue |
| FAILED | Failed on the provider side (for example, a setup script error) or the consumer side (for example, an inactive account) |
For usage, the PROVIDER_APPLICATION_DAILY_USAGE_HISTORY view reports, for each consumer installation, the daily CREDITS_USED and the average STORAGE_BYTES, each with a breakdown array. It also includes the consumer's region and account and APPLICATION_NAME_HASH. The view only returns data for listings owned by the current account, data can be up to 2 days late, and it is kept for 365 days.
Checkpoint 8 of 8· Match them up
Match each upgrade state to what it means.
Tap a term, then the definition that fits it.
QUEUED_RETRY means Snowflake will try again. FAILED means it will not, and the cause must be fixed.
“The setup script or other check failed and the app is returned to the upgrade queue.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.You can combine UPGRADE_AFTER with UPGRADE_IN_MAINTENANCE_WINDOW to set an earliest start and also respect maintenance windows.Why is that wrong?
The two parameters cannot be used together. Maintenance-window upgrades use UPGRADE_DEADLINE instead.
Covered in Scheduling when an automated upgrade starts
2.Patches are limited like versions, so only two patches of a version can be running across consumers.Why is that wrong?
Only versions are limited. Any number of patches can be active, which is why patches should not change app state.
Practise it for real
Release a version through the QA channel to a test account and confirm the directive is in place.
1.Run ALTER APPLICATION PACKAGE my_app_package REGISTER VERSION V1 USING '@stage/path';
Why: Release-channel packages create versions by registering them, not with ADD VERSION USING.
You should see: Version V1 with patch 0 exists in the package but is not in any channel.
2.Run ALTER APPLICATION PACKAGE my_app_package MODIFY RELEASE CHANNEL QA ADD VERSION V1;
Why: A release directive can only point at a version that is in its channel.
You should see: V1 is in QA, and no security scan has started.
3.Run ALTER APPLICATION PACKAGE my_app_package MODIFY RELEASE CHANNEL QA SET DEFAULT RELEASE DIRECTIVE VERSION = V1 PATCH = 0;
Why: QA's default directive decides what QA installs receive.
You should see: The QA channel now delivers V1 patch 0.
4.Using a role with CREATE PREVIEW APPLICATION, run CREATE APPLICATION my_app FROM APPLICATION PACKAGE my_app_package USING RELEASE CHANNEL QA;
Why: Installing from QA requires the preview privilege, and leaving out the clause would install from DEFAULT.
You should see: A test instance of the app is created from the QA channel.
5.Run SHOW RELEASE DIRECTIVES IN APPLICATION PACKAGE my_app_package FOR RELEASE CHANNEL QA;
Why: Shows which directives are actually in effect.
You should see: A row named DEFAULT with target_type DEFAULT.
Stuck? Get a nudge
If ADD VERSION fails, check whether QA already holds two versions. Each channel can contain at most two.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.snowflake.com/en/sql-reference/sql/alter-application-package-release-channelOfficial docs
“Creates a custom release directive for the specified accounts.”
↩︎ Default and custom release directives“Removes the specified custom release directive from the application package.”
↩︎ Default and custom release directives“When set to TRUE, upgrades respect consumer maintenance policies.”
↩︎ Scheduling when an automated upgrade starts“A version can only be deregistered when it is not assigned to any release channel and no installed application instances are running on it.”
↩︎ Version assignment constraints during upgrades“If you try to set both, the command fails with an error.”
↩︎ Exam trap 1“When this parameter is set to TRUE, the UPGRADE_DEADLINE parameter is required.”
↩︎ Checkpoint - 2.
“You can only use the UPGRADE_AFTER clause if you are setting the version and patch.”
↩︎ Scheduling when an automated upgrade starts“Snowflake ensures that only the previous version of the app is active.”
↩︎ Version assignment constraints during upgrades“Reducing the refresh frequency can increase the costs associated with replication.”
↩︎ Auto-fulfillment settings for remote regions“When most of the apps in the primary region have been upgraded, Snowflake sends messages to the remote region to begin the app upgrade.”
↩︎ Auto-fulfillment settings for remote regions“the Snowflake Native App Framework does not enforce any restrictions on the number of active patches running”
↩︎ Exam trap 2“If the timestamp has already passed the upgrade is immediately scheduled.”
↩︎ Prediction“Update the release directive for the version or patch. This initiates an automated upgrade”
↩︎ Checkpoint“The setup script or other check failed and the app is returned to the upgrade queue.”
↩︎ Checkpoint - 3.https://docs.snowflake.com/en/collaboration/provider-listings-auto-fulfillment-set-refresh-intervalOfficial docs
“If you have the ACCOUNTADMIN role, you can change the refresh interval for the account using Snowsight or a SQL command.”
↩︎ Auto-fulfillment settings for remote regions - 4.
“To configure the application package to refresh each time the release directive is modified, use the LISTING_AUTO_REFRESH clause of the ALTER APPLICATION PACKAGE command.”
↩︎ Auto-fulfillment settings for remote regions“set a data refresh at the account level that applies to every application package available from your account”
↩︎ Checkpoint - 5.
“To view the release channels for all installed instances of an app, view the current_release_channel_name column of the SNOWFLAKE.DATA_SHARING_USAGE.APPLICATION_STATE view.”
↩︎ Viewing release metadata and usage metrics“Dropping a version from a release channel is asynchronous and will only be truly dropped once all consumers have been upgraded off that version.”
↩︎ Checkpoint - 6.
“Returns only the release directives defined for the specified release channels.”
↩︎ Viewing release metadata and usage metrics - 7.https://docs.snowflake.com/en/sql-reference/data-sharing-usage/provider-application-daily-usage-historyOfficial docs
“The view only returns data for listings owned by the current account.”
↩︎ Viewing release metadata and usage metrics“Latency for the view may be up to 2 days.”
↩︎ Viewing release metadata and usage metrics