What you will be able to do
- Assess the risk of an external share from the provider's point of view: what consumers can see, when, and how to revoke it
- Share only secure objects and check exactly what a consumer account will see before adding it
- Run a mitigation lifecycle in the Trust Center and produce posture evidence for auditors
1.How a share exposes data to an external partner
To assess a data sharing agreement, start with how Secure Data Sharing works. No data is copied between accounts. Consumers query your objects through Snowflake's services layer, and everything they import is read-only. Shares are controlled entirely by the provider account. You choose which objects to grant and which accounts to add, and access to a share or any object in it can be revoked at any time. The live connection also cuts the other way. Any new object or update you make is visible to every consumer immediately, so one careless grant reaches every partner on that share at once.
The way you share also changes the risk. Partners that don't have a Snowflake account can be given reader accounts. A reader account belongs to the provider that created it, can only consume that provider's data, and can't load or modify data. Keep in mind that the Trust Center doesn't support reader accounts, so you can't scan them for misconfigurations. If you share through listings, data exchanges or Snowflake Marketplace, you get metrics on consumer usage and on the consumer accounts accessing your listings, which you can use to monitor partners.
| Mechanism | What it does | Risk-relevant property |
|---|---|---|
| Direct Share | Shares specific database objects with another account in your region | Granular grants. You add each consumer account yourself |
| Listing | Offers a share plus metadata as a data product | Provides metrics on consumer usage |
| Data Exchange | Offers a share to a group of accounts you set up and manage | Membership is managed as a group |
| Clean room | Shares data while controlling which queries can run | Limits what consumers can compute |
Checkpoint 1 of 6· Check yourself
A partner relationship ends and you need to cut off their access to shared data. Which statement is correct?
No data is copied to the consumer, and the provider controls the share completely, so revoking access takes effect on the provider's side.
“Access to a share (or any of the objects in a share) can be revoked at any time.”Source: docs.snowflake.com
Sources1
2.Sharing secure views and checking what each consumer sees
The main control a provider has is choosing what goes into the share. Snowflake strongly recommends sharing secure views or secure UDFs rather than sharing tables directly. The pattern it documents keeps the base table in a private schema and the secure view in a public schema, and shares only the public schema and the secure object. If different partners should see different rows, a mapping table in the private schema links an access ID to each consumer account, and the view filters on CURRENT_ACCOUNT().
create or replace secure view mydb.public.paid_sensitive_data as select name, date, time, bid_price, ask_price, bid_size, ask_size from mydb.private.sensitive_data sd join mydb.private.sharing_access sa on sd.access_id = sa.access_id and sa.snowflake_account = current_account();Check the share before any partner gets access. Set the SIMULATED_DATA_SHARING_CONSUMER session parameter to a consumer account name, then query the view to see exactly what that account will see. After you grant objects to the share, run SHOW GRANTS to confirm what the share holds. Only after both checks do you add consumer accounts. Creating a share requires ACCOUNTADMIN or a role with the global CREATE SHARE privilege, which you should keep in mind when reviewing who can expose data externally.
alter session set simulated_data_sharing_consumer=<account_name>; select * from mydb.public.paid_sensitive_data;Checkpoint 2 of 6· Put it in order
Put the steps for safely sharing filtered data with a partner in order
- 1.Create the base table and the mapping table in the private schema
- 2.Add the consumer accounts to the share
- 3.Validate the view's filtering with SIMULATED_DATA_SHARING_CONSUMER
- 4.Grant the database, schema and secure view to the share, then confirm with SHOW GRANTS
- 5.Create the secure view in the public schema
- 6.Create the share
Validating before you create the share, and confirming grants before you add accounts, means no partner sees data until both checks have passed.
“Validate the tables and secure view to ensure the data is filtered properly by account.”Source: docs.snowflake.com
Checkpoint 3 of 6· Fill the gap
Which keyword completes the statement that gives partner accounts access to the share?
alter share mydb_shared set ? = <consumer_accounts>;ALTER SHARE ... SET ACCOUNTS sets which consumer accounts can access the share. Run it last, after the contents have been checked.
Source: docs.snowflake.comSources2
3.Sharing data protected by masking and row access policies
Sometimes a partner needs to see sensitive data that is protected by a masking or row access policy. The documented way to do this is a shared database role. The provider writes the policy so that it calls IS_DATABASE_ROLE_IN_SESSION to check for the shared database role, or for a mapping-table column that holds it. The database role must be created in the same database as the protected table, granted to the share, and that database shared with the consumer. When the consumer creates a database from the share, the database roles in it are granted to the role that created the database.
This setup can fail in two ways during an assessment. On the consumer side, the shared database has to be active in the session, either through USE DATABASE or a fully qualified object name. Otherwise consumer users can't access the policy-protected data. On the provider side, when the policy or view isn't shared and the database role lives in a different database, the function evaluates to False. That denies access silently instead of raising an error.
Checkpoint 4 of 6· Check yourself
A consumer with the right shared database role gets no access to policy-protected rows when querying from a worksheet that has a different database in use. What is the most likely cause?
The consumer has to activate the shared database with USE DATABASE or a fully qualified name. Until then, the shared database role isn't in the session and the policy condition fails.
“If you do not specify this shared database, users in the consumer account cannot access shared data that is protected by a policy.”Source: docs.snowflake.com
Sources3
4.Implementing and monitoring mitigation in the Trust Center
Once risks are ranked, mitigation in Snowflake follows the Trust Center's violation lifecycle. A violation is a scanner finding for a configuration that persists until it is changed. You remediate it by changing that configuration, using the remediation guidance the Trust Center gives for each violation. While the work is in progress, the Violations tab lets you triage findings, record evidence or progress notes, and resolve or reopen violations with a justification for auditors. Setting a violation to Resolved suppresses its email notifications. It doesn't fix the underlying misconfiguration.
Monitoring confirms the fix worked. A remediated violation stays on the Violations tab until the next scheduled run of its scanner package starts, or until you run the package on demand. You can also set up proactive notifications so new risks reach you without you having to check. For reporting, the Account posture section on the Overview tab groups violations as newly opened, remediated, increased, decreased, unchanged or muted, and generates a PDF posture report. The report is a point-in-time record you can hand to auditors and management who don't use your account.
Checkpoint 5 of 6· Check yourself
You enforced MFA for all password users an hour ago, but the MFA violation is still listed. What explains this, and what can you do?
Scanners re-evaluate on their schedule. Running the package on demand confirms the fix sooner than waiting.
“After you remediate a violation, the violation still appears in the Violations tab until the next scheduled run of the scanner package”Source: docs.snowflake.com
Mitigation also has a customer side that Snowflake's certifications don't cover. For PCI DSS, for example, Snowflake states that some compliance responsibilities fall to customers outside those Snowflake manages. The controls the scanners check, such as MFA enrolment, network policies and least-privilege roles, are configurations the customer has to set up and maintain.
Checkpoint 6 of 6· Exam question
A security operations group needs analysts to see Trust Center violations, detections and account posture, but analysts must not change scanner schedules or violation status. What is the correct grant?
Correct answer: A — Grant the SNOWFLAKE.TRUST_CENTER_VIEWER application role to the analysts' role, which allows viewing findings without scanner management rights
- A. Correct: TRUST_CENTER_VIEWER is the read-only application role for violations, detections and posture, so it matches least privilege for analysts.
- B. Incorrect: access to Trust Center is governed by its application roles, not by SECURITYADMIN, which would also add unrelated user and grant management powers.
- C. Incorrect: IMPORTED PRIVILEGES exposes shared SNOWFLAKE database views such as ACCOUNT_USAGE, but does not grant the Trust Center application roles.
- D. Incorrect: TRUST_CENTER_ADMIN carries full management including schedules and violation lifecycle, and there is no per-package USAGE revoke that reliably narrows it.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Adding an object to an existing share only affects consumers after they refresh or re-accept the share.Why is that wrong?
Shares are live. New objects and updates reach every consumer on the share immediately, so each grant is a release to all partners at once.
2.Marking a violation Resolved remediates the risk.Why is that wrong?
Resolving a violation only manages its lifecycle and suppresses notifications. The misconfiguration stays in place until you change it.
Covered in Implementing and monitoring mitigation in the Trust Center
Practise it for real
Share a filtered secure view with a partner account, and check what that partner sees before granting access
1.As SYSADMIN, create mydb.private.sensitive_data and mydb.private.sharing_access, then insert a mapping row that links an access_id to the partner's account name
Why: The mapping table decides which rows each consumer account can see, and it stays in the unshared private schema
You should see: Both tables exist only in the private schema
2.Create the secure view mydb.public.paid_sensitive_data that joins on sa.snowflake_account = current_account()
Why: Snowflake recommends sharing secure views rather than base tables
You should see: Querying the view as the provider returns only the rows mapped to your own account
3.Run alter session set simulated_data_sharing_consumer=<account_name>; then query the view
Why: Shows exactly what the partner will see before any access exists
You should see: Only the partner's mapped rows are returned
4.As ACCOUNTADMIN, create the share mydb_shared and grant usage on mydb, usage on mydb.public, and select on the view to the share
Why: Only the public schema and the secure object should be in the share
You should see: The statements succeed with no grants on the private schema
5.Run show grants to share mydb_shared;
Why: Confirms the share contains nothing beyond what you intended
You should see: The database, the public schema and the view, which is listed as a table
6.Run alter share mydb_shared set accounts = <consumer_accounts>;
Why: Access is granted only after the share's contents are checked
You should see: The partner account can now create a database from the share
Stuck? Get a nudge
If the simulated query returns no rows, check that the account name in sharing_access is in uppercase, as the sample script requires.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Shares are secure, configurable, and controlled completely by the provider account:”
↩︎ How a share exposes data to an external partner“All database objects shared between accounts are read-only”
↩︎ How a share exposes data to an external partner“a reader account can only consume data from the provider account that created it.”
↩︎ How a share exposes data to an external partner“you have access to various metrics about consumer usage of your listings, and metrics about the consumer accounts accessing your listings.”
↩︎ How a share exposes data to an external partner“New objects added to a share become immediately available to all consumers, providing real-time access to imported data.”
↩︎ Exam trap 1“New objects added to a share become immediately available to all consumers, providing real-time access to imported data.”
↩︎ Prediction“Access to a share (or any of the objects in a share) can be revoked at any time.”
↩︎ Checkpoint - 2.
“Snowflake strongly recommends sharing secure views and/or secure UDFs instead of directly sharing tables.”
↩︎ Sharing secure views and checking what each consumer sees“Only the public schema and secure object are shared.”
↩︎ Sharing secure views and checking what each consumer sees“Set this session parameter to the name of the consumer account you wish to simulate access for.”
↩︎ Sharing secure views and checking what each consumer sees“you should use the SHOW GRANTS command to confirm the objects in the share have the necessary privileges.”
↩︎ Sharing secure views and checking what each consumer sees“Validate the tables and secure view to ensure the data is filtered properly by account.”
↩︎ Checkpoint - 3.
“The provider defines the policy to call the IS_DATABASE_ROLE_IN_SESSION function to evaluate the shared database role”
↩︎ Sharing data protected by masking and row access policies“Create the database role in the same database as the protected table.”
↩︎ Sharing data protected by masking and row access policies“When these objects are not shared and the database role is defined in a different database, the function evaluates to False.”
↩︎ Sharing data protected by masking and row access policies“If you do not specify this shared database, users in the consumer account cannot access shared data that is protected by a policy.”
↩︎ Checkpoint - 4.
“Resolve or reopen violations for any reason and record justification for audit needs.”
↩︎ Implementing and monitoring mitigation in the Trust Center“Email notifications are suppressed for resolved violations.”
↩︎ Implementing and monitoring mitigation in the Trust Center“You can also use the Trust Center to configure proactive notifications that help you monitor your account for security risks.”
↩︎ Implementing and monitoring mitigation in the Trust Center“Suppression prevents more notifications while you work to remediate the underlying misconfigurations.”
↩︎ Exam trap 2“After you remediate a violation, the violation still appears in the Violations tab until the next scheduled run of the scanner package”
↩︎ Checkpoint - 5.
“The PDF is a self-contained, point-in-time record of the period you select, which makes it useful for compliance evidence”
↩︎ Implementing and monitoring mitigation in the Trust Center - 6.
“there are PCI compliance responsibilities that fall to customers outside of those managed by Snowflake”
↩︎ Implementing and monitoring mitigation in the Trust Center