SNOWPRO-CORE-C03 Practice Questions: Data Collaboration Domain

Correct answer (A): Snowflake supports cross-region and cross-cloud data sharing via replication. By replicating the provider's database to Azure West Europe and then sharing it to the customer's Azure account, the customer can query a local replica using its own compute while the provider maintains a single logical data source without export/import pipelines.

Why the other options are wrong:
- Option B: Manual export/import into cloud storage violates the requirement to avoid such pipelines and breaks the single logical source-of-truth model that Snowflake's replication and sharing can provide.
- Option C: Reader accounts in the provider's AWS region force the customer to query data outside their Azure environment and bill compute to the provider, which conflicts with the requirement that compute be billed to the customer in their own Snowflake deployment.
- Option D: Requiring the customer to move to AWS us-east-1 ignores their existing Azure deployment and does not use Snowflake's built-in cross-cloud collaboration capabilities.

Correct answer (C): A direct secure data share between two full Snowflake accounts in the same region provides near real-time access without copying or exporting data. It supports a private, one-to-one relationship, where the provider exposes specific tables or secure views to a known consumer without making the data discoverable to others, and avoids ETL or file movement by using metadata pointers to the provider’s data.

Why the other options are wrong:
- Option A: Incorrect because Snowflake Marketplace is designed for discoverable listings to a broader or curated audience. Publishing a public listing conflicts with the requirement for a private, one-to-one arrangement.
- Option B: Incorrect because exporting to cloud storage and re-loading introduces file movement and ETL-like processes, which the scenario explicitly wants to avoid and which reduce near real-time access.
- Option D: Incorrect because reader accounts are intended for consumers who do not have their own Snowflake account. Here, the logistics partner already has a Snowflake account, so a direct secure share is the appropriate mechanism.

Correct answer (B): Secure views and secure UDFs are specifically designed so that consumers cannot access base objects or underlying logic directly. By sharing only secure views and secure UDFs in a listing, the provider can restrict columns, encapsulate business logic, and prevent customers from bypassing the governed interface.

Why the other options are wrong:
- Option A: Sharing base tables directly exposes the underlying schema and makes it harder to fully hide sensitive fields or internal logic, especially if column grants are misconfigured. It does not provide the same protection as secure views and secure UDFs.
- Option C: Publishing the full database contradicts the requirement to hide certain columns and business logic, shifting responsibility to customers rather than enforcing central governance.
- Option D: This approach bypasses Snowflake’s native data sharing and listing model. Using external files removes the benefits of governed, near real-time access and does not address protecting internal logic in a Snowflake-native way.

Correct answer (B): Marketplace listings provide a centralized way to publish a data product, manage who can access it (via public or private listings), and track adoption. Combined with database replication into target regions, they enable cross-region and cross-cloud access without relying on manual file exports, aligning with a globally distributed commercial data product.

Why the other options are wrong:
- Option A: Direct shares are limited to accounts within the same region and generally do not span regions or clouds without replication. They also do not provide a unified, discoverable product and subscription management experience.
- Option C: Exporting to cloud storage introduces manual file management, breaks near real-time collaboration, and does not provide subscription/auditing capabilities like Marketplace listings.
- Option D: Reader accounts are for consumers without their own Snowflake accounts and are provider-managed and billed. The scenario assumes customers have their own accounts and need self-managed access in their own regions.

Correct answer (A): Secure views are designed so that consumers cannot see or bypass the underlying logic or definitions. By creating secure views that implement masking and sharing only those secure views, the provider ensures that partners can access governed, de-identified data while preventing access to raw identifiers or the ability to circumvent the masking.

Why the other options are wrong:
- Option B: Relying on partners to apply masking in their own accounts does not meet the governance requirement. Partners would still see raw identifiers in the base tables and could choose not to mask them.
- Option C: Non-secure views expose their definitions to consumers, who may be able to derive underlying data or circumvent the intended protections. Sharing base tables alongside views also breaks the governance requirement, as partners could access sensitive columns directly.
- Option D: Exporting CSV files bypasses Snowflake’s data collaboration capabilities and makes governance harder to enforce and audit. The requirement is specifically about controlling what is shared through Snowflake, which secure views address directly.

Correct answer (A): Reader accounts are intended for consumers without Snowflake accounts, where the provider pays for storage and compute. When customers mature and need independent governance and want to pay for their own compute, they should have their own Snowflake accounts. The provider can then share data using secure shares or listings, keeping storage costs with the provider while shifting compute costs to the customers.

Why the other options are wrong:
- Option B: Increasing warehouse size in reader accounts only increases the provider’s compute costs; it does not transition cost responsibility to the customers or give them independent account control.
- Option C: There is no mechanism to simply "convert" reader accounts into full accounts while keeping the provider as the payer of compute. The goal is to make customers responsible for their own compute costs in their own accounts, not to extend provider billing.
- Option D: Abandoning Snowflake collaboration and exporting files adds complexity and removes zero-copy and governance benefits. It also does not meet the requirement to keep using Snowflake’s zero-copy data sharing model.

Correct answer (B): Direct shares are limited to accounts in the same region. To share natively with a partner in a different cloud/region, the provider should replicate the database into a Snowflake account in the partner’s region and then create a share from that replicated data. This preserves Snowflake’s secure sharing model without relying on file exports or forcing the partner to change regions.

Why the other options are wrong:
- Option A: Forcing the partner to create a new account in a different cloud/region is disruptive and unnecessary. Snowflake supports governed cross-region/cross-cloud sharing through replication and sharing or listings.
- Option C: Exporting to files bypasses Snowflake’s data sharing capabilities and adds operational complexity. The requirement is to use Snowflake’s native sharing model, not file-based transfer.
- Option D: Warehouse size affects query performance, not cross-region visibility of shares. Shares do not become cross-cloud-visible by adjusting compute resources.

Correct answer (B): In Snowflake secure data sharing, the underlying data is not copied to the consumer account. A single copy of the data remains in the provider account, and the provider (Account A) is billed for that storage. The consumer (Account B) creates a read-only database pointing to this data and is only billed for the compute used by its own virtual warehouses when querying the shared data.

Why the other options are wrong:
- Option A: Incorrect because Snowflake sharing is metadata-based; the data is not copied into the consumer account, so it does not create additional storage charges for Account B.
- Option C: Incorrect because Snowflake does not split storage billing between accounts. Storage is billed once to the provider that owns the underlying tables.
- Option D: Incorrect because each account pays for its own compute. The provider is responsible for storage costs, not compute on behalf of the consumer.

Correct answer (C): A private data exchange allows an organization to create a curated sharing hub where selected provider and consumer accounts, such as internal BUs, can publish and discover data products in a governed environment that is not publicly visible.

Why the other options are wrong:
- Option A: Public Marketplace listings are visible to many Snowflake customers and are not restricted to internal BUs, which conflicts with the requirement to keep datasets internal.
- Option B: Direct shares allow data access but do not provide a centralized, curated discovery experience across many BUs. They also become harder to manage at scale compared to an exchange.
- Option D: Reader accounts are for consumers without their own Snowflake accounts. Here, each BU already has its own account, and the requirement is for discovery and curation, not provider-managed reader environments.

Correct answer (B): The provider can modify the share definition to remove just the retired table. Since the consumers’ databases are metadata-linked to the provider’s share, the removed table will no longer be accessible to any consumer, while the remaining shared objects stay available.

Why the other options are wrong:
- Option A: Dropping the entire share would revoke access to all shared objects, not just the retired table. This is broader than required and disrupts consumers who still need the other tables.
- Option C: Virtual warehouses are not shared across accounts and are owned by the consumers. The provider cannot disable consumer warehouses, and this would not change which objects are exposed by the share.
- Option D: Consumers’ shared databases are metadata-linked to the provider’s share. The visibility of shared objects is controlled by the provider; consumers cannot keep independent copies of provider-owned shared tables in that shared database when the provider removes them from the share.