ADA-C01 Question 463
Single answerShare data with secure User-defined Functions (UDFs)A data provider shares a database with several consumer accounts. The provider wants consumers to calculate a masked business metric by calling a UDF, but does not want consumers to inspect the function definition or infer details about the underlying SQL logic. The UDF references only objects in the shared database. Which action should the Snowflake administrator take to meet these requirements?
- A
Create the function as a SECURE UDF in the shared database, then grant USAGE on the shared database and schema so consumers can call it through the share.
- B
Create a standard UDF in the shared database and grant OWNERSHIP on the function to the share so consumers can execute it without seeing the definition.
- C
Create the function as a SECURE UDF in the provider account, then replicate the function to consumer accounts because functions cannot be used directly from a share.
- D
Create the function as an external function and include the API integration in the share so consumers can invoke the logic securely.
Show answer and explanation
Correct answer: A
Explanation
The correct solution is to use a SECURE UDF. In Snowflake, secure UDFs and secure procedures are intended for cases where a provider wants to expose callable logic while preventing consumers from viewing the function body or inferring sensitive implementation details. This is especially relevant in data sharing scenarios, where providers may want consumers to compute derived or masked values without exposing proprietary SQL logic. A key requirement is that the UDF's dependencies must also be shareable and available to the consumer through the shared database context. Standard UDFs do not provide the same protection. Also, shares do not receive OWNERSHIP grants, and account-level objects such as API integrations are not shared as database objects. Snowflake documentation on secure UDFs and data sharing describes secure objects as the supported pattern for sharing protected logic with consumers.
- A. Correct.
Correct. To share executable logic while protecting the implementation details, the provider should create a SECURE UDF. Secure UDFs are specifically designed so their internal definition is hidden from data consumers, while still allowing invocation when shared as part of a database share. If the UDF references only objects in the shared database and the necessary database/schema usage is available through the share, consumers can call it without viewing the underlying logic.
- B. Incorrect.
Incorrect. A standard UDF does not provide the same protection for implementation details as a SECURE UDF. In addition, OWNERSHIP is not a privilege that is granted to a share. Shares expose objects to consumers through imported privileges, not by transferring ownership. This option combines two misconceptions: using a non-secure function for protected logic and attempting to grant an invalid privilege model through a share.
- C. Incorrect.
Incorrect. Consumers can use supported shared objects directly from a data share; replication to each consumer account is not required for this use case. The key requirement is that the UDF be secure and that its referenced objects are also shareable and available in the shared database context. This option reflects the common misunderstanding that executable database objects must be copied into the consumer account before use.
- D. Incorrect.
Incorrect. External functions are for invoking external services, not for simply hiding SQL logic inside a shared database. API integrations are account-level objects and are not included in data shares in the manner described here. This option is plausible because external functions can encapsulate logic, but it does not fit the requirement to share logic that references only objects in the shared database.