A Data Engineer has written a stored procedure that will run with caller's rights. The Engineer has granted ROLEA the right to use this stored procedure. What is a characteristic of the stored…

Question

Options

• AThe stored procedure must run with caller's rights; it cannot be converted later to run with owner's
• BIf the stored procedure accesses an object that ROLEA does not have access to, the stored
• CThe stored procedure will run in the context (database and schema) where the owner created the
• DROLEA will not be able to see the source code for the stored procedure, even though the role has

• A
  6% (3)
• B
  90% (44)
• C
  2% (1)
• D
  2% (1)

Explanation

When a stored procedure runs with caller's rights, it executes using the calling role's privileges, not the owner's. So if ROLEA lacks access to any object the procedure tries to reach (a table, view, etc.), the execution will fail with an access error - the procedure is fundamentally limited to what ROLEA can see and touch. This makes option B correct.

Why the distractors are wrong:

• A is false - a stored procedure can be altered to switch between caller's and owner's rights after creation; neither type is permanent.
• C describes owner's rights behavior, not caller's. With caller's rights, the procedure runs in the caller's current session context (database/schema), not the owner's.
• D is a red herring - source code visibility is unrelated to rights type and is not restricted simply by granting USAGE to a role.

Memory tip: Think of caller's rights like lending someone your car but telling them they can only go where their license permits - the car (procedure) runs under the passenger's (caller's) credentials, not the owner's. Owner's rights is the opposite: the car follows the owner's permissions regardless of who's driving.

No community discussion yet for this question.