ARA-C01 Question 371
Single answerSecure functionsA healthcare provider exposes a data product to several partner organizations through a shared database. The product includes a user-defined function that determines whether a requesting user can see a masked or unmasked value based on internal entitlement logic. The provider is concerned that partners could inspect the function definition and infer sensitive business rules or underlying object references. Which design best meets this requirement while still allowing partners to use the function in SQL queries?
- A
Create the function as a SECURE function so its implementation details are hidden from consumers, and grant partners the privileges needed to call it through the share
- B
Create a normal UDF and rely on role-based access control; consumers without ownership privileges will not be able to see the function body
- C
Wrap the logic in a stored procedure instead of a function, because stored procedures are not visible to data sharing consumers when referenced from SELECT statements
- D
Create the function in a separate schema with managed access, because managed access schemas automatically hide function definitions from all non-owners
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a secure function. In Snowflake, SECURE functions are designed for cases where the function logic itself is sensitive and should not be exposed to users or data sharing consumers. This is especially relevant in provider-consumer scenarios involving listings or direct shares, where the provider wants consumers to execute logic without learning proprietary rules, entitlement criteria, or referenced object details. A standard UDF may be callable, but it does not provide the same protection of implementation details. Managed access schemas help with governance and privilege delegation, and RBAC controls execution rights, but neither substitutes for the secure object property. Snowflake documentation on secure UDFs and secure objects emphasizes using SECURE when code or logic must be concealed while still being executable by authorized users.
- A. Correct.
Correct. A secure UDF is specifically intended to protect the implementation details of the function, including hiding sensitive logic and limiting exposure of underlying object references to consumers. This is the appropriate design when sharing data products and needing consumers to invoke the function without revealing how the logic works internally. Partners can still use the secure function in supported SQL statements if the provider shares the necessary database objects and grants appropriate privileges.
- B. Incorrect.
Incorrect. RBAC controls who can use an object, but it does not provide the same definition-hiding guarantees as a secure function for shared consumption scenarios. A normal UDF is not the recommended mechanism when the goal is to prevent exposure of function implementation details to consumers. This option reflects the common misconception that permissions alone are equivalent to secure object semantics.
- C. Incorrect.
Incorrect. Stored procedures are not a drop-in replacement for UDFs in SQL expressions such as SELECT lists or predicates. The scenario requires a function that can be used directly in SQL queries to determine masking behavior or entitlement outcomes. Choosing a stored procedure would change the calling model and would not satisfy the requirement as stated.
- D. Incorrect.
Incorrect. Managed access schemas centralize privilege management at the schema level, but they do not by themselves make a function secure or hide its implementation from consumers. This option confuses schema-level privilege administration with secure object behavior. Managed access can be useful for governance, but it does not address the requirement to conceal the function's logic.