What you will be able to do
- Explain why a provider shares secure views and secure UDFs instead of base tables, and what a secure object does and does not hide
- Build a per-account secure view in a private/public schema layout and check it with SIMULATED_DATA_SHARING_CONSUMER
- Choose a listing visibility and access option, and know when a listing needs auto_fulfillment
- State what a reader account can consume
Key concept
Secure object as the sharing boundary — In a share or a listing, consumers query the shared data directly. The protection has to be built into the shared object itself, so the provider exposes secure views and secure UDFs, not raw tables.
1.Shares, listings, reader accounts and clean rooms: who can query what
Snowflake gives a provider several ways to collaborate, and the security question is the same for each one: what can the other party actually run against my data? A listing is not a separate mechanism. It is Secure Data Sharing with extra features on top, and it keeps the same provider and consumer roles. Both shares and listings give the consumer direct query access to whatever objects the provider puts in the share. A Data Clean Room works differently. The data provider decides which analyses may run, so other collaborators get insights without unrestricted access to the data. That difference determines where your controls go. With a share or a listing, the controls go into the shared objects. With a clean room, they go into the approved analyses.
Data sharing works only between Snowflake accounts. To reach a partner who has no Snowflake account, the provider can create a reader account. A reader account belongs to the provider account that created it and can consume data only from that provider. Users in a reader account can query the data imported into it, but they cannot run the DML tasks a full account allows, such as loading, inserting or updating data. A reader account is therefore a closed, read-only channel back to a single provider. It cannot serve as a general-purpose account that collects shares from several vendors.
| Mechanism | What the other party can do |
|---|---|
| Share | Directly query the shared data |
| Listing | Directly query the share attached to the listing; same provider and consumer model as Secure Data Sharing |
| Data Clean Room | Run only the analyses the data provider makes available; no unrestricted access to the data |
Checkpoint 1 of 6· Check yourself
A provider created a reader account for a partner that has no Snowflake account. Which statement about that reader account is correct?
A reader account belongs to the provider that created it and can consume only that provider's data. Its users also cannot perform DML such as data loading.
“a reader account can only consume data from the provider account that created it”Source: docs.snowflake.com
Checkpoint 2 of 6· Exam question
A governance team plans to call `SNOWFLAKE.DATA_PRIVACY.GENERATE_SYNTHETIC_DATA` on several source tables to produce shareable test data. Which source table can the procedure NOT use as input?
Correct answer: B — An Apache Iceberg table registered in the account, because generation accepts only native Snowflake tables as input
- A. Inputs up to about 14 million rows are supported, so 10 million rows is within bounds with no pre-sampling required.
- B. Apache Iceberg, external and hybrid tables (and streams) are not supported inputs, so a call against one cannot generate output.
- C. The limit is 100 columns per input table, so a 90-column table is accepted.
- D. The documented floor is 20 distinct rows, not 100, so a table with 25 distinct rows is acceptable input.
2.Secure views, UDFs and procedures as the sharing boundary
The SECURE keyword does two separate jobs. The first is hiding the definition. For a secure UDF or procedure, only roles that own the object can see its body, imports, handler name and packages. Everyone else still sees its signature. This applies everywhere a definition could show up: SHOW and DESCRIBE commands, the Information Schema views, Query Profile and GET_DDL. Secure functions and procedures with Java, Python or Scala handlers also run in separate sandboxes that share no resources.
| Hidden from unauthorized users | Still visible |
|---|---|
| Body (handler code) | Parameter types |
| List of imports | Return type |
| Handler name | Handler language |
| Packages list | Null handling and volatility |
The second job is protecting the data. Optimizations such as filter pushdown can reorder filters so that a general filter runs before the filter that secures the data, and that can leak information about rows the user cannot see. Secure UDFs skip those optimizations. The cost is performance, so make a UDF secure when it exists for data privacy, not when it exists for query convenience. Apply the same rule consistently: if secure UDFs guard a table, any views over that table should probably be secure too. Even a secure object can leak through its design. Sequence-generated IDs can reveal how many rows were created between two visible rows, so either leave them out or use randomized identifiers such as UUID_STRING. Snowflake does not report bytes or micro-partitions scanned for queries that contain secure functions.
Sharing adds one specific behaviour. When a secure UDF is shared with other accounts, CURRENT_ROLE and CURRENT_USER return NULL, because the provider does not control the consumer's users or roles. To authorize rows by consumer, use CURRENT_ACCOUNT. The recommended layout is a private schema holding the base table and a mapping table of account to access_id, plus a public schema holding the secure view. Only the public schema and the secure view go into the share. Before you share, set the session parameter SIMULATED_DATA_SHARING_CONSUMER to a consumer account name, then query the view to see exactly what that consumer will see.
Checkpoint 3 of 6· Put it in order
Put the provider's steps for sharing row-filtered data through a secure view in order
- 1.Create the paid_sensitive_data secure view in the public schema
- 2.Create the share and grant only the public schema and secure view to it
- 3.Set SIMULATED_DATA_SHARING_CONSUMER and query the view to validate the filtering
- 4.Create sensitive_data and the sharing_access mapping table in the private schema
The documented sequence builds the private tables, then the secure view over them, then validates the per-account filtering by simulating a consumer, and only then creates the share.
“Set this session parameter to the name of the consumer account you wish to simulate access for.”Source: docs.snowflake.com
Checkpoint 4 of 6· Check yourself
A shared secure UDF filters rows with WHERE owner_role = CURRENT_ROLE(). Consumers report that they see no rows. What is the fix?
In a shared secure UDF, CURRENT_ROLE and CURRENT_USER return NULL. CURRENT_ACCOUNT is the documented way to authorize rows for a consumer account.
“the CURRENT_ACCOUNT function can be used to authorize users from a specific account to access rows in a base table”Source: docs.snowflake.com
3.Configuring listings: visibility, access and cross-region fulfillment
The data product of a listing is the share or app attached to it. Configuring a listing comes down to two decisions. The first is visibility. A private listing reaches specific consumers in any Snowflake region. A public listing appears on the Snowflake Marketplace, so you can serve many consumers without maintaining a separate sharing relationship with each one. The second is access: free, limited trial or paid. Listings also add metadata, such as a title, description and sample SQL, and they let you monitor interest in the listing and use of the shared data. That monitoring gives you visibility into who is using what you share.
| Access option | Where offered | Key constraint |
|---|---|---|
| Free | Privately or on the Snowflake Marketplace | Instant access to the full published dataset |
| Limited trial | Snowflake Marketplace | Availability period of 1 to 90 days; the provider chooses who later gets full access |
| Paid | Privately or on the Snowflake Marketplace | Only available to consumers in specific regions, and from providers in specific regions |
Limited trial listings suit customer-specific data, or cases where licensing or regulatory requirements mean only certain consumers may buy. Anyone can try the product, but the provider decides who gets full access. Reaching consumers in other regions is a manifest setting. Cross-Cloud Auto-fulfillment automatically fulfills the data product to other regions, and the manifest's auto_fulfillment field controls how. The organization listing manifest reference says auto_fulfillment is required for a private listing shared across regions and should not be enabled when every account is in the same region. If you set auto_fulfillment.refresh_schedule in minutes, it must be between 10 minutes and 8 days (11520 minutes).
Checkpoint 5 of 6· Check yourself
A provider scripts a private listing whose consumers are in two other regions. What should the manifest contain?
Auto-fulfillment is required for a private listing shared across multiple regions. The minimum refresh_schedule is 10 minutes, so 5 MINUTE is invalid.
“Required if your data product is shared through a private listing.”Source: docs.snowflake.com
Checkpoint 6 of 6· Exam question
A provider generates synthetic `customers` and `orders` tables for a partner with two separate `GENERATE_SYNTHETIC_DATA` calls. The partner reports that `customer_id` values in the outputs no longer join. Which change restores joinability while keeping the data synthetic?
Correct answer: D — Set `join_key` to true for `customer_id` in both table configurations and supply the same `consistency_secret` to each call
- A. Overwriting only replaces the previous output tables; each run still generates independent values, so the keys will still disagree.
- B. The categorical flag controls how string columns are modeled; it does not synchronise generated values between two separate output tables.
- C. The similarity filter removes output rows that are too close to the input, which protects privacy but does nothing to align key values across tables.
- D. Marking the column as a join key with a shared consistency secret makes the generator map identical source values to identical synthetic values across tables and runs.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Marking a Java or Python UDF SECURE also locks down the stages it imports files from.Why is that wrong?
SECURE hides the imports list in the definition but does nothing to the stages themselves. Stage access has to be controlled separately.
Covered in Secure views, UDFs and procedures as the sharing boundary
2.A shared secure UDF can filter rows by the consumer's CURRENT_ROLE or CURRENT_USER.Why is that wrong?
Both functions return NULL in a secure UDF shared with other accounts. Authorize by CURRENT_ACCOUNT instead.
Covered in Secure views, UDFs and procedures as the sharing boundary
3.A reader account can collect shares from several vendors once the partner has it.Why is that wrong?
A reader account belongs to the provider that created it and can consume data only from that provider.
Covered in Shares, listings, reader accounts and clean rooms: who can query what
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“With a share or a listing, the consumer can directly query the shared data.”
↩︎ Shares, listings, reader accounts and clean rooms: who can query what - 2.
“A listing is an enhanced method of Secure Data Sharing and uses the same provider and consumer model.”
↩︎ Shares, listings, reader accounts and clean rooms: who can query what“share data and other information directly with other Snowflake accounts in any Snowflake region”
↩︎ Configuring listings: visibility, access and cross-region fulfillment“Providers can set the availability period for limited trial listings from 1 to 90 days.”
↩︎ Configuring listings: visibility, access and cross-region fulfillment - 3.
“cannot perform any of the DML tasks that are allowed in a full account”
↩︎ Shares, listings, reader accounts and clean rooms: who can query what“a reader account can only consume data from the provider account that created it”
↩︎ Exam trap 3“a reader account can only consume data from the provider account that created it”
↩︎ Checkpoint - 4.
“the Snowflake query optimizer, when evaluating secure UDFs, bypasses the optimizations used for regular UDFs.”
↩︎ Secure views, UDFs and procedures as the sharing boundary“Define a UDF as secure when it is specifically designated for data privacy”
↩︎ Secure views, UDFs and procedures as the sharing boundary“Using the SECURE keyword does not have any effect on the visibility of or access to those stages.”
↩︎ Exam trap 1“Snowflake returns a NULL value for these functions”
↩︎ Exam trap 2“Using the SECURE keyword does not have any effect on the visibility of or access to those stages.”
↩︎ Prediction“the CURRENT_ACCOUNT function can be used to authorize users from a specific account to access rows in a base table”
↩︎ Checkpoint - 5.
“Only the public schema and secure object are shared.”
↩︎ Secure views, UDFs and procedures as the sharing boundary“Snowflake strongly recommends sharing secure views and/or secure UDFs instead of directly sharing tables”
↩︎ Key concept“Set this session parameter to the name of the consumer account you wish to simulate access for.”
↩︎ Checkpoint - 6.https://docs.snowflake.com/en/user-guide/collaboration/listings/organizational/org-listing-manifest-referenceOfficial docs
“Do not enable it if you are sharing to accounts in the same region.”
↩︎ Configuring listings: visibility, access and cross-region fulfillment“Minimum 10 minutes, maximum 8 days, or 11520 minutes.”
↩︎ Configuring listings: visibility, access and cross-region fulfillment“Required if your data product is shared through a private listing.”
↩︎ Checkpoint