6.4 Secure Views, Cross-Region Sharing, and Governance

Why Secure Views and Secure UDFs Matter for Sharing

When you expose data through a share, you usually do not want to share raw base tables — you want a curated, filtered view. A secure view (and, for functions, a secure UDF) is the right choice when the consumer must not see how the data is derived. The reason is data protection:

• A standard view exposes its SQL definition to anyone who can describe it, and the optimizer may push predicates into the view in ways that let a consumer infer hidden rows of the base table.
• A secure view hides its definition (the consumer cannot see the underlying SQL or base-table names) and disables those optimizations that could leak data, so users only ever see what the view explicitly returns.

The tradeoff is performance: secure views forgo some query optimizations, so they can be slower than equivalent standard views. The exam expects you to know this cost is accepted in exchange for security. Snowflake's current list of shareable objects also includes regular views and non-secure UDFs, so secure objects are a protection choice, not a requirement.

Cross-Region and Cross-Cloud Sharing

Native Secure Data Sharing operates within a single region on a single cloud. To share data with an account in a different region or on a different cloud (AWS, Azure, or Google Cloud), the provider uses a listing with cross-cloud auto-fulfillment or database replication:

1. Enable replication on the source database.
2. Create a replica of the database in the target region/cloud and refresh it on a schedule.
3. Create a share from the replica and add the remote consumer.

Marketplace listings wrap this process in auto-fulfillment, so providers do not script replication manually for each consumer region. The key tested distinction: direct shares = same region only; replication (or a listing built on it) = cross-region/cross-cloud. A common trap answer claims a direct share can reach another cloud without replication — it cannot.

Governance follows the data

Sharing does not bypass governance. Masking policies (column-level dynamic data masking), row access policies (row-level filtering), and object tagging all continue to apply to shared objects. So a provider can share one secure view to many consumers while a masking policy redacts PII columns and a row access policy limits each consumer to its own rows. Because consumers get read-only access, they cannot disable these controls.

Data Clean Rooms and Discovery

A Data Clean Room is a secured, privacy-preserving environment in which two or more parties can analyze their combined data without either party seeing the other's raw, row-level data. It is built on Secure Data Sharing plus governance controls (secure functions, row access policies, query templates) that allow only approved, aggregate queries to run against the joined dataset. The classic use case is advertising overlap analysis: a brand and a publisher measure shared audiences without exchanging customer identities.

Key points for the exam:

• Clean rooms protect raw data from exposure while still enabling joint analytics.
• They rely on secure objects and policy controls to restrict which queries are permitted.
• No party copies the other's underlying data — it remains governed by Secure Data Sharing.

Listing discovery

Consumers discover data through Marketplace search and categories, listing metadata (title, description, sample SQL, usage examples, refresh cadence, and provider profile), and request workflows. Strong metadata is what makes a listing findable, so providers are expected to document their datasets thoroughly. For private collaboration, the same discovery experience exists inside a Data Exchange, scoped to invited members only.

Governance of Shared Data in Practice

Governance is where many candidates lose points, because they assume sharing is an all-or-nothing handoff. It is not. A provider can expose exactly the slice each consumer should see by layering controls on top of a single shared object:

• Secure views restrict which columns and rows are returned and hide the SQL definition.
• Masking policies apply column-level dynamic masking, so PII columns are redacted at query time based on the querying role.
• Row access policies filter rows so each consumer sees only the records permitted to them — for example, only their own region's sales.
• Object tagging classifies sensitive columns and can drive policy assignment and auditing.

Because consumers receive read-only access, they cannot alter or remove any of these controls. This lets one provider safely fan out the same dataset to many consumers with different visibility. A frequent exam scenario describes a provider who must share a customer table but hide tax IDs from external consumers; the correct answer combines a secure view with a masking policy, not a second physical copy of the table.

Distinguishing the protection mechanisms

Knowing which control operates at which granularity lets you pick the precise answer when a stem asks how to protect a column versus restrict rows versus hide a view definition. These controls travel with the data into every share, listing, and clean room.