ADA-C01 Question 453
Single answerDetermine the role of context functions in data sharingA data provider publishes a secure view in a share for several consumer accounts. The view is intended to show each consumer only its own rows by filtering on the account that is querying the shared data. During testing, the provider notices that using CURRENT_ACCOUNT() in the view does not reliably identify the consumer account as expected. Which approach should the Snowflake administrator recommend to implement consumer-specific row filtering for shared data?
- A
Use the context function CURRENT_ACCOUNT() directly in the shared secure view filter because context functions always evaluate in the consumer session for shared objects.
- B
Create a secure UDF that uses CURRENT_ROLE() to determine the consumer identity, and filter rows based on the role name returned in the consumer account.
- C
Use the context function CURRENT_ACCOUNT_NAME() or CURRENT_ORGANIZATION_NAME() inside the secure view to derive the consumer account context for row filtering in data sharing scenarios.
- D
Convert the secure view to a regular view and use CURRENT_USER() so the provider can identify the end user in the consumer account.
Show answer and explanation
Correct answer: C
Explanation
In Snowflake data sharing, secure views are commonly used to present different subsets of data to different consumers from a single provider-managed object. However, administrators must understand that context functions have special behavior in shared objects. The correct design is to use the consumer account context exposed by supported functions such as CURRENT_ACCOUNT_NAME(), and if needed CURRENT_ORGANIZATION_NAME(), to identify which consumer account is querying the share. The provider can then filter rows accordingly, often by joining to or referencing a mapping table keyed by consumer account name. Functions like CURRENT_ROLE() and CURRENT_USER() do not solve the problem of identifying the consumer account for share-based row filtering, and CURRENT_ACCOUNT() is not the recommended choice for this scenario. This aligns with Snowflake best practices for secure data sharing and documentation covering context functions and secure objects in shares.
- A. Incorrect.
Incorrect. In data sharing scenarios, not all context functions behave the same way for shared objects, and CURRENT_ACCOUNT() is not the recommended function for identifying the consumer account for row-level filtering in a shared secure view. This is a common misconception because administrators often assume account context functions are interchangeable. Snowflake documents special considerations for context functions in shares, and relying on CURRENT_ACCOUNT() can lead to incorrect or unexpected evaluation context.
- B. Incorrect.
Incorrect. CURRENT_ROLE() reflects role context, not consumer account identity, and role names are not a reliable mechanism for enforcing tenant isolation across multiple consumer accounts. In addition, shared data access does not depend on provider-side knowledge of consumer role naming conventions. This option reflects the misconception that role context can substitute for account context in data sharing.
- C. Correct.
Correct. For consumer-aware filtering in a secure view shared through Snowflake data sharing, Snowflake supports using account-identifying context such as CURRENT_ACCOUNT_NAME() and, where needed, CURRENT_ORGANIZATION_NAME() to distinguish the querying consumer. This allows the provider to map consumer account context to rows in a reference table or CASE logic and return only the appropriate subset of data. This is the recommended pattern when implementing tenant-aware filtering in shared secure objects.
- D. Incorrect.
Incorrect. Regular views are not appropriate for securely sharing filtered data in this scenario; secure views are designed to protect underlying logic and support controlled data sharing. Also, CURRENT_USER() does not provide a dependable end-user identity for this use case in a data share, because shared data is accessed at the consumer account level rather than exposing provider-visible consumer users in the way this option suggests. This distractor targets the misconception that user context is available across shares for row security.