nerdexam
Oracle

1Z0-116 · Question #62

Database Vault is not used in your installation. Why is a conventional secure application role more secure than a normal role?

The correct answer is D. It can be set only by users with the grant any bole privilege. Important note: The stated correct answer (D) appears to be an error in this question. The actual correct answer is E. Explaining D as correct would mislead you on the real exam. --- A secure application role is created with CREATE ROLE role_name IDENTIFIED USING…

Configuring and Auditing User Security

Question

Database Vault is not used in your installation. Why is a conventional secure application role more secure than a normal role?

Options

  • AIt Is In effect only when configured as a default role for the user.
  • BIt requires a password to be set.
  • CIt can be set only by a package or procedure that is created with deflner's rights.
  • DIt can be set only by users with the grant any bole privilege.
  • EIt can be set only by a package or procedure associated with the role definition.

How the community answered

(44 responses)
  • A
    2% (1)
  • B
    7% (3)
  • C
    9% (4)
  • D
    80% (35)
  • E
    2% (1)

Explanation

Important note: The stated correct answer (D) appears to be an error in this question. The actual correct answer is E. Explaining D as correct would mislead you on the real exam.


A secure application role is created with CREATE ROLE role_name IDENTIFIED USING schema.package, which ties role activation to a specific PL/SQL package. Unlike a normal role (enabled via SET ROLE or as a default role), a secure application role can only be enabled by invoking that designated package-which can enforce additional security checks (IP address, time of day, application context) before granting access. This prevents users from simply typing SET ROLE to elevate their privileges directly.

Why the distractors are wrong:

  • A - Default role configuration applies to normal roles too; it's not unique to secure application roles.
  • B - Password-protected roles exist (CREATE ROLE r IDENTIFIED BY password), but that's a password-protected role, not a secure application role-a different concept.
  • C - Close, but misleading: the package enabling the role is often created with definer's rights, but that's an implementation detail, not the defining security property.
  • D - GRANT ANY ROLE controls who can grant roles to others, not who can enable them. This has nothing to do with what makes secure application roles special.

Memory tip: Think "secure = sealed pipeline"-the role is locked inside a package. Only that package's front door can open it, so attackers can't sneak in through a side entrance with SET ROLE.

Topics

#secure application roles#privilege restriction#role activation#application security

Community Discussion

No community discussion yet for this question.

Full 1Z0-116 Practice