Database Vault realm r protects all tables In the fin schema from DBA access User fin is configured as the owner in realm R. You must also prevent access to realm r protected tables by user FIN…

Question

Options

• ARevoke the select any table privilege from user FIN.
• BMake realm R a mandatory realm.
• CRemove the owner authorization of user fin in realm R.
• DMake user FIN participant In realm r. Instead of owner.

• A
  11% (2)
• B
  5% (1)
• D
  84% (16)

Explanation

In Oracle Database Vault, a realm owner holds an implicit exemption from the realm's own enforcement - the realm does not block its owner, so FIN can freely access all realm-protected tables in the fin schema despite the realm existing to restrict such access. Changing FIN's authorization type from owner to participant removes that exemption; as a participant, FIN is now governed by the realm's access controls rather than bypassing them, which prevents FIN from accessing the protected tables.

Why the distractors are wrong:

• A fails because FIN owns the fin schema and accesses those tables through schema ownership rights, not the SELECT ANY TABLE system privilege; revoking it has no effect on FIN's own schema.
• B fails because a mandatory realm requires both realm authorization and object-level grants - but FIN, as schema owner, already possesses object-level grants, so the mandatory requirement is already satisfied and FIN still gets through.
• C fails because simply removing the owner authorization role may leave FIN with no administration rights, but FIN's schema ownership and any residual object-level access remain; it doesn't cleanly block data access the way changing the authorization type does. If FIN also had participant authorization, removing only the owner role leaves participant access intact.

Memory tip: Think "O for Override" - an Owner overrides realm protections, while a Participant is policed by them. When you need a user to be subject to the realm rather than exempt from it, demote to Participant.

No community discussion yet for this question.