What you will be able to do
- Set default log, trace, metric and lifecycle-event levels in the manifest configuration block
- Declare required (MANDATORY) and optional event definitions and predict what consumers can toggle
- Describe the consumer approval workflow for event sharing, including the ALTER APPLICATION clauses
- Set up a provider event account and active event table per region, and explain what event data is shared, masked or omitted
- Restrict a Streamlit app's UI to consumers who hold a given application role
Key concept
Event definitions as filters — The provider's manifest levels decide what an app emits into the consumer's event table. Event definitions then act as a second filter that decides which of those events are copied to the provider. Consumers must accept required definitions and can turn optional ones on or off.
1.Default log and trace levels live in the manifest
An app records nothing until the provider says it should. You set this in the configuration block of manifest.yml, which takes four levels. log_level covers log messages. trace_level covers trace events. metric_level covers CPU and memory metrics for stored procedures and UDFs. log_event_level was added in BCR bundle 2026_02 and covers application lifecycle events (RECORD_TYPE=EVENT) separately from log messages. Snowflake's checklist for providers lists this as a prerequisite: providers must define the default log level and trace level for an app in the manifest file.
configuration:
...
log_level: INFO
trace_level: ALWAYS
metric_level: ALL
log_event_level: INFO
...These levels control what goes into the consumer's own event table. Three cautions follow. First, if you leave the levels unset, the app emits no events. Second, the levels are fixed once the app is published, so changing them means shipping a new version or patch. Third, any trace_level other than OFF records the start and end of every query and procedure call. That can reveal calls to hidden stored procedures to anyone in the consumer account who can read the event table. Apps that use Snowpark Container Services are a special case: the container's telemetry levels are set in the service specification, and the manifest log_level does not reach into containers.
For finer control, you can set levels on individual objects inside the app. Use the SET clause of the ALTER command to set LOG_LEVEL, TRACE_LEVEL and METRIC_LEVEL on a schema, procedure or function. For versioned schemas, set them with CREATE OR ALTER VERSIONED SCHEMA in the setup script.
| Object | Command |
|---|---|
| Schemas | ALTER SCHEMA |
| Versioned schema | CREATE OR ALTER VERSIONED SCHEMA |
| Stored procedures | ALTER PROCEDURE |
| User-defined functions | ALTER FUNCTION |
Checkpoint 1 of 7· Check yourself
A provider published version V1 with trace_level: OFF. Consumers now report slow procedures, and the provider wants traces from V1 installs. What is true?
Published log and trace levels cannot be changed. Event definitions only filter what the levels already allow, so they cannot turn on tracing that the manifest switched off.
“After you publish an app, the log and trace levels cannot be changed.”Source: docs.snowflake.com
Checkpoint 2 of 7· Exam question
Which of the following statements about required and optional events in a Native App's event definitions are correct?(Select 3)
Correct answers: A, B, D — A required event must be approved by the consumer or the app cannot be installed; An optional event can be enabled or disabled by the consumer at any time without blocking installation; Legacy apps that predate event definitions default to an "OPTIONAL ALL" event definition automatically
- A. A required event definition blocks installation until the consumer approves sharing for it, which is what distinguishes it from an optional one.
- B. Optional events do not block installation, and the consumer retains the ability to toggle sharing for them afterward.
- C. Required versus optional status is declared by the provider in the manifest's event definitions, not chosen by the consumer when creating an event table.
- D. Apps built before event definitions existed automatically fall back to an "OPTIONAL ALL" definition so they keep functioning without manifest changes.
- E. Optional events can still be shared with the provider if the consumer chooses to approve sharing for them; the optional label only means approval is not mandatory.
- F. Required event definitions are not restricted to container-based apps; they apply to the general event definition mechanism for Native Apps.
2.Declaring required and optional event definitions
Once the levels let events into the consumer's table, event definitions decide which of them also go to the provider. You list them under configuration.telemetry_event_definitions. Each entry has a type and a sharing mode. MANDATORY makes a definition required, and OPTIONAL leaves it to the consumer.
configuration:
telemetry_event_definitions:
- type: ERRORS_AND_WARNINGS
sharing: MANDATORY
- type: DEBUG_LOGS
sharing: OPTIONAL| Type | Name | Shares |
|---|---|---|
| All | SNOWFLAKE$ALL | All log messages and trace events that the app emits |
| Events | SNOWFLAKE$ALL_EVENTS | All events from the application (RECORD_TYPE EVENT) |
| Errors and warnings | SNOWFLAKE$ERRORS_AND_WARNINGS | Logs with severity FATAL, ERROR or WARN |
| Traces | SNOWFLAKE$TRACES | Spans and span events of user activities |
| Usage logs | SNOWFLAKE$USAGE_LOGS | High-level INFO logs about user actions and app events |
| Debug logs | SNOWFLAKE$DEBUG_LOGS | DEBUG and TRACE technical logs for troubleshooting |
| Metrics | SNOWFLAKE$METRICS | METRIC records |
Event definitions are optional. If you declare none, the consumer gets a single switch for all events, which is the same as the older event sharing feature. That older behaviour is equivalent to an OPTIONAL ALL definition. To move to granular sharing, add definitions to the manifest of a new version or patch; nothing else is needed. One limit applies: apps with Snowpark Container Services currently support only SNOWFLAKE$ALL.
Checkpoint 3 of 7· Match them up
Match each event definition to the records it shares
Tap a term, then the definition that fits it.
Each definition filters on RECORD_TYPE and, for logs, on severity. Debug logs are the troubleshooting tier, and usage logs are the INFO tier.
“Shares technical logs used to troubleshoot the app.”Source: docs.snowflake.com
3.The consumer approval workflow
Required definitions are switched on automatically when the app is installed. Optional ones are the consumer's choice. After installing, the consumer sees the definitions in Snowsight, in the Events and logs tab of the app's Security page. In SQL, AUTHORIZE_TELEMETRY_EVENT_SHARING = TRUE turns on all required definitions but leaves optional ones off. Optional ones are added with SET SHARED TELEMETRY EVENTS. The authorization is one-way: if the app has required definitions, you cannot set it back to FALSE. The consumer's choices also feed back into what the app emits, because Snowflake uses the most verbose log and trace levels that the enabled definitions allow.
ALTER APPLICATION <name> SET SHARED TELEMETRY EVENTS ('<event_definition' [ , <event_definition>, ...])
ALTER APPLICATION <name> SET AUTHORIZE_TELEMETRY_EVENT_SHARING = { TRUE | FALSE }Upgrades need care. If a new version adds required definitions, the provider can check whether the consumer has enabled them all, using system functions or the Python Permission SDK. The end-to-end workflow runs in a fixed order, starting on the provider side and ending with the consumer.
Checkpoint 4 of 7· Put it in order
Put the event sharing setup workflow in order
- 1.The provider sets the log and trace levels for the app
- 2.The provider publishes the app
- 3.The provider sets up an event table in their organization
- 4.The consumer installs the app, sets up an event table and enables event sharing
- 5.The provider adds event definitions to the manifest file
The documented workflow is: levels, then definitions, then the provider event table, then publishing. The consumer opts in only after installing.
“The provider sets the log and trace levels for the app.”Source: docs.snowflake.com
4.Provider event tables, costs and governance
Shared events land in an event table in the provider's own account. For each region, an organization administrator picks an events account by calling SYSTEM$SET_EVENT_SHARING_ACCOUNT_FOR_REGION. That account cannot be locked, suspended, a reader account, a trial account or Snowflake-managed. In the events account, run CREATE EVENT TABLE and then make the table active. An account can have several event tables, but only one can be active, and without an active table any shared events are discarded.
Checkpoint 5 of 7· Fill the gap
Which parameter makes the new table the account's active event table?
ALTER ACCOUNT SET ? =event_db.event_schema.my_event_table;EVENT_TABLE is the account parameter that selects the active event table, and an account can have only one active at a time.
Source: docs.snowflake.comGovernance applies on both sides. The provider pays all provider-side ingestion and storage costs. Consumers write app telemetry to their active event table, which by default is SNOWFLAKE.TELEMETRY.EVENTS. Access to it is controlled by the EVENTS_ADMIN and EVENTS_VIEWER database roles. Before shared events leave the consumer account, sensitive identifiers are masked or removed. For new deployments, Snowflake recommends centralized event sharing: an event routing table sends events from every region to one destination account. If you use it, you are responsible for complying with regulations such as GDPR.
| Treatment | Example fields |
|---|---|
| Shared | APPLICATION_PROVIDER_ORG, LISTING_NAME, SERVICE_NAME |
| Masked (SHA-1) | snow.database.hash, snow.query.hash, snow.application.hash |
| Omitted | snow.warehouse.name, snow.user.name, snow.session.role.primary.name |
Checkpoint 6 of 7· Check yourself
A consumer in AWS_EU_WEST_1 installs an app and enables sharing. The provider has set an events account only for AWS_US_WEST_2. What happens to that consumer's events?
Without centralized sharing, the provider needs an events account in every region where consumers share events. Otherwise the provider's copy is lost, while the consumer's table keeps its local data.
“trace events and log messages from that region are dropped (events access loss for the provider).”Source: docs.snowflake.com
5.Role-based access control in the Streamlit UI
Access to a Streamlit app inside a Native App is controlled with application roles. In the setup script, you create the Streamlit object and grant USAGE on its schema and on the Streamlit object to an application role. Consumers who are granted that application role can open the app. For finer control inside the UI, the app can check which application role the viewer holds and show or hide parts of the page. IS_APPLICATION_ROLE_IN_SESSION checks the consumer's current session. SYS_CONTEXT with IS_APPLICATION_ROLE_ACTIVATED does the same for a context you choose: SESSION or ACTIVE. Pass the role name without the application name.
GRANT USAGE ON STREAMLIT APP_SCHEMA.MY_TEST_APP_NA TO APPLICATION ROLE app_public;SELECT SYS_CONTEXT('SNOWFLAKE$APPLICATION', 'IS_APPLICATION_ROLE_ACTIVATED', 'SESSION', 'my_app_role')::BOOLEAN = TRUE;Do not confuse this with the Python Permission SDK. get_held_account_privileges() reports which manifest-declared privileges the consumer has granted to the app. It says nothing about which application role the viewing user holds. IS_APPLICATION_ROLE_IN_SESSION works only when called from within a Snowflake Native App.
Checkpoint 7 of 7· Check yourself
A Streamlit page should show an admin panel only to viewers who hold the application role ADMIN. Which call fits?
IS_APPLICATION_ROLE_IN_SESSION tests the viewer's session for the application role. get_held_account_privileges only checks privileges granted to the app itself.
“Verifies whether the application role is activated in the consumer’s current session.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A provider can raise the log or trace level of a published version once consumers report a problem.Why is that wrong?
Levels are fixed once published. If they are unset, the app emits nothing, so a new version or patch is required.
Covered in Default log and trace levels live in the manifest
2.A containerized app can request granular definitions such as DEBUG_LOGS, and its manifest log_level controls container logs.Why is that wrong?
Apps with Snowpark Container Services support only SNOWFLAKE$ALL, and container telemetry levels are set in the service specification.
Covered in Declaring required and optional event definitions
3.One provider events account collects shared events from every region automatically.Why is that wrong?
Unless centralized event sharing is used, the provider needs an events account with an active event table in each region where consumers share events.
Covered in Provider event tables, costs and governance
4.Use permissions.get_held_account_privileges() in the Streamlit app to check which role the viewing user holds.Why is that wrong?
It lists privileges granted to the app, not the viewer's application roles. Use IS_APPLICATION_ROLE_IN_SESSION or SYS_CONTEXT for that.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“To allow an app to use event tracing, a provider must configure the log and trace levels in the manifest file.”
↩︎ Default log and trace levels live in the manifest“If neither the log nor tracing levels are set, then the app does not emit any events.”
↩︎ Default log and trace levels live in the manifest“consumers can only enable or disable event sharing for all events when the provider enables event tracing.”
↩︎ Declaring required and optional event definitions“Required event definitions are enabled automatically when the app is installed.”
↩︎ The consumer approval workflow“Snowflake uses the most verbose log and trace levels allowed by the event definitions the consumer has enabled.”
↩︎ The consumer approval workflow“providers can use system functions or the Python Permission SDK to check if the consumer has enabled all required event definitions.”
↩︎ The consumer approval workflow“Event definitions act as filters on the log message and trace event levels set by the provider.”
↩︎ Key concept“After you publish an app, the log and trace levels cannot be changed.”
↩︎ Exam trap 1“The manifest log_level does not propagate into containers.”
↩︎ Exam trap 2“After you publish an app, the log and trace levels cannot be changed.”
↩︎ Checkpoint“Shares technical logs used to troubleshoot the app.”
↩︎ Checkpoint“consumers cannot disable event sharing or the required event definitions.”
↩︎ Prediction - 2.
“might expose calls to hidden stored procedures to any user in the consumer account who can view the event table.”
↩︎ Default log and trace levels live in the manifest - 3.
“Providers must define the default log level and trace level for an app in the manifest file.”
↩︎ Default log and trace levels live in the manifest“The previous event sharing functionality is equivalent to the OPTIONAL ALL event definition.”
↩︎ Declaring required and optional event definitions“Providers are responsible for all costs associated with event sharing on the provider side, including data ingestion and storage.”
↩︎ Provider event tables, costs and governance“Snowflake ships two default database roles for access control: EVENTS_ADMIN (manage row-access policies and delete data) and EVENTS_VIEWER”
↩︎ Provider event tables, costs and governance“The provider sets the log and trace levels for the app.”
↩︎ Checkpoint - 4.
“After setting this value to TRUE, you cannot reset the value back to FALSE if there are required event definitions in the app.”
↩︎ The consumer approval workflow - 5.
“You must use an organization administrator role to set an account as the account used to store events.”
↩︎ Provider event tables, costs and governance“Without an active event table, log messages and trace events that the consumer shares are discarded.”
↩︎ Provider event tables, costs and governance“Fields fall into three categories: shared (visible to the provider), masked (hashed before sharing), and omitted (never leave the consumer account).”
↩︎ Provider event tables, costs and governance“we strongly recommend using centralized event sharing to route events from every region to a single destination account.”
↩︎ Provider event tables, costs and governance“Providers must set up an event account to store shared events in every region where consumers configure event sharing for an app.”
↩︎ Exam trap 3“trace events and log messages from that region are dropped (events access loss for the provider).”
↩︎ Checkpoint - 6.
“you must ensure that your app is compliant with all relevant regulations and standards, such as GDPR, HIPAA, and PCI DSS.”
↩︎ Provider event tables, costs and governance - 7.
“This example also grants the required privileges on the schema and Streamlit object to an application role.”
↩︎ Role-based access control in the Streamlit UI - 8.
“Verifies whether the application role is activated in the consumer’s current session.”
↩︎ Role-based access control in the Streamlit UI - 9.
“Only privileges defined in the manifest file are valid arguments to get_held_account_privileges().”
↩︎ Role-based access control in the Streamlit UI“obtain a list of privileges that have been granted to the Snowflake Native App.”
↩︎ Exam trap 4