Which GRANT Statements Execute Successfully on Roles?
1. MANAGER is an existing role with no privileges or roles. 2. EMP is an existing role containing the CREATE TABLE privilege. 3. EMPLOYEES is an existing table in the HR schema. Which two commands execute successfully? (Choose two.)
Community Votes
50% of anonymous learners picked answer AB. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests whether you can separate the privilege list (what follows GRANT) from the grantee list (what follows TO) — the trap is assuming a role name may sit in the privilege list or that system and object privileges can be blended in one statement.
Oracle GRANT syntax keeps system privileges (no ON clause) and object privileges (privilege ON object) in two separate statement forms. This page explains why granting CREATE SEQUENCE to two roles (A) and SELECT, INSERT ON hr.employees to a role with grant option (D) both execute, while B, C and E fail.
Choosing B, the source key's answer, because CREATE TABLE is a genuine system privilege and roles can be grantees — but emp is written inside the privilege list, where a role name is invalid and triggers ORA-00990.
Community Discussion (4 comments)
- A: Grants the CREATE SEQUENCE system privilege to both the manager and emp roles. It is valid to specify multiple roles or users in a single GRANT statement. - B: CREATE TABLE is a system privilege, and privileges can be granted to roles. - C: CREATE ANY SESSION is not a valid privilege in Oracle. It should be CREATE SESSION instead - D: This syntax is valid. - E: CREATE TABLE is a system privilege, and SELECT is an object privilege. System and object privileges cannot be granted in the same GRANT statement
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
A is valid because GRANT CREATE SEQUENCE TO manager, emp lists one system privilege followed by a comma-separated grantee list, and Oracle syntax allows multiple users or roles after TO; a role can receive a system privilege. D is valid because SELECT and INSERT are object privileges on the concrete table hr.employees, and WITH GRANT OPTION is permitted when object privileges are granted to a role. Both statements respect the two distinct GRANT forms: system privileges without an ON clause, object privileges with an ON object clause. EMP already holding CREATE TABLE is irrelevant to either statement, and MANAGER having no privileges of its own does not stop it from receiving new ones.Why the Other Options Are Wrong
B fails because emp is a role, not a privilege: after CREATE TABLE the parser reads emp as another privilege name and raises ORA-00990 (missing or invalid privilege), since role names may appear only after TO. C fails because CREATE ANY SESSION is not a real Oracle privilege — the genuine one is CREATE SESSION — and a single invalid privilege invalidates the whole statement even though CREATE ANY TABLE is legitimate. E fails because one GRANT cannot combine a system privilege with an object privilege; CREATE TABLE would have to be granted in its own statement, separate from SELECT ON hr.employees.Community Comment Notes
The vote is split 50/50 between AB and AD, and the thread shows exactly why. treat picked AB and justified it with "can grant system and object privileges in same grant statement" — a claim that is itself wrong and does not rescue B, whose failure is the role name sitting in the privilege list. k1b argued for A and E, saying that E "grants both a system privilege and an object privilege to a role", which is precisely the mixing Oracle rejects. Thameur01's AD reasoning, including the accurate note "It is valid to specify multiple roles or users in a single GRANT statement.", matches documented GRANT behavior.Official Reference
Exam Strategy
For every GRANT option, split the statement at TO: everything before TO must be valid privileges (or privilege ON object), and everything after TO must be valid users or roles. Any invented privilege such as CREATE ANY SESSION, any role name placed among privileges, or any blend of system and object privileges kills the statement outright.
Frequently Asked Questions
Why does GRANT CREATE TABLE, emp TO manager fail in Oracle?
emp is a role name, not a privilege, so Oracle reads it as a second system privilege and raises ORA-00990. Role names are only valid after TO, in the grantee list.
Can one GRANT mix a system privilege and an object privilege?
No. CREATE TABLE is a system privilege and SELECT ON hr.employees is an object privilege; they need separate GRANT statements, which is why E fails while D succeeds.