ARA-C01 Question 154
Single answerSecurity patterns for data sharingA healthcare analytics company must share a subset of patient-related claims data with several external partner organizations using Snowflake. Each partner should see only the rows for its own organization, and the provider must be able to add new partners without copying data for each one. The security team also requires that sensitive columns such as member email and phone number remain hidden from all shared consumers. Which approach best meets these requirements with the least operational overhead?
- A
Create a separate database copy for each partner, remove sensitive columns from each copy, and grant each partner access to its dedicated database.
- B
Create one secure view that references a mapping table and uses CURRENT_ACCOUNT() to filter rows by consumer account, excludes sensitive columns, then share that secure view through a share to all partner accounts.
- C
Create a masking policy on the sensitive columns in the base table and directly share the base table to all partners; the masking policy will automatically enforce row-level filtering for each consumer account.
- D
Create one standard view with a WHERE clause on CURRENT_ROLE() and share the view to all partner accounts; Snowflake shares preserve the consumer role context from the provider account.
Show answer and explanation
Correct answer: B
Explanation
For secure data sharing, Snowflake best practice is to share controlled projections of data through secure views rather than exposing base tables when row- and column-level restrictions are required. A secure view can omit sensitive columns entirely and can implement dynamic row filtering based on the consuming account using CURRENT_ACCOUNT(). This pattern enables zero-copy sharing, minimizes operational overhead, and scales as new consumers are added by updating the account-to-organization mapping rather than cloning data. While Snowflake also supports row access policies and masking policies, masking policies do not provide row-level isolation, and directly sharing base tables is generally not the preferred architecture when the provider must enforce both row and column restrictions per consumer. Relevant Snowflake documentation includes guidance on Secure Data Sharing, secure views, and context functions such as CURRENT_ACCOUNT() used in shared data scenarios.
- A. Incorrect.
This approach can work functionally, but it creates unnecessary operational overhead and storage/management complexity compared with Snowflake's secure data sharing patterns. Maintaining separate database copies per partner does not scale well as new partners are added, and it defeats the goal of avoiding duplicated datasets where possible.
- B. Correct.
This is the best answer. A secure view is the recommended pattern for restricting shared data to specific rows and columns when using Snowflake Secure Data Sharing. The provider can maintain a mapping table of consumer account identifiers to allowed organization identifiers, and use CURRENT_ACCOUNT() in the secure view logic to enforce partner-specific row filtering. By selecting only approved columns in the secure view, sensitive fields such as email and phone number are not exposed. This supports zero-copy sharing and scales better as new consumers are onboarded.
- C. Incorrect.
This is incorrect because masking policies protect column values, not row-level visibility by consumer account in a direct share of the base table. Also, directly sharing the base table exposes the full table structure and requires the provider to rely on masking for sensitive columns while still lacking the required per-partner row filtering. Row access policies and secure views are the relevant constructs for row-level restriction, but the option specifically claims masking policies will enforce row-level filtering, which is false.
- D. Incorrect.
This is incorrect for two reasons. First, secure views, not standard views, are the appropriate mechanism for data sharing when the provider needs to protect underlying logic and avoid exposing base object details. Second, CURRENT_ROLE() is not a valid way to distinguish consumer accounts in a provider-managed share because role context is not preserved in the way this option suggests. The proper context function for this pattern is CURRENT_ACCOUNT(), which identifies the consuming account.