Deal of The Day! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions
Mail Us support@pass4success.com
Location US
Mob_nav_barsMENU

Splunk SPLK-2003 Exam - Topic 17 Question 64 Discussion

Some of the playbooks on the SOAR server should only be executed by members of the admin role. How can this rule be applied?
A) Make sure the Execute Playbook capability is removed from all roles except admin.
B) Place restricted playbooks in a second source repository that has restricted access.
C) Add a filter block to all restricted playbooks that filters for runRole = 'Admin'.
D) Add a tag with restricted access to the restricted playbooks.

Splunk SPLK-2003 Exam - Topic 17 Question 64 Discussion

Actual exam question for Splunk's SPLK-2003 exam
Question #: 64
Topic #: 17
[All SPLK-2003 Questions]

Some of the playbooks on the SOAR server should only be executed by members of the admin role. How can this rule be applied?

Show Suggested Answer Hide Answer
Suggested Answer: A

To restrict playbook execution to members of the admin role within Splunk SOAR, the 'Execute Playbook' capability must be managed appropriately. This is done by ensuring that this capability is removed from all other roles except the admin role. Role-based access control (RBAC) in Splunk SOAR allows for granular permissions, which means you can configure which roles have the ability to execute playbooks, and by restricting this capability, you can control which users are able to initiate playbook runs.


by Frederick at Apr 05, 2025, 02:32 AM

Limited Time Offer

25%

Off

Get Premium SPLK-2003 Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Nieves
7 months ago
C sounds interesting, but is it really foolproof?
upvoted 0 times
...
Torie
7 months ago
Totally agree with A, makes it straightforward!
upvoted 0 times
...
Royal
7 months ago
I think B could work too, but it seems more complicated.
upvoted 0 times
...
Elli
7 months ago
Really? Can we trust everyone to follow that rule?
upvoted 0 times
...
Katina
8 months ago
Option A is the best way to go!
upvoted 0 times
...
Anglea
8 months ago
I feel like option D could work too, but I'm not sure how effective just tagging would be in actually enforcing access control.
upvoted 0 times
...
Haley
8 months ago
I'm a bit confused about option B; placing playbooks in a second repository sounds secure, but would that really prevent admins from executing them?
upvoted 0 times
...
Wava
8 months ago
I remember practicing a similar question where we discussed using filters, so option C could also be a valid approach to restrict access based on roles.
upvoted 0 times
...
Micheal
9 months ago
I think option A makes the most sense since it directly removes the execute capability from other roles, but I'm not entirely sure if that's the only way to enforce it.
upvoted 0 times
...
Laura
9 months ago
I'm confident that option C is the right choice here. Adding the filter block to check the user's role is a clean and effective way to restrict access to the sensitive playbooks. The other options don't seem as elegant or comprehensive.
upvoted 0 times
...
Brock
9 months ago
Option A seems too broad - removing the Execute Playbook capability from all roles except admin could have unintended consequences. I like the targeted approach of option C with the filter block. That seems like the most robust solution.
upvoted 0 times
...
Lezlie
9 months ago
Hmm, I'm a bit unsure about this one. I'm trying to decide between options B and C. Placing the restricted playbooks in a separate repository could work, but the filter block in option C seems more flexible. I'll have to think this through a bit more.
upvoted 0 times
...
Giuseppe
9 months ago
This seems like a straightforward access control question. I think option C is the best approach - adding a filter block to the restricted playbooks to check the user's role.
upvoted 0 times
...
Pedro
1 year ago
Option C is the way forward, no doubt. Gotta keep those playbooks in the hands of the chosen few, am I right?
upvoted 0 times
Karima
1 year ago
C) Add a filter block to all restricted playbooks that filters for runRole = 'Admin'.
upvoted 0 times
...
Bambi
1 year ago
A) Make sure the Execute Playbook capability is removed from all roles except admin.
upvoted 0 times
...
Dean
1 year ago
C) Add a filter block to all restricted playbooks that filters for runRole = 'Admin'.
upvoted 0 times
...
...
Shalon
1 year ago
I see both points, but I personally prefer option B. Keeping restricted playbooks in a separate repository adds an extra layer of security.
upvoted 0 times
...
Orville
1 year ago
I disagree, I think option C is more secure. Adding a filter block directly to the playbooks is more foolproof.
upvoted 0 times
...
Nana
1 year ago
I think option A is the best choice. It ensures that only admins can execute the playbooks.
upvoted 0 times
...
Allene
1 year ago
I bet the admin role has a secret handshake or something. Option C is the way to keep those playbooks on lockdown.
upvoted 0 times
Lelia
1 year ago
Definitely, it's important to have measures in place to control who can run certain playbooks.
upvoted 0 times
...
Luisa
1 year ago
Yeah, adding a filter block for runRole = 'Admin' seems like a secure way to restrict access.
upvoted 0 times
...
Fernanda
1 year ago
I agree, option C sounds like the best way to ensure only admins can execute those playbooks.
upvoted 0 times
...
...
Ocie
1 year ago
Ah, the admin role strikes again! Option C is definitely the way to go. Can't have the regular folks messing with the important stuff, right?
upvoted 0 times
...
Lisha
1 year ago
Hmm, I'm not sure about option B. Keeping restricted playbooks in a separate repo seems a bit complex. I'd go with C - the filter block is a straightforward solution.
upvoted 0 times
Lizbeth
1 year ago
True, it depends on the specific requirements of the organization.
upvoted 0 times
...
Ellsworth
1 year ago
That could work too, but I think the filter block is more specific.
upvoted 0 times
...
Laquanda
1 year ago
But wouldn't removing the Execute Playbook capability from non-admin roles also work?
upvoted 0 times
...
Wilford
1 year ago
I agree, option C seems like the simplest solution.
upvoted 0 times
...
Tawny
1 year ago
I see your point. It's important to have a clear restriction in place.
upvoted 0 times
...
Alesia
1 year ago
True, but adding a filter block ensures only admins can run the playbooks.
upvoted 0 times
...
Corinne
1 year ago
But wouldn't removing the Execute Playbook capability work as well?
upvoted 0 times
...
Ruthann
1 year ago
I agree, option C seems like the simplest solution.
upvoted 0 times
...
...
Gennie
1 year ago
Option C looks like the way to go. Filtering for the admin role is a solid approach to ensure only the right people can execute those playbooks.
upvoted 0 times
Katie
1 year ago
True, adding a tag with restricted access could also help in controlling who can execute those playbooks.
upvoted 0 times
...
Erin
1 year ago
That could work too, but adding a filter block seems more specific to the restricted playbooks.
upvoted 0 times
...
Lilli
1 year ago
But wouldn't it be easier to just remove the Execute Playbook capability from all roles except admin?
upvoted 0 times
...
Adrianna
1 year ago
I agree, filtering for the admin role is a good way to restrict access.
upvoted 0 times
...
Sheron
1 year ago
True, adding a tag for restricted access could also help in controlling who can execute the playbooks.
upvoted 0 times
...
Diego
1 year ago
That could work too, but filtering seems more specific to the admin role.
upvoted 0 times
...
Nichelle
1 year ago
But wouldn't removing the Execute Playbook capability from non-admin roles also work?
upvoted 0 times
...
Cathern
1 year ago
I agree, filtering for the admin role is a good way to restrict access.
upvoted 0 times
...
...

Save Cancel