What you will be able to do
- Tell development mode, debug mode and session debug mode apart, and say what each one exposes
- Choose the AS_APPLICATION or AS_SETUP_SCRIPT execution context for session debug mode
- Request account privileges in the manifest and grant app objects to application roles with SQL
- Gate Streamlit UI features on application roles, and place environment.yml correctly
1.Testing locally: development mode and debug mode
Before publishing, you test the app in the account that holds the application package. Snowflake describes three modes for creating and testing an app. The sources do not define a separate "test mode"; testing means using these three. Development mode applies when you install an app from a specific version or from files on a named stage. It lets you quickly try changes to the setup script or app logic. It also shows the app as a consumer would see it: only objects granted to application roles are visible, so DESC APPLICATION lists only the schemas those roles allow.
Debug mode removes that limit. You can see and change every object in the app, including objects not granted to any application role and shared content. You can only turn it on for an app created in development mode, in the same account as its package. You need OWNERSHIP on the app and DEVELOP on the application package.
ALTER APPLICATION hello_snowflake_app SET DEBUG_MODE = TRUE;| Mode | What the provider sees | Who owns objects created in it | Scope |
|---|---|---|---|
| Development mode | Only objects granted to application roles | n/a (consumer view) | The installed app |
| Debug mode | All objects in the app | The session's primary role | Toggled on the app with DEBUG_MODE |
| Session debug mode | All objects in the app | The app | Current session only |
Checkpoint 1 of 6· Check yourself
A developer runs ALTER APPLICATION ... SET DEBUG_MODE = TRUE on an app that a colleague installed from a listing in another account. Why does it fail?
Debug mode is a provider-side testing tool. It needs an app installed from a version or a stage, in the same account as the package.
“Debug mode can only be toggled on and off for an app created in development mode within the same account containing the application package.”Source: docs.snowflake.com
Sources1
2.Session debug mode and its execution contexts
Session debug mode fixes debug mode's ownership problem and narrows its reach. It lasts only for the current session, to reduce security risk: turning it on in one worksheet tab does not affect another tab. Objects you create in it are created with the app's privileges. You start it with SYSTEM$BEGIN_DEBUG_APPLICATION, which takes an optional execution context. AS_APPLICATION is the default and runs statements with the privileges the app has once installed in a consumer account. AS_SETUP_SCRIPT runs them with the privileges the setup script has during install or upgrade, which makes it the context for testing the setup script. It has the same requirements as debug mode: a development-mode app in the package's account, OWNERSHIP on the app and DEVELOP on the package.
Checkpoint 2 of 6· Fill the gap
You want to rehearse the setup script's grants with exactly the privileges it will have during install. Which execution mode completes the call?
SELECT SYSTEM$BEGIN_DEBUG_APPLICATION( 'hello_snowflake_app', execution_mode = ' ? ')AS_SETUP_SCRIPT gives statements the setup script's privileges. AS_APPLICATION, the default, mimics the installed app.
Source: docs.snowflake.comUse SELECT SYSTEM$GET_DEBUG_STATUS(); to check your current state, and SYSTEM$END_DEBUG_APPLICATION() to leave. Code inside the app can also tell when it is running in development mode: SYS_CONTEXT('SNOWFLAKE$APPLICATION', 'IS_DEV_MODE') returns TRUE in that case.
3.Requesting app privileges and granting with SQL
The privileges that development mode lets you check come from two places. Account-level privileges that the app needs in the consumer account are declared in the manifest privileges block. Each entry needs a description, which consumers see in Snowsight and in SHOW PRIVILEGES. Use it to explain why the app needs the privilege. Manifest version 2 adds automated granting of privileges. Roles in the SNOWFLAKE database, such as CORTEX_USER, are requested separately under snowflake_database, and consumers can review, grant and revoke them.
privileges:
- CREATE TABLE:
description: 'Required to create tables in the consumer account.'
- CREATE COMPUTE POOL:
description: 'Required to allow the app to create a compute pool in the consumer account.'
- BIND SERVICE ENDPOINT:
description: 'Required to allow endpoints to be externally accessible.'Going the other way, consumers reach the app's own objects through SQL grants in the setup script. Grant USAGE on the schema and then on the object, both to an application role. In the documented example, a Streamlit object is created in app_schema and then exposed to app_public.
CREATE OR REPLACE STREAMLIT app_schema.my_test_app_na
FROM '/code_artifacts/streamlit'
MAIN_FILE = '/streamlit_app.py';
GRANT USAGE ON SCHEMA APP_SCHEMA TO APPLICATION ROLE app_public;
GRANT USAGE ON STREAMLIT APP_SCHEMA.MY_TEST_APP_NA TO APPLICATION ROLE app_public;Checkpoint 3 of 6· Check yourself
After installing in development mode, a provider cannot see the Streamlit app as a consumer would. The setup script has GRANT USAGE ON STREAMLIT APP_SCHEMA.MY_TEST_APP_NA TO APPLICATION ROLE app_public;. Which grant is most likely missing?
The documented pattern grants USAGE on the schema as well as on the Streamlit object. Development mode only shows what application roles can reach.
“can only access objects granted to application roles, similar to the consumer perspective.”Source: docs.snowflake.com
Checkpoint 4 of 6· Exam question
A support engineer is investigating where a newly installed Native App's telemetry data is being stored, and the consumer has not configured any custom event table. Which event table holds this data by default?
Correct answer: A — SNOWFLAKE.TELEMETRY.EVENTS
- A. Every Snowflake account has this table available out of the box, and it is where telemetry lands when no custom event table has been configured.
- B. This is a usage/billing metadata schema, not the default destination for application telemetry such as logs and traces.
- C. This is not a real Snowflake system object; no such default event table exists under this name.
- D. INFORMATION_SCHEMA exposes metadata about database objects, not a destination for log or trace telemetry.
Checkpoint 5 of 6· Exam question
When event sharing is enabled for a Native App, how does telemetry data actually reach the provider's account?
Correct answer: A — Log and trace records written to the consumer's event table are copied to the provider's event table at the same time
- A. Event sharing works by writing matching telemetry to both the consumer's and provider's event tables simultaneously as it is emitted, not through a batch or export process.
- B. There is no daily full-table replication mechanism for event sharing; sharing happens at write time for matching records.
- C. There is no CSV export or stage-based download step involved in event sharing between consumer and provider event tables.
- D. Providers do not directly query consumer event tables through role impersonation; the sharing mechanism writes qualifying events to the provider's own event table instead.
4.Role-aware Streamlit UIs and environment.yml
A grant decides who can open the Streamlit app. Inside the app, you can show different features to different roles with SYS_CONTEXT('SNOWFLAKE$APPLICATION', 'IS_APPLICATION_ROLE_ACTIVATED', ...). It works in an owner's-rights Streamlit app or procedure that belongs to a Native App. The SESSION context checks the user's primary and secondary roles. The ACTIVE context checks the role hierarchy of the current call, which for an owner's-rights procedure is the owner's role. Pass the bare role name, because the function works out the app from where it is called. It returns the string 'TRUE' or 'FALSE'. Under the 2026_06 behaviour change bundle it returns a BOOLEAN, and existing casts still work.
SYS_CONTEXT(
'SNOWFLAKE$APPLICATION' ,
'IS_APPLICATION_ROLE_ACTIVATED' ,
'<context>' ,
'<app_role>'
)Extra Python packages for the Streamlit app are listed in environment.yml, which goes in the stage directory next to the app's main file (for example code_artifacts/streamlit/). For local development of warehouse-runtime apps with conda, Snowflake's Streamlit guide says to use the Snowflake Anaconda channel and block the default channel. The sources here do not list every required top-level property of the file, and do not say what happens to packages from channels hosted outside Snowflake. Check the current Streamlit dependency documentation for those details.
channels:
- https://repo.anaconda.com/pkgs/snowflake
- nodefaultsCheckpoint 6 of 6· Check yourself
An owner's-rights Streamlit page should show an admin panel only to users whose session roles include the app role app_admin. Which call fits?
SESSION checks the user's primary and secondary roles. ACTIVE would check the owner's role of the owner's-rights call. The role name must not include the app name.
“SESSION: Checks if the application role is in the role hierarchy of the current session’s primary or secondary roles.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Debug mode is the right place to create new objects inside the app while testing.Why is that wrong?
Objects created in debug mode are owned by your primary role, not the app. Session debug mode creates them with the app's privileges.
2.IS_APPLICATION_ROLE_ACTIVATED needs the fully qualified role name, such as my_app.app_admin.Why is that wrong?
Pass the bare role name. The function works out the application from the context it is called in.
Covered in Role-aware Streamlit UIs and environment.yml
Practise it for real
Use the three local testing modes on a development-mode app named hello_snowflake_app
1.Run DESC APPLICATION hello_snowflake_app; and note the schemas listed
Why: Development mode shows only what the consumer's application roles allow
You should see: Only schemas granted to application roles
2.Run ALTER APPLICATION hello_snowflake_app SET DEBUG_MODE = TRUE; then run DESC again
Why: Debug mode exposes every object in the app
You should see: All schemas in the app, including ungranted ones
3.Turn debug mode off with SET DEBUG_MODE = FALSE, then run SELECT SYSTEM$BEGIN_DEBUG_APPLICATION( 'hello_snowflake_app', execution_mode = 'AS_SETUP_SCRIPT')
Why: Lets you rerun setup-script statements with the setup script's own privileges, scoped to this session
You should see: Session debug mode is active in this worksheet only
4.Run SELECT SYSTEM$GET_DEBUG_STATUS(); then SELECT SYSTEM$END_DEBUG_APPLICATION();
Why: Confirms the session state and then exits it
You should see: The status reports the debug session, and after ending it the session returns to normal
Stuck? Get a nudge
If ALTER APPLICATION fails, check that your role has OWNERSHIP on the app and DEVELOP on the application package.
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/developer-guide/native-apps/installing-testing-applicationOfficial docs
“With the Snowflake Native App Framework, providers can use the following modes to create an app and test its functionality:”
↩︎ Testing locally: development mode and debug mode“This enables you to quickly test changes to the setup script or application logic.”
↩︎ Testing locally: development mode and debug mode“You must also have the DEVELOP privilege on the application package.”
↩︎ Testing locally: development mode and debug mode“Unlike debug mode, session debug mode only applies to the current session to reduce security risks.”
↩︎ Session debug mode and its execution contexts“AS_SETUP_SCRIPT: all statements are executed using the same privileges as the setup script has when it is run in the consumer account”
↩︎ Session debug mode and its execution contexts“When a provider creates objects, such as a table, using session debug mode, the object is created with the same privileges as the app.”
↩︎ Exam trap 1“Because the session’s primary role is used, objects created in debug mode are not owned by the app.”
↩︎ Prediction“Debug mode can only be toggled on and off for an app created in development mode within the same account containing the application package.”
↩︎ Checkpoint“can only access objects granted to application roles, similar to the consumer perspective.”
↩︎ Checkpoint - 2.
“'AS_APPLICATION' (DEFAULT) All statements are executed as using the same privileges as the app.”
↩︎ Session debug mode and its execution contexts - 3.https://docs.snowflake.com/en/sql-reference/functions/sys_context_snowflake_applicationOfficial docs
“TRUE if the application is in development mode; otherwise, FALSE.”
↩︎ Session debug mode and its execution contexts“A stored procedure or Streamlit app that is configured to use owner’s rights and is within or owned by a Snowflake Native App.”
↩︎ Role-aware Streamlit UIs and environment.yml - 4.
“The privileges field (block, optional) defines the privileges that the Snowflake Native App requests in a consumer account.”
↩︎ Requesting app privileges and granting with SQL“include as much information as possible about why the Snowflake Native App needs this privilege”
↩︎ Requesting app privileges and granting with SQL“This version of the manifest file provides support for additional features, including automated granting of privileges.”
↩︎ Requesting app privileges and granting with SQL - 5.
“This example creates a Streamlit object within a schema named app_schema.”
↩︎ Requesting app privileges and granting with SQL“The environment.yml file must be at the same level as your main file of your Streamlit app.”
↩︎ Role-aware Streamlit UIs and environment.yml - 6.
“ACTIVE: Checks if the application role is in the role hierarchy in the context of the current call.”
↩︎ Role-aware Streamlit UIs and environment.yml“Do not qualify the role name with the name of the application.”
↩︎ Exam trap 2“SESSION: Checks if the application role is in the role hierarchy of the current session’s primary or secondary roles.”
↩︎ Checkpoint - 7.https://docs.snowflake.com/en/developer-guide/streamlit/app-development/dependency-managementOfficial docs
“Identify the Snowflake Anaconda Channel by its URL: https://repo.anaconda.com/pkgs/snowflake.”
↩︎ Role-aware Streamlit UIs and environment.yml