ARA-C01 Question 370
Single answerSecure functionsA healthcare company exposes a derived patient-risk score to external research partners through a data share. The score is produced by a SQL UDF that applies proprietary business logic to diagnosis and claims data in the provider account. Security architects must ensure that consumers can query the score, but cannot inspect the function definition or infer proprietary logic from metadata. Which design best meets this requirement?
- A
Create a secure UDF for the scoring logic and expose it through a secure view that references the function.
- B
Create a standard SQL UDF for the scoring logic and grant USAGE on the function to the shared database role.
- C
Implement the scoring logic in a JavaScript UDF because handler code is hidden from consumers by default.
- D
Create a materialized view that contains the score and grant SELECT on the materialized view through the share.
Show answer and explanation
Correct answer: A
Explanation
Snowflake secure functions are intended for situations where the function's internals must be protected from consumers while still allowing execution. This is especially relevant for provider-consumer models such as secure data sharing, listings, or other governed access patterns. A secure UDF helps prevent exposure of sensitive implementation details in ways that could occur with non-secure objects. When combined with a secure view, it provides a standard architecture for sharing derived results without revealing underlying business logic or source structures. Best practice is to use SECURE for UDFs, procedures, and views whenever the object definition itself is sensitive. Standard UDFs do not provide the same protection, and changing the handler language does not replace the need for SECURE semantics. See Snowflake documentation on secure UDFs and secure views for the supported behavior and metadata protection model.
- A. Correct.
Correct. A secure UDF is designed to protect sensitive implementation details from being exposed through metadata or query plan visibility to unauthorized users. In a data sharing scenario, pairing the secure UDF with a secure view is the appropriate pattern when you want consumers to query derived results without exposing underlying logic. Secure objects are specifically intended for cases where the provider must prevent consumers from accessing details of the object definition while still allowing controlled query access.
- B. Incorrect.
Incorrect. A standard SQL UDF does not provide the metadata protection guarantees required here. Even if the consumer can execute it through appropriate privileges, the requirement is specifically to prevent inspection or inference of the proprietary logic from metadata exposure. Standard UDFs are not the right mechanism when the implementation itself must be protected.
- C. Incorrect.
Incorrect. Choosing JavaScript as the UDF language does not by itself satisfy the requirement to protect the function definition in a data-sharing or secure object context. The key control is whether the function is created as SECURE, not whether it is implemented in SQL or JavaScript. This option reflects the misconception that handler language alone determines metadata visibility.
- D. Incorrect.
Incorrect. A materialized view could expose precomputed results, but it does not satisfy the stated need to expose the score through protected function logic, and it changes the design significantly. It may also introduce maintenance, refresh, and storage considerations that are unnecessary if the objective is simply to let consumers query a derived value while keeping the transformation logic hidden. The core requirement is secure encapsulation of logic, which secure UDFs and secure views address directly.