SnowPro Advanced: Security Engineer Question 137
Single answer2.2 Manage and audit Secure Data Sharing and collaborations.A Snowflake security engineer manages a provider account that shares regulated sales data with several consumer accounts by using Secure Data Sharing. The provider recently added a row access policy to one of the shared tables to restrict visibility by region. During an audit, the engineer must verify two things: whether consumers are querying the share, and whether the new row access policy is affecting what consumers can see before notifying external partners. Which action will best meet both requirements with the least operational overhead?
- A
Create a reader account for each consumer and review the query history in each reader account after asking partners to reconnect through the reader accounts.
- B
Use the provider account to query shared-object usage through account-level monitoring views such as ACCESS_HISTORY and QUERY_HISTORY for consumer activity, and validate the policy effect by testing the shared objects from a separate consumer context.
- C
Ask each consumer to export their query history and send screenshots proving that the row access policy is applied correctly to their users.
- D
Clone the shared database in the provider account and run test queries there, because clones preserve sharing behavior exactly as seen by all consumers.
Show answer and explanation
Correct answer: B
Explanation
This question focuses on managing and auditing Secure Data Sharing. In Snowflake, providers should use native monitoring and governance features to audit shared data usage rather than depending on consumers for proof of access patterns. Account monitoring views, including QUERY_HISTORY and ACCESS_HISTORY, are commonly used to investigate who queried what and how objects were accessed. For policy validation, the key principle is that secure sharing should be tested from the consumer perspective, especially when row access policies or masking policies affect query results. Testing only in the provider account can miss how shared objects are actually enforced for consumers. Reader accounts are appropriate in some collaboration scenarios, but introducing them solely for auditing existing direct shares adds avoidable complexity. This aligns with Snowflake best practices for Secure Data Sharing, account monitoring, and policy-based access control validation.
- A. Incorrect.
Incorrect. Reader accounts can be useful when consumers do not have their own Snowflake account, and providers can monitor activity in reader accounts they own. However, replacing existing direct shares with reader accounts would create unnecessary migration effort and operational overhead. It also does not address the requirement to validate how current consumers see the shared data without changing the collaboration model.
- B. Correct.
Correct. In Snowflake, providers can audit usage of shared data using account monitoring capabilities, including views such as QUERY_HISTORY and ACCESS_HISTORY, to understand how shared objects are queried. To validate the effect of row access policies on shared data, the provider should test from an actual consumer perspective, such as a separate consumer account or equivalent consumer context, because policies on shared objects are enforced when data is queried by the consumer. This approach satisfies both auditing and validation requirements without redesigning the sharing architecture.
- C. Incorrect.
Incorrect. This relies on manual evidence from consumers, which is not ideal for auditability or operational efficiency. It also does not provide a provider-controlled, repeatable verification process. A security engineer should use Snowflake-native monitoring and controlled validation rather than screenshots or exported reports from external parties.
- D. Incorrect.
Incorrect. Cloning in the provider account is useful for testing many database changes, but it does not replicate the exact runtime behavior of a secure share as experienced from a consumer account. The requirement is to validate what consumers can see through the share after the row access policy change. That must be tested from a consumer-side context rather than only inside the provider account.