Examine these statements, which execute successfully: CREATE ROLE r_world_rd; GRANT SELECT ON world.* TO r_world_rd; CREATE USER john IDENTIFIED BY `P@ssw0rd'; GRANT r_world_rd TO john; Examine…

Question

Exhibit

Options

• AThe statement was blocked by MySQL Firewall.
• BJohn has not activated the role.
• CJohn needs to reconnect to the database.
• DThe DBA needs to execute FLUSH PRIVILEGES.

• A
  15% (6)
• B
  77% (30)
• C
  3% (1)
• D
  5% (2)

Explanation

In MySQL 8.0+, roles granted to a user are not active by default upon login. John must explicitly activate the role in his session with SET ROLE r_world_rd; or SET ROLE ALL;, or the DBA must configure it as a default with SET DEFAULT ROLE r_world_rd TO john; - until then, John's SELECT attempt on the world schema will fail with an access denied error even though the role was granted.

Why the distractors are wrong:

• A - MySQL Firewall is an enterprise plugin that blocks based on query patterns; nothing in the setup indicates it's configured or involved.
• C - Reconnecting alone won't help because roles still don't auto-activate on a new connection unless a default role has been configured first.
• D - FLUSH PRIVILEGES is only needed when grant tables are modified directly (e.g., INSERT INTO mysql.user); using GRANT statements reloads privileges automatically, so this is a no-op here.

Memory tip: Think of a MySQL role like a badge you've been issued but must badge in to use - GRANT hands you the badge, but SET ROLE (or SET DEFAULT ROLE) is the tap that activates it.

No community discussion yet for this question.