A secure function returns data coming through an inbound share. What will happen if a Data Engineer tries to assign USAGE privileges on this function to an outbound share?

Question

Options

• AAn error will be returned because the Engineer cannot share data that has already been shared.
• BAn error will be returned because only views and secure stored procedures can be shared.
• CAn error will be returned because only secure functions can be shared with inbound shares.
• DThe Engineer will be able to share the secure function with other accounts.

• A
  92% (58)
• B
  5% (3)
• C
  2% (1)
• D
  2% (1)

Explanation

Option A is correct because Snowflake enforces a strict "no re-sharing" policy: data received via an inbound share cannot be reshared outbound to other accounts. When a secure function returns data sourced from an inbound share, attempting to grant USAGE on that function to an outbound share will fail with an error, regardless of the function's security properties.

Why the distractors are wrong:

• B is wrong because secure functions can be shared - Snowflake supports sharing secure UDFs and secure views, not just stored procedures.
• C is wrong because the restriction here has nothing to do with inbound shares being required for sharing functions; the block is on re-sharing inbound data outbound, not on the object type.
• D is wrong because this scenario directly violates Snowflake's no-re-sharing rule, so the operation fails rather than succeeds.

Memory tip: Think of inbound shares as "read-only borrowed data" - you can use it internally, but you can never lend what you've borrowed. The moment your shareable object wraps inbound-shared data, Snowflake blocks the outbound share at the door.

No community discussion yet for this question.