ADA-C01 Question 464
Single answerShare data with secure User-defined Functions (UDFs)A data provider wants to publish a secure data share to several customers. The provider must expose a masking rule implemented as a SQL UDF so consumers can query a shared secure view without seeing the rule logic or gaining access to underlying tables beyond what the share exposes. During testing, the administrator notices that the consumer can query the shared view only when the UDF is recreated in a specific way. Which action should the administrator take to make the UDF usable through the share while preserving the provider's implementation details?
- A
Create the function as a SECURE UDF in the same database that is being shared, and reference it from the shared secure view.
- B
Create the function as an external function so the share can invoke it without exposing the underlying SQL logic.
- C
Grant USAGE on the UDF directly to the consumer account and keep the function in a separate utility database not included in the share.
- D
Convert the SQL UDF to a JavaScript UDF because only non-SQL UDFs can be used from shared objects.
Show answer and explanation
Correct answer: A
Explanation
When sharing data that depends on a user-defined function, Snowflake requires use of SECURE UDFs to prevent consumers from viewing sensitive implementation details such as proprietary logic or references to underlying objects. In practice, providers commonly expose shared data through SECURE VIEWs that call SECURE UDFs. The referenced function must be available within the shared database context; placing it outside the shared database or trying to rely on direct grants to the consumer does not satisfy Snowflake data sharing behavior. This aligns with Snowflake guidance on secure objects for data sharing: use secure views and secure UDFs when you need to protect definitions while allowing consumers to query shared results.
- A. Correct.
Correct. To use a UDF in data sharing, the function must be created as a SECURE UDF. Secure UDFs are designed to protect implementation details from consumers. In addition, objects referenced by shared objects must be resolvable within the shared database context. A shared secure view can reference a secure UDF in the same shared database, allowing consumers to use the view without seeing the function body or getting direct access to underlying provider objects.
- B. Incorrect.
Incorrect. External functions are for invoking remote services outside Snowflake, not for making a SQL masking function shareable. Using an external function would add unnecessary complexity and does not address the core requirement that shared functions must protect implementation details and be usable within shared database objects. The issue here is solved by using a secure UDF, not by changing the function type to an external integration pattern.
- C. Incorrect.
Incorrect. Data sharing does not work by granting privileges directly to consumer accounts on individual objects in the provider account. Instead, the provider adds supported objects to a share, and consumers create a database from that share. Keeping the function in a separate unshared utility database would prevent the shared view from resolving the function for the consumer. This option reflects the common misconception that standard privilege grants can replace share design requirements.
- D. Incorrect.
Incorrect. SQL UDFs can be shared when created as secure functions. There is no requirement to convert a SQL UDF to JavaScript for data sharing. The important property is that the UDF is SECURE and used appropriately from supported shared objects such as secure views.