Free SPLK-1002 Practice Test Questions 2026

Explanation:

A macro in Splunk is a knowledge object that allows you to save a reusable piece of search logic (e.g., a complex search string, an eval expression, or a set of filtering conditions) and give it a name. You can then call that macro in any search by enclosing it in backticks (e.g., |my_macro). Macros help reduce repetitive typing, simplify complex searches, and ensure consistency across searches, reports, and dashboards.

❌ Why the other options are incorrect

A. A macro is a method of categorizing events based on a search. – This describes an event type, not a macro. Event types categorize events using a search string and add an eventtype field. Macros do not categorize events; they are simply reusable search snippets.

B. A macro is a way to associate an additional (new) name with an existing field name. – This describes a field alias, not a macro. Field aliases allow you to give an existing field a secondary name (e.g., alias client_ip to src). Macros do not rename fields.

D. A macro is a knowledge object that enables you to schedule searches for specific events. – This describes a scheduled search (or report), not a macro. Scheduled searches run at defined intervals and can trigger alerts. Macros are not scheduled; they are called manually within other searches.

References

Splunk Documentation:
"A macro is a reusable piece of search logic that you can use in other searches. It can be a simple string or include arguments."

Explanation:

The descriptions of the data models that come with the Splunk Common Information Model (CIM) Add-on are documented in the CIM Add-on manual. Specifically, the Data Models chapter of this manual provides reference documentation for the fields and tags that make up each data model. The manual contains a full listing of all data models included with the add-on, such as Authentication, Network Traffic, Web, Email, and many others, along with the expected fields and tags for each dataset. The official documentation explicitly states that you should refer to these reference tables to determine what tags and fields are expected for each dataset in a data model.

❌ Why the other options are incorrect

A. Search and reporting user manual
– This manual covers general search and reporting functionality in Splunk, but it does not provide detailed descriptions of CIM data models. The CIM-specific documentation is maintained separately in the CIM Add-on manual.

C. Pivot users manual
– While Pivot does allow you to interact with data models and create reports, the detailed field descriptions and data model reference tables are documented in the CIM Add-on manual, not the Pivot manual.

D. Datamodel command reference guide
– The datamodel command reference describes the syntax and usage of the command itself, but it does not provide comprehensive descriptions of all CIM data models and their fields.

📚 References

Splunk CIM Add-on Manual: "The Data Models chapter of this manual provides reference documentation for the fields and tags that make up each data model."

Splunk Documentation: The CIM Add-on contains a collection of preconfigured data models, and the manual includes a CIM fields per associated data model section that lists all fields and the models they belong to.

Explanation:

The maxspan option in the transaction command sets the maximum total time span between the earliest and latest events within a single transaction. When the time difference between the first and last event exceeds this limit, the transaction is closed and a new one begins. This is exactly what the question describes: "the maximum total time between the earliest and latest events returned." For example, | transaction host maxspan=5m ensures that a transaction includes only events from the same host that occur within a 5‑minute window from the first to the last event.

❌ Why the other options are incorrect

A. maxpause
– This option sets the maximum idle time (pause) between consecutive events in a transaction. If the gap between two sequential events exceeds maxpause, the transaction is closed. It does not control the total time span from first to last event. For instance, if maxpause=30s, a transaction closes if no new event appears within 30 seconds of the last event, regardless of the total transaction length.

B. endswith
– This option defines a condition (e.g., endswith="logout") that marks the last event in a transaction. It does not enforce any time limit. It is purely content‑based, not time‑based.

C. maxduration
– There is no maxduration option for the transaction command in Splunk. This is a distractor. The correct time‑span control option is maxspan, not maxduration.

References

Splunk Documentation:
"The maxspan option specifies the maximum time span of a transaction, from the first event to the last event."

Explanation:

In Splunk, text enclosed in backticks (`) indicates a macro. The search `third_party_outages(EMEA,-24h)` executes a macro named third_party_outages and passes two arguments to it: EMEA and -24h. The macro definition will substitute these arguments into predefined search logic (e.g., index=outages region=$arg1$ earliest=$arg2$). Macros are reusable search snippets that can accept parameters to make them dynamic.

❌ Why the other options are incorrect

A. This search will find all events for the third_party_outages event type that have "EMEA" or "-24h" in the raw event data. –
The backticks indicate a macro, not an event type. Event types are searched with eventtype=third_party_outages, not with backticks. Also, this misinterprets the arguments as literal text to search for in the raw data.

B. This search will run the third_party_outages saved search and filter for events containing "EMEA" and "-24h" in the raw event data. –
Saved searches are not called with backticks; they are used in scheduled reports or alerts. Additionally, the arguments are macro parameters, not literal strings to search in _raw.

D. This search will find all events in the third_party_outages index with the tags EMEA and -24h. –
There is no index named third_party_outages indicated here. The syntax is a macro call, not an index reference. Tags are searched with tag=..., not with backticks.

📚 References

Splunk Documentation:
"Macros are enclosed in backticks and can accept arguments. When you call a macro, you pass the arguments in parentheses."

Explanation

When configuring a Search workflow action in Splunk, you have the option to define the time range for the new search that will be opened. To make the secondary search use the same time range as the original search that produced the results, you simply check the box labeled "Use the same time range as the search that created the field listing". This ensures the new search inherits the exact time constraints from the parent search, providing consistent and relevant results.

❌ Why the other options are incorrect

A. Set the earliest time to match the original search.
– The workflow action configuration only allows you to enter static time modifiers (e.g., -24h, -7d@d) in the Earliest time and Latest time fields. There is no dynamic option to automatically replicate the original search's time range using these fields. The checkbox is the correct mechanism for this.

B. Select the same time range from the time-range picker.
– The workflow action configuration does not include the standard time‑range picker. It uses text fields for specifying relative time strings. You cannot "select" a time range from a picker in this context.

D. Select the "Overwrite time range with the original search" checkbox.
– There is no checkbox with this label in the workflow action configuration. The actual label is "Use the same time range as the search that created the field listing." The wording in option D is incorrect and does not exist.

References

Splunk Documentation:
"To use the same time range as the original search, select 'Use the same time range as the search that created the field listing'."

Explanation:

TThis search does the following:
index=games – retrieves events from the games index.
| stats count as IP_count by IP – counts occurrences of each unique IP value and stores the count in a new field called IP_count.
| where IP_count > 5 – filters the results to keep only those rows where the count is greater than 5 (i.e., IP addresses present more than five times).
This is the correct sequence to achieve the requirement.

❌ Why the other options are incorrect

B. index=games | search IP_Count > 5
– This is missing the stats command entirely. IP_Count does not exist in the raw events, so search IP_Count > 5 would return no results because the field has not been created yet. You must use stats first to generate the count field.

C. index=games | where IP > 5
– This is incorrect because it compares the IP field (which contains IP addresses like 192.168.1.1) to the number 5. This is a type mismatch; you cannot compare an IP address string to an integer. It would not produce the desired result.

D. index=games | search IP > 5
– This has the same issue as option C: it compares the IP field to a numeric value. Also, search is less efficient than where for post‑processing filtering, and it still lacks the required stats command.

References

Splunk Documentation:
"Use stats with the count function to count occurrences, then use where to filter the aggregated results."

Explanation:

A user would select delimited field extractions in the Field Extractor (FX) when the data is structured with a consistent delimiter that separates fields. Common examples include comma‑separated values (CSV), pipe‑delimited (|), tab‑separated (TSV), or space‑delimited logs. The FX can automatically detect the delimiter and assign each column to a field, making it the quickest and most accurate method for such data.

❌ Why the other options are incorrect

B. When a log file contains empty lines or comments.
– The FX delimiter method requires clean, consistent data. Empty lines or comment lines would break delimiter‑based extraction because they do not contain the same number of fields or delimiters. In such cases, you would use regular expressions or pre‑process the data to remove invalid lines before extraction.

C. With structured files such as JSON or XML.
– JSON and XML are not delimiter‑based formats; they are hierarchical structured data. For JSON, you would use automatic key‑value extraction or the spath command. For XML, you would use the xpath command or dedicated add‑ons. Delimiters are not appropriate for nested or hierarchical data.

D. When the file has a header that might provide information about its structure or format.
– The FX delimiter method can use a header row to name fields (e.g., in CSV with column headers), but the presence of a header alone is not the reason to choose delimiters. The key factor is the consistent delimiter between values. Headers are optional and only help with field naming, not with choosing the extraction method.

References

Splunk Documentation:
"Select Delimiters when your data has a consistent separator, such as commas, pipes, or tabs, between each field."

Explanation:

A macro that accepts two arguments is defined using parentheses ( ) containing the argument placeholders, separated by a comma. For example, if the macro definition is samplemacro(1,2), it means the macro expects two arguments when called. When you actually call the macro in a search, you use backticks and pass actual values: `samplemacro(EMEA,-24h)`. The definition itself uses numbered placeholders ($1$, $2$) to reference the arguments passed. Option B correctly represents the macro definition syntax.

❌ Why the other options are incorrect

A. samplemacro [1,2]
– This uses square brackets [ ], which are not valid for macro definitions. Splunk uses parentheses for macro arguments, not brackets. Square brackets are used in other contexts (e.g., subsearch syntax), but not for macro parameters.

C. samplemacro (2)
– This contains a space between the macro name and the opening parenthesis. Splunk macro syntax does not allow a space; the parentheses must immediately follow the macro name (e.g., samplemacro(2)). Additionally, it only shows one argument, not two.

D. samplemacro[2]
– This uses square brackets and only specifies one argument. It is incorrect for the same reason as option A: brackets are not used for macro arguments, and it does not represent a macro accepting two arguments.

References

Splunk Documentation:
"When defining a macro, specify the arguments in parentheses after the macro name. For example, mymacro(1,2)."

Explanation

In Splunk, you define tags on specific field-value pairs, not just as global labels . To search for events where the tag "alert" is associated specifically with the host field (e.g., the tag was applied to host=webserver01), the correct syntax is tag::host=alert. The official documentation confirms this: "To search for a tag associated with a value in a specific field, use the following syntax: tag::=" .

This syntax explicitly restricts the search to only those events where the tag is attached to the host field, providing the precision the user needs.

❌ Why the other options are incorrect

A. tag=alert: This searches for the tag "alert" on any field . If the tag is also applied to sourcetype=apache or status=500, this search would return those events as well, making it too broad and failing to limit results to the host field only.

B. host::tag::alert: This is invalid syntax. The correct format places the field name immediately after the double colon (::), preceding the equals sign and the tag name, as shown in the documentation .

C. tag==alert: This uses an incorrect operator. The correct delimiter for tag searches is a single equals sign (=) . A double equals sign (==) is not valid in this context.

References

Splunk Documentation: "To search for a tag associated with a value in a specific field, use the following syntax: tag::="

Explanation

The transaction command in Splunk allows you to correlate events across multiple sources, hosts, or time periods into a single group (transaction). It groups events that share a common field (e.g., session_id, src_ip, user) and can span different source types or log files. This is useful for analyzing complex workflows, such as a user session that generates events across web servers, application servers, and databases.

❌ Why the other options are incorrect

A. duplicate – The transaction command does not duplicate events. It groups existing events into transactions but does not create copies of them.

C. persist – transaction does not persist events or make them permanent; it is a search‑time grouping command. Persistence is handled by indexing or summary indexing, not by transaction.

D. tag – While transaction can be used to group events and potentially apply tags, its primary purpose is correlating events, not tagging them. Tagging is done using the tag command or via knowledge objects like tags and event types.

References

Splunk Documentation:
"The transaction command groups related events into a single transaction, allowing you to correlate events that occur across multiple sources."

Explanation

The time range specified for a historical search defines the time range for the static results—that is, the fixed window of time from which events are retrieved and displayed. Historical searches run against already‑indexed data and return a static set of results based on the time range you specify (e.g., earliest=-7d@d latest=now). The results do not change after the search completes unless you run it again. This contrasts with real‑time searches, which continuously update.

❌ Why the other options are incorrect

A. Amount of data shown on the timeline as data streams in
– This describes a real‑time search, not a historical one. In real‑time searches, data streams in continuously, and the timeline updates dynamically. Historical searches do not "stream in" new data; they query fixed index data.

B. Amount of data fetched from index matching that time range
– While this is technically true (the time range does determine what data is fetched), it focuses on the mechanism (fetching from the index) rather than the result (static results). The exam emphasizes that historical searches produce static results, not just that they fetch data. Option C is more precise because it describes the outcome from the user's perspective: the results are fixed to that time range.

References

Splunk Documentation:
"A historical search runs over a specified time range and returns static results."

Explanation:

When defining a macro in Splunk, the required elements are:

Name – A unique identifier for the macro (e.g., my_filter).
Definition – The actual search string or SPL snippet that the macro represents (e.g., index=main sourcetype=access_* status=404).

Without both a name and a definition, the macro cannot be created or called. Arguments are optional, not required.

❌ Why the other options are incorrect

A. Name and arguments – Arguments are optional; a macro can be defined without any arguments. A definition is required, but this option omits it.

B. Name and a validation error message– A validation error message is not a required element. It is an optional field that appears when the macro is used incorrectly.

D. Definition and arguments – While both can be present, arguments are not required. A valid macro can be defined with just a name and a definition. This option omits the required name.

References

Splunk Documentation:
"To define a macro, you must provide a name and a definition. Arguments and other fields are optional."