Free SPLK-1002 Practice Test Questions 2026

Explanation

When using the Field Extractor (FX) in Splunk, the delimiter-based extraction method allows you to use any consistent character that separates fields in your data. This includes commas, periods, pipes (|), tabs, spaces, colons, semicolons, or even multi-character strings—as long as the same delimiter appears consistently between fields throughout the data. The Field Extractor lets you specify a custom delimiter if it does not automatically detect one.

❌ Why the other options are incorrect

A. A period or comma.
– This is too restrictive. While periods and commas can be used as delimiters, they are not the only options. The FX supports many other characters and even multi-character delimiters.

B. A comma.
– This is also overly restrictive. Commas are common (especially in CSV data), but they are not the only valid delimiter. Pipes, tabs, spaces, and other characters are equally supported.

C. A tab or space.
– Again, this is too limiting. Tabs and spaces are valid, but the FX is not limited to just these two. The correct answer must reflect the full flexibility of the tool.

References

Splunk Documentation:
"When you use the delimiter method, you can select one of the common delimiters or specify a custom delimiter. The delimiter can be any single character or a string of characters."

Explanation:

When a scheduled report takes longer to run than its scheduled interval (e.g., a 15‑minute schedule but a 17‑minute runtime), it overlaps with the next scheduled run. Splunk will skip or defer the next scheduled execution to prevent multiple instances of the report from running concurrently and overloading system resources. This behavior is designed to protect performance and ensure that report schedules do not pile up.

❌ Why the other options are incorrect

B. Automatically accelerated
– Report acceleration is a feature that pre‑computes and caches results to speed up future runs. It is not triggered by a report taking longer than its schedule. Acceleration is a manual or scheduled setting, not an automatic reaction to a slow run.

C. Deleted
– Splunk does not delete a report just because it takes too long to complete. The report definition remains intact; only the execution is skipped or deferred.

D. All of the above
– Since only skipped/deferred is correct, and acceleration and deletion are not, this option is incorrect.

📚 References

Splunk Documentation:
"Scheduled reports can be skipped if the previous run has not completed. This prevents overlapping runs and performance degradation."

Explanation:

The stats, chart, and timechart commands all support the same set of aggregation functions, such as count, sum, avg, min, max, stdev, values, list, first, last, and dc (distinct count). These are all transforming commands that produce statistical summaries of data. They share identical function syntax, and the only difference lies in how they present results: stats outputs a table, chart outputs a pivot table, and timechart outputs a time‑based series.

❌ Why the other options are incorrect

A. stats, eval, table
– eval is not an aggregation command; it is used to create or evaluate expressions on a per‑event basis (e.g., arithmetic, string manipulation). table is a formatting command that displays specified fields, not an aggregation command. They do not share the same functions.

B. search, where, eval
– search is a filtering command, where is a conditional filtering command, and eval is an expression command. None of these are aggregation commands. They use different syntax and do not share the same functions.

D. transaction, chart, timechart
– transaction is a grouping command that groups events based on conditions (e.g., start/end, time limits). It does not support statistical functions like count, sum, or avg. While chart and timechart share functions, transaction does not, so this set is incorrect.

References

Splunk Documentation:
"The stats, chart, and timechart commands use the same set of statistical functions, including count, sum, avg, min, max, and others."

Explanation:

The fields sidebar in Splunk does not show all extracted fields by default. It only displays a subset of fields based on their prevalence and configuration. Specifically, the sidebar shows:

Interesting fields – Fields that appear in at least 20% of the events (or a configurable threshold) and are considered "interesting" based on certain criteria like high cardinality or variability.

Selected fields – Fields that you have manually selected to appear in the sidebar for easy access.

However, many fields may be extracted from events (e.g., via regex, delimiters, lookups, or automatic extraction) but may not appear in the sidebar if they do not meet the "interesting" threshold or have not been manually selected. The sidebar is not an exhaustive list of every extracted field.

❌ Why the other options are incorrect

A. interesting fields – The fields sidebar does show interesting fields by default. This is one of its primary purposes: to highlight fields that are statistically significant across the result set.

B. selected fields – The fields sidebar does show selected fields. Users can manually select specific fields to pin them to the sidebar for quick access.

📚 References

Splunk Documentation:
"The Fields sidebar shows interesting fields and selected fields. It does not show all fields that are extracted from events by default."

Explanation:

A GET workflow action is specifically designed to take a field value from an event and append it to a URL as a query parameter (or path variable) to open an external website in a new browser window. This is exactly what the user needs: they want to perform an external IP lookup using the extracted domain field. Splunk documentation explicitly provides this exact scenario: "You have configured your Splunk app to extract domain names in web services logs and specify them as a field named domain. You want to be able to search an external WHOIS database for more information about the domains that appear. Here's how you would set up the GET workflow action..." .

❌ Why the other options are incorrect

A. POST
– A POST workflow action sends data in the request body (form‑encoded or JSON) to an external server. It is typically used to submit data, such as creating a ticket in a ticketing system or sending a webhook. It is not used for opening a simple external lookup URL, and it requires more configuration (e.g., parameter names, content type) than a GET action.

B. PUT
– PUT is not a standard workflow action type in Splunk. The three official types are Search, GET, and POST. "PUT" does not exist as an option in the workflow action configuration interface.

D. Search
– A Search workflow action runs a new search inside the same Splunk instance (e.g., index=main domain=$domain$). It does not send data to an external resource. The question explicitly asks for an "external IP lookup," which requires sending data outside Splunk, making Search workflow actions incorrect.

📚 References

Splunk Documentation (Workflow Actions – GET):
"Create a GET workflow action to look up domain names in an external WHOIS database using the extracted domain field."

Explanation:

When you use | timechart by host, the x‑axis represents the _time field. The timechart command always plots time on the x‑axis because it is a time‑based aggregation command. Each data point on the x‑axis corresponds to a time bucket (e.g., 1 minute, 1 hour, 1 day) determined automatically by the search time range or manually set with span=. While the x‑axis label may display human‑readable dates or times (e.g., "12:00 PM"), the underlying field is always _time—Splunk's default timestamp field.

❌ Why the other options are incorrect

A. date
– There is no default field named date in Splunk. The x‑axis displays time values derived from _time, but the field itself is not called date. Even if you see a date format on the axis, the underlying data is _time.

B. host
– The host field is used in the by clause to split the data into separate series (lines or bars). It appears in the legend, not on the x‑axis. The x‑axis is always time‑based.

C. time
– While "time" correctly describes what is on the x‑axis, the actual field name in Splunk is _time (with an underscore). In Splunk exam questions, precision matters. The field is _time, not time. If an option says "time" without the underscore, it is a distractor.

References:

Splunk Documentation:
"The timechart command creates a time series chart. The x‑axis is always _time, and the y‑axis is the aggregated statistic."

📝 Explanation:

The Splunk Common Information Model (CIM) Add-on is a shared semantic model that provides a standardized way to interpret and normalize data at search time . Its primary component is a collection of pre-configured data models for common IT and security domains, such as Authentication, Network Traffic, Web, and Change Analysis .

These data models define a standard set of field names and event tags, allowing you to run consistent reports, dashboards, and correlation searches across data from different vendors . For example, you can use the Authentication data model to analyze login events regardless of whether the source is a Windows, Linux, or firewall log .

❌ Why the other options are incorrect

A. Sourcetype definitions from the most popular technology vendors:
The CIM add-on does not include sourcetype definitions. Sourcetypes are provided by the specific Splunk Add-ons that collect data from those vendors (e.g., Splunk Add-on for Microsoft Windows), which often then map their data to the CIM .

C. Scripted inputs to pre-align data with the CIM:
The CIM does not provide scripted inputs. Its tools are for applying the CIM schema at search-time, not for collecting or pre-processing data before indexing .

D. Dashboards to validate data quality:
While the add-on includes a CIM Validation data model and tools like a custom validation command, the primary deliverable is the set of data models . A "Data Model Audit" dashboard is available to monitor acceleration performance, not general data quality validation . The core offering remains the data models themselves.

Explanation:

The median(X) function in the stats command returns the middle-most value of field X (the median). The median is the value that separates the higher half from the lower half of the data set. It is a statistical aggregation function supported by stats, chart, and timechart.

❌ Why the other options are incorrect

A. Fields(X)
– There is no Fields() function in the stats command. The fields command is used to retain or remove fields, but it is not a statistical aggregation function. This is a distractor.

C. Eval by X
– eval is a separate command used to create or manipulate fields on a per‑event basis. The phrase "by X" suggests grouping, but eval does not return the middle‑most value. There is no eval by syntax in stats.

D. Values(X)
– The values(X) function returns a list of all unique values for field X (as a multivalue field). It does not return the median or any middle value. It shows every distinct value present in the group.

References

Splunk Documentation:
"The median(X) function returns the middle-most value of field X."

SPLK-1002 Exam Blueprint:
Search Commands → stats → Statistical functions.

Explanation:

This command checks whether the field src exists and is not null (i.e., it has a valid value). If src is not null, it sets host equal to the value of src. If src is null or does not exist, it leaves host unchanged (keeping its original value). This exactly matches the requirement: "provide a new value for host from src if it exists."

❌ Why the other options are incorrect

A. | eval host = if (isnu11(src), src, host)
– This contains a typo: isnu11 (with the number "11" instead of two lowercase "l"s). The correct function is isnull(). Because of this typo, the command would fail with a syntax error. Even if corrected to isnull(), the logic would be reversed: it would set host = src only when src is null, which is the opposite of what is needed.

B. | eval host = if (NOT src = host, src, host)
– This checks whether src does not equal host. However, if src is null or missing, src = host would be false, so NOT false = true, and it would incorrectly set host = src (which is null). This logic does not correctly handle missing fields and would overwrite host with a null value in many cases.

C. | eval host = if (src = host, src, host)
– This checks whether src equals host. If they are equal, it sets host = src (no change). If they are not equal, it leaves host unchanged. This would never change host to the value of src when they differ, which defeats the purpose. It does not check whether src exists; it checks for equality instead..

📚 References

Splunk Documentation:
"The isnotnull function returns true if the field exists and is not null."

SPLK-1002 Exam Blueprint:
Search Commands → eval → Conditional functions (if, isnull, isnotnull).

Explanation

In Splunk, when you perform a search, any search terms that match events are highlighted in the raw event data within the search results. This highlighting visually indicates which parts of the event text matched your search criteria. For example, if you search for error, every occurrence of the word "error" in the _raw field of matching events will be highlighted in yellow (or another color) to help you quickly identify why that event was returned.

❌ Why the other options are incorrect

A. Display as selected fields – Highlighted search terms are not automatically displayed as selected fields. "Selected fields" refers to fields that you manually pin to the Fields sidebar. Highlighting is purely a visual indicator in the event preview, not a field selection mechanism.

B. Sorted – Highlighting has nothing to do with sorting. Sorting is controlled by the sort command (e.g., | sort - _time). Highlighting does not affect the order of results.

C. Charted based on time – Highlighting is unrelated to charting or time-based visualization. Charting is achieved with commands like timechart or chart. Highlighting is a display feature only.

📘 Additional exam note
Highlighting applies to literal search terms and field=value matches.
In the event viewer, matched terms appear with a colored background (default yellow).
This feature helps users quickly scan events and verify that the search returned relevant results.

📚 References

Splunk Documentation:
"Search terms that match events are highlighted in the raw event data in search results." https://docs.splunk.com/Documentation/Splunk/latest/Search/Searesults

SPLK-1002 Exam Blueprint:
Search Interface → Search results → Highlighting of matching terms.

Explanation:

The | where A=B command filters events based on a field comparison. It evaluates each event and keeps only those where the value of field A equals the value of field B. This is a conditional filter that operates on field values, not literal strings. For example, if an event has A=100 and B=100, it is kept; if A=100 and B=200, it is dropped.

❌ Why the other options are incorrect

A. Events that contain the string value where A=B. – The where command does not search for literal strings. The syntax | where A=B is a conditional expression, not a text search. This option misunderstands the command as a literal search for the phrase "where A=B", which is incorrect.

B. Events that contain the string value A=B. – This option also treats A=B as a literal string. The where command evaluates field comparisons; it does not search for string patterns. This is a common misconception.

D. Events where field A contains the string value B. – The = operator in where tests for equality, not "contains". If you wanted to test whether field A contains the string "B", you would use | where like(A, "%B%") or | where A="*B*" (depending on syntax). The equals sign (=) means exact match, not substring containment.

📘 Additional exam note
The where command is a streaming command that filters events based on boolean expressions.
It can use comparison operators: =, !=, >, <, >=, <=.
It can also use logical operators: AND, OR, NOT.


📚 References

Splunk Documentation:
"The where command filters search results using eval expressions. It keeps events where the expression evaluates to true."

Explanation:

The | datamodel command is used to search or inspect data models in Splunk. Its syntax is | datamodel (or just the dataset name if the data model is unambiguous). The dataset name (also called the data model object) is required if you want to retrieve actual events. Without specifying a dataset, the command only returns the JSON structure of the data model, not the events themselves. For example, to get events from the Failed_Authentication dataset within the Authentication data model, you would use: | datamodel Authentication Failed_Authentication.

❌ Why the other options are incorrect

A. status field
– There is no requirement to include a status field when using the datamodel command. The dataset may or may not contain a status field, depending on its definition. The command does not mandate any specific field name; it only requires the dataset name.

B. Multiple indexes
– The datamodel command does not require specifying multiple indexes. In fact, data models are designed to work across indexes based on their configured constraints. You do not explicitly list indexes in the command.

C. Data model field name
– The command requires a dataset name, not a generic "field name." A dataset is a specific object within the data model (e.g., Web or Network_Traffic), not an individual field like src or dest. This option confuses the dataset with a field.

📘 Additional exam note
If you omit the dataset name, the datamodel command returns the JSON definition of the data model, which is useful for reference but does not produce a searchable event table.

Data models are collections of datasets (objects) that define constraints and field names for specific use cases (e.g., Authentication, Web, Email).

📚 References

Splunk Documentation:
"The datamodel command can be used to return the JSON of a data model or to search a specific dataset. To search a dataset, specify the data model name and the dataset name."