An Architect needs to grant a group of ORDER_ADMIN users the ability to clean old data in an ORDERS table (deleting all records older than 5 years), without granting any privileges on the table. The g

Question

Options

• ACreate a stored procedure that runs with caller's rights, including the appropriate "> 5 years"
• BCreate a stored procedure that can be run using both caller's and owner's rights (allowing the user
• CCreate a stored procedure that runs with owner's rights, including the appropriate "> 5 years"
• DThis scenario would actually not be possible in Snowflake ?any user performing a DELETE on a

• A
  5% (1)
• B
  16% (3)
• C
  74% (14)
• D
  5% (1)

Explanation

A stored procedure using owner's rights (EXECUTE AS OWNER) runs with the privileges of the role that owns the stored procedure - not the role of the user calling it. The ORDER_MANAGER (who has DELETE on the ORDERS table) creates the stored procedure. When ORDER_ADMIN executes it, the procedure runs under the owner's privileges, including DELETE access, without ORDER_ADMIN ever being granted DELETE directly. This is a classic privilege escalation pattern for controlled access. A caller's rights procedure (A) would run with ORDER_ADMIN's own privileges, meaning it would fail because ORDER_ADMIN lacks DELETE. Option B is not a real Snowflake feature - a procedure runs with either caller's or owner's rights, not both simultaneously. Option D is incorrect - this scenario is precisely what owner's rights stored procedures are designed to enable.

No community discussion yet for this question.