A customer has implemented their own Role Based Access Control (RBAC) model to attempt to give the Security team different data access than the Operations team by creating two new Splunk roles ""…

Question

Options

• Aoperations, network, _internal, _audit
• Boperations
• CNo Indexes
• Doperations, network

• A
  6% (3)
• B
  21% (11)
• C
  11% (6)
• D
  62% (33)

Explanation

Option D is correct because Splunk role inheritance is additive - the operations role explicitly allows the "operations" index, but it also inherits from the default "user" role, which has srchIndexesAllowed = * (wildcard). That wildcard covers all non-internal indexes, meaning it includes the "network" index defined under the security role, giving the user access to both.

• A is wrong because _internal and _audit are internal indexes (prefixed with _), and Splunk's wildcard * in srchIndexesAllowed deliberately excludes internal indexes - explicit grants are required for those.
• B is wrong because inheritance from the user role isn't being accounted for; the wildcard * on the parent role adds network access on top of the operations index.
• C is wrong because the user is directly assigned the operations role, which explicitly allows the operations index - access is not zero.

Memory tip: Think of Splunk's * wildcard as "everything without an underscore." When tracing permissions, always walk up the inheritance chain - a child role accumulates all parent permissions, so a user can end up with more access than their assigned role's settings suggest.

No community discussion yet for this question.