Creating and Using Macros for Splunk Core Certified Power User

Sample Practice Questions

1. Question 1

   When can a pipe follow a macro?
   1. A. A pipe may always follow a macro.
   2. B. The current user must own the macro.
   3. C. The macro must be defined in the current app.
   4. D. Only when sharing is set to global for the macro.
   Explanation

   The correct answer is: A. A pipe may always follow a macro..

   A macro expands to whatever SPL its definition contains, and once that text is substituted the search is parsed as though you had typed the expanded string yourself. Because of that, a pipe can always follow a macro reference: the pipe simply separates the expanded fragment from whatever command comes next, exactly as it would between any two commands. Ownership is irrelevant here, since it governs whether a user can see or edit the macro through permissions rather than whether the resulting SPL can be piped. The app a macro is defined in likewise affects only visibility and sharing scope, so a macro available to your search context can be piped from regardless of which app holds its definition. Setting sharing to global widens who may use the macro but has no bearing on syntax. The only thing worth watching is what the definition itself expands to, since a definition that already ends in a pipe followed by another pipe in the search would produce a malformed string.

2. Question 2

   What is required for a macro to accept three arguments?
   1. A. The macro's name ends with (3).
   2. B. The macro's name starts with (3).
   3. C. The macro's argument count setting is 3 or more.
   4. D. Nothing, all macros can accept any number of arguments.
   Explanation

   The correct answer is: A. The macro's name ends with (3)..

   A macro's arity is declared in its name, so a macro that accepts three arguments must be named with (3) appended, as in my_macro(3). Splunk uses that suffix to resolve which definition a reference points at, which is what lets my_macro(1) and my_macro(3) exist side by side as distinct macros differentiated only by how many arguments the caller supplies. Putting the count at the start of the name is invalid, since the parenthesised count is a suffix by definition and a leading parenthesis would not parse as part of a name. There is no separate argument count setting to configure either; the count is inherent in the name, while a distinct Arguments field holds the comma-separated argument names the definition refers to as placeholder tokens. It is also untrue that all macros accept any number of arguments, because a macro defined without a count takes none, and calling one with arguments it was not defined to accept fails to resolve.

3. Question 3

   Which of the following statements about macros is true? (Choose all that apply.)
   1. A. Arguments are defined at execution time.
   2. B. Arguments are defined when the macro is created.
   3. C. Argument values are used to resolve the search string at execution time.
   4. D. Argument values are used to resolve the search string when the macro is created.
   Explanation

   The correct answers are: B. Arguments are defined when the macro is created., C. Argument values are used to resolve the search string at execution time..

   Arguments are declared when the macro is created, in the Arguments field of its definition, where you list the names the SPL body will reference as dollar-delimited placeholders. That declaration is static configuration and stays fixed until someone edits the macro. What happens at execution time is substitution: the values the caller supplies in the reference are inserted into those placeholders to produce the final search string, which is then parsed and run. Keeping those two ideas apart is the whole point here, since the names are design-time and the values are run-time. Saying arguments are defined at execution time confuses the values with the declaration, because nothing about the macro's structure changes when it is called. Saying the values resolve the search string at creation time is equally wrong, since at creation the definition still holds unresolved placeholders; a macro is stored as a template and becomes concrete SPL only when invoked.

4. Question 4

   Which of the following searches show a valid use of a macro? (Choose all that apply.)
   1. A. index=main source=mySource oldField=* |'makeMyField(oldField)'| table _time newField
   2. B. index=main source=mySource oldField=* | stats if('makeMyField(oldField)') | table _time newField
   3. C. index=main source=mySource oldField=* | eval newField='makeMyField(oldField)'| table _time newField
   4. D. index=main source=mySource oldField=* | "'newField('makeMyField(oldField)')'" | table _time newField
   Explanation

   The correct answers are: A. index=main source=mySource oldField=* |'makeMyField(oldField)'| table _time newField, C. index=main source=mySource oldField=* | eval newField='makeMyField(oldField)'| table _time newField.

   Two of these are valid, and they illustrate the two places a macro reference legitimately appears. In the first, the reference stands where a command belongs, between two pipes, so the definition expands into the pipeline as a command fragment. In the third it appears on the right side of an eval assignment, where the definition expands into an expression producing the new field's value, which is the usual way to package a reusable calculation. The stats example fails for a reason unrelated to the macro: if is an eval function rather than a stats aggregation, so the surrounding SPL is invalid no matter what the reference expands to. The last option buries the reference inside nested quoted strings, which turns the whole construct into a string literal rather than a command. A macro reference must sit in the search as bare SPL delimited by backtick characters, because quoting it prevents expansion entirely.

5. Question 5

   Which of the following statements describes macros?
   1. A. A macro is a reusable search string that must contain the full search.
   2. B. A macro is a reusable search string that must have a fixed time range.
   3. C. A macro is a reusable search string that may have a flexible time range.
   4. D. A macro is a reusable search string that must contain only a portion of the search.
   Explanation

   The correct answer is: C. A macro is a reusable search string that may have a flexible time range..

   A macro may carry a time range, and that range is flexible rather than mandatory: you can define the macro to include time modifiers such as earliest and latest, or leave time entirely to the search that calls it. That flexibility is what makes macros practical across contexts, since the same fragment can be reused under a dashboard's time picker in one place and under a fixed window in another. The requirement that a macro contain the full search is wrong, because the most common use is a fragment such as a stats clause or a filter stitched into a larger pipeline. The claim that a macro must contain only a portion of a search is the mirror-image error, since a macro is perfectly capable of holding a complete search from the index specification onward. Insisting on a fixed time range is wrong as well, and doing so would defeat reuse by pinning every caller to the same window.

Other Splunk Core Certified Power User domains

• Correlating Events (24 questions)
• Creating and Managing Fields (21 questions)
• Creating and Using Workflow Actions (25 questions)
• Creating Data Models (27 questions)
• Creating Field Aliases and Calculated Fields (22 questions)
• Creating Tags and Event Types (21 questions)
• Filtering and Formatting Results (27 questions)
• Using the Common Information Model (CIM) (17 questions)
• Using Transforming Commands for Visualizations (19 questions)