Creating and Using Workflow Actions for Splunk Core Certified Power User

This page covers the Creating and Using Workflow Actions domain of the Splunk Core Certified Power User certification. Master Cybersecurity offers 25 practice questions in this domain, drawn from the same content we use across our timed exam simulations. Below are five sample questions with full answer explanations.

Sample Practice Questions

  1. Question 1

    Which workflow action method can be used when the action type is set to link?
    1. A. GET
    2. B. PUT
    3. C. Search
    4. D. UPDATE
    Explanation

    The correct answer is: A. GET.

    When the action type is set to link, the available methods are GET and POST, so GET is the valid choice among these options. A link action builds a URL from the event's field values and issues a request to it, with GET appending the values into the URL for retrieval and POST sending them in the request body for submission. PUT and UPDATE are not offered, and although both are meaningful HTTP verbs in other contexts, the workflow action configuration exposes only the two. Search is not a method at all, since it is the other action type, and choosing it replaces the URI configuration with a search string rather than adding a method to a link. Keeping the two levels straight is what this question tests, because type comes first and only the link type presents a method choice.

  2. Question 2

    Information needed to create a GET workflow action includes which of the following? (Choose all that apply.)
    1. A. A name for the workflow action.
    2. B. A URI where the user will be directed at search time.
    3. C. A label that will appear in the Event Action menu at search time.
    4. D. A name for the URI where the user will be directed at search time.
    Explanation

    The correct answers are: A. A name for the workflow action., B. A URI where the user will be directed at search time., C. A label that will appear in the Event Action menu at search time..

    Three pieces of information are needed. A name identifies the workflow action within configuration, which is how it is listed and managed. A URI specifies where the user is directed when the action fires, and it is where field tokens are embedded so the request carries values from the selected event. A label supplies the text the user actually sees in the Event Actions menu, and it can also include field tokens so the menu entry displays the value it will act on. The remaining option asks for a name for the URI, which is not a configuration element, because the URI is entered directly as an address and has no separate name of its own. Distinguishing the action's name from its label is the useful takeaway, since one is internal and the other is what appears in the interface.

  3. Question 3

    When creating a Search workflow action, which field is required?
    1. A. Search string
    2. B. Data model name
    3. C. Permission setting
    4. D. An eval statement
    Explanation

    The correct answer is: A. Search string.

    A Search workflow action is defined by its search string, which is the one required field, because that string is what the action runs when invoked. It normally contains field tokens so values from the selected event are substituted in, which is what makes the secondary search specific to what the user clicked. A data model name is not required, since the action runs SPL directly rather than querying a model. Permission settings are not a required field either, because like other knowledge objects an action has permissions, but they default and can be adjusted later rather than being mandatory at creation. An eval statement is not required, though eval may appear inside the search string like any other command. The essential idea is that the search string is the substance of this action, just as the URI is the substance of a link action.

  4. Question 4

    Which of the following statements describes POST workflow actions?
    1. A. Configuration of a POST workflow action includes choosing a sourcetype.
    2. B. POST workflow actions can be configured to send email to the URI location.
    3. C. By default, POST workflow actions are shown in both the event and field menus.
    4. D. POST workflow actions can be configured to send POST arguments to the URI location.
    Explanation

    The correct answer is: D. POST workflow actions can be configured to send POST arguments to the URI location..

    A POST workflow action sends POST arguments to the URI, which is exactly what distinguishes it from a GET: the values travel in the request body as key-value pairs you configure, rather than being appended to the URL. Those arguments can mix literal text with field tokens, so the receiving system gets both fixed parameters and values drawn from the event. Choosing a sourcetype is not part of the configuration in the sense implied, because an action can be scoped so it appears only for certain events, but a sourcetype is not a required element of defining a POST. Sending email to a URI is not something a workflow action does, since email is generated by alert actions instead. And POST actions are not shown in both menus by default, because where an action appears, in the event menu or the field menu or both, is a setting you choose.

  5. Question 5

    Which workflow uses field values to perform a secondary search?
    1. A. POST
    2. B. Action
    3. C. Search
    4. D. Sub-search
    Explanation

    The correct answer is: C. Search.

    Splunk supports exactly two kinds of workflow action, and the search type is the one that takes field values from the event you clicked and uses them to launch a secondary search. You define it with an SPL template containing field tokens such as $src_ip$, and Splunk substitutes the values from that specific event when the action is invoked, which is what makes the resulting search event-specific rather than static. The other supported type is a link action, which builds a URL and issues it as either a GET or a POST to an external system, useful for pivoting into a ticketing tool or a threat-intelligence service but incapable of running a Splunk search. POST is therefore a method available to the link type rather than a workflow action type in its own right. Action is simply part of the feature's name and identifies nothing. Sub-search is not a workflow action type at all; a subsearch is an unrelated SPL construct in which a search enclosed in square brackets supplies values to an outer search.

Other Splunk Core Certified Power User domains

Practice all 25 Creating and Using Workflow Actions questions · Browse Splunk Core Certified Power User