ADA-C01 Question 452
Single answerShare different types of data objects including secure functionsA data provider wants to share a curated analytics dataset with a partner using a direct share. The partner must be able to query a subset of rows from a table and use a provider-defined function that masks part of a string before returning results. The provider also wants to ensure that the function logic is not exposed to the consumer account. Which action should the Snowflake administrator take to meet these requirements?
- A
Create a secure view for the row-filtered data, create a secure UDF for the masking logic, grant USAGE on the database and schema plus SELECT on the secure view and USAGE on the secure UDF to the share.
- B
Create a standard view for the row-filtered data, create a JavaScript UDF for the masking logic, and grant SELECT on the base table to the share so the consumer can resolve dependencies.
- C
Create a secure materialized view for the row-filtered data, create a secure UDF, and grant OWNERSHIP on the function to the share so the consumer can execute it.
- D
Create a secure view for the row-filtered data, create a masking policy for the string column, and grant APPLY MASKING POLICY on the policy to the share.
Show answer and explanation
Correct answer: A
Explanation
The best solution is to share secure objects designed for provider-to-consumer access control. In Snowflake Secure Data Sharing, providers commonly expose data through secure views so consumers can query curated subsets of data without seeing underlying implementation details. When sharing function-based logic, secure UDFs or secure procedures are used to protect the definition from consumers while still allowing execution through the share. The share must be granted the appropriate privileges on the database, schema, and shared objects. By contrast, granting access to base tables undermines the curated-access design, and shares cannot receive OWNERSHIP. This aligns with Snowflake documentation on Secure Data Sharing, secure views, and secure UDFs, which emphasizes using secure objects to protect definitions and control data exposure across accounts.
- A. Correct.
Correct. In a direct share, consumers can access shared objects only through privileges granted to the share. To expose filtered data without revealing underlying implementation details, the provider should use a secure view. To expose provider-defined function logic without making the definition visible to consumers, the function must be secure. The provider then grants the required privileges to the share: USAGE on the containing database and schema, SELECT on the secure view, and USAGE on the secure UDF. This matches Snowflake sharing behavior for secure objects.
- B. Incorrect.
Incorrect. A standard view is not appropriate for secure data sharing scenarios where object definitions and underlying details should be protected; secure views are designed for data sharing use cases. Granting SELECT on the base table is also unnecessary and counterproductive because it exposes the underlying object rather than limiting access through the curated shared object. In addition, simply using a JavaScript UDF does not satisfy the requirement to hide the function definition; the key requirement is that the function be secure.
- C. Incorrect.
Incorrect. Although a secure UDF is appropriate, granting OWNERSHIP to a share is not valid. Shares can receive supported object privileges such as USAGE and SELECT, but not OWNERSHIP. Also, secure materialized views are not the standard approach for this requirement; the scenario only requires row filtering and controlled exposure, which is commonly addressed with a secure view.
- D. Incorrect.
Incorrect. A masking policy can protect sensitive columns inside the provider account, but policies themselves are not directly granted to shares for consumer use in the way described here. The requirement explicitly states that the partner must use a provider-defined function and that the function logic must not be exposed. A secure UDF addresses that requirement, while granting APPLY MASKING POLICY on a policy to a share does not.