ADA-C01 Question 454
Single answerDetermine the role of context functions in data sharingA data provider publishes a secure view in a share to several consumer accounts. The provider wants each consumer to see only rows for its own region without creating a separate view per consumer. An engineer proposes filtering the secure view with a context function so the view can identify which account is querying it. Which approach will meet this requirement when the secure view is queried from a data share?
- A
Use CURRENT_ROLE() in the secure view predicate because the consumer's active role is passed through the share and can be used for row-level filtering.
- B
Use CURRENT_ACCOUNT() in the secure view predicate because, for shared objects, this function resolves to the consumer account that is querying the shared data.
- C
Use CURRENT_USER() in the secure view predicate because Snowflake preserves the consumer username across data sharing and this is the recommended way to identify the tenant.
- D
Use CURRENT_DATABASE() in the secure view predicate because the shared database name is unique per consumer and can be mapped to a region.
Show answer and explanation
Correct answer: B
Explanation
For Snowflake Secure Data Sharing, providers often use secure views to implement row-level restrictions for multiple consumers. When the provider needs the shared object to behave differently depending on which consumer account is querying it, CURRENT_ACCOUNT() is the key context function because it identifies the account making the request. This enables patterns such as joining to an entitlement table keyed by account locator or account identifier. By contrast, functions such as CURRENT_ROLE() or CURRENT_USER() are not appropriate for identifying the consumer tenant in a provider-shared secure view. Best practice is to use secure views plus account-based filtering logic, and to avoid relying on consumer-side naming conventions or session context that is not guaranteed across shares. This aligns with Snowflake documentation on secure data sharing, secure views, and context functions used with shared data.
- A. Incorrect.
Incorrect. In a data sharing scenario, provider-side secure objects cannot rely on the consumer's role context for row filtering through CURRENT_ROLE(). Role and user context are not exposed in a way that makes CURRENT_ROLE() suitable for identifying the consumer tenant in a share. A common misconception is to assume role-based context from the consumer session is available inside the provider's shared secure view.
- B. Correct.
Correct. CURRENT_ACCOUNT() is the appropriate context function for secure views used in data sharing when the provider needs to identify the querying consumer account. Providers commonly use it in a mapping table or CASE expression to restrict rows per consumer without duplicating the view for each account. This is a practical pattern for account-based entitlements in shares.
- C. Incorrect.
Incorrect. CURRENT_USER() is not the right mechanism for determining which consumer account is accessing shared data. User identity is not the stable account-level discriminator needed for shared secure views, and the provider should not depend on consumer usernames for tenant isolation. This distractor targets the misconception that user context behaves the same across account boundaries in a share.
- D. Incorrect.
Incorrect. CURRENT_DATABASE() returns database context, not consumer identity. Although consumers can rename imported databases or use different local names, that information is not a reliable or supported basis for enforcing account-specific row filtering in provider-owned secure views. This option confuses object naming context with account identity.