ADA-C01 Question 435
Single answerGiven a scenario, implement sharing solutionsA data platform team at a provider account needs to share a curated SALES database with three external partner companies. Each partner should see the same secure views over the base tables, but each partner must only see rows for its own REGION. The provider wants to avoid copying data, minimize operational overhead as new partners are onboarded, and allow consumers to query the shared data from their own warehouses. Which implementation best meets these requirements?
- A
Create a separate database clone for each partner, grant access to the clone, and use masking policies in each clone to filter rows by REGION.
- B
Create a direct share on the SALES database, expose secure views that reference a mapping table in the provider account, and rely on CURRENT_ACCOUNT() in the secure views to apply row-level filtering for each consumer account.
- C
Create reader accounts for all partners, load partner-specific data into separate schemas, and require all partners to use provider-managed virtual warehouses.
- D
Create a data exchange listing for the SALES database and use standard views with session variables set by the consumer to restrict rows by REGION.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use Secure Data Sharing with secure views that enforce row-level filtering based on the consuming account identity. In Snowflake, shared data is not copied into the consumer account; instead, the consumer gets read-only access to shared database objects and uses its own virtual warehouses to query them. To implement per-consumer filtering while sharing a common dataset, providers commonly expose secure views rather than base tables and use provider-controlled logic such as CURRENT_ACCOUNT() joined to an entitlement table to restrict rows appropriately. This design minimizes duplication and onboarding effort because the provider can maintain one set of shared secure views and update only entitlement metadata as new partners are added. Reader accounts are used when consumers do not already have Snowflake accounts, so they do not fit this scenario. Best-practice references include Snowflake documentation on Secure Data Sharing, Secure Views, Reader Accounts, and account-aware functions such as CURRENT_ACCOUNT() for provider-side entitlement patterns.
- A. Incorrect.
Incorrect. Cloning creates separate physical metadata objects and increases administrative overhead because each partner-specific clone and policy assignment must be maintained independently. In addition, masking policies are primarily for column-level obfuscation, not the best mechanism for partner-specific row filtering in a shared-data scenario. This approach does not best satisfy the requirement to minimize operational overhead while avoiding unnecessary duplication of access structures.
- B. Correct.
Correct. Secure shares allow consumers to access provider data without copying the underlying data, and consumers use their own warehouses to query shared data. A common design is to share secure views rather than base tables and implement row-level filtering in the secure view logic using CURRENT_ACCOUNT() or similar account-aware logic, often joined to a provider-side entitlement/mapping table. This supports a single set of shared objects, scales better as partners are added, and preserves data isolation per consumer account.
- C. Incorrect.
Incorrect. Reader accounts are intended for consumers who do not have their own Snowflake accounts. The scenario states that partners should query from their own warehouses, which aligns with standard data sharing to existing consumer accounts, not reader accounts. Creating separate schemas and loading partner-specific data also adds operational complexity and is unnecessary when secure sharing with filtered secure views can meet the requirement.
- D. Incorrect.
Incorrect. Listings and exchanges can be used to distribute data products, but standard views are not appropriate for secure data sharing scenarios that require strong protection of underlying logic and controlled exposure. Also, relying on consumer-set session variables for row restriction is not a secure entitlement model for provider-managed sharing because consumers control their own sessions. Secure views with provider-controlled logic are the correct pattern.