Free SPLK-1002 Practice Test Questions 2026

Explanation:

Calculated fields in Splunk are search‑time knowledge objects that allow you to define an eval expression once and have it applied automatically to every event that matches a specified condition. They are essentially a shortcut for repetitive and complex eval commands that you would otherwise have to write manually in every search. For example, instead of writing | eval response_time_ms = response_time * 1000 every time, you can create a calculated field that does this automatically.

❌ Why the other options are incorrect

A. Calculated fields are only used on fields added by lookups.
– This is false. Calculated fields can be based on any extracted field (e.g., from regex, delimiters, or automatic extraction). They are not limited to fields added by lookups. In fact, lookup fields are processed after calculated fields, so they cannot be used as sources for calculated fields.

C. Calculated fields are a shortcut for repetitive and complex calc commands.
– There is no calc command in Splunk. The command used for calculations is eval. This option is a distractor using an invalid command name.

D. Calculated fields automatically calculate the simple moving average for indexed fields.
– This is false. Calculated fields can perform any eval expression (arithmetic, string manipulation, conditional logic), but they do not automatically calculate a moving average. You would need to write that logic explicitly.

References

Splunk Documentation – Calculated Fields:
"Calculated fields are a shortcut for repetitive and complex eval commands. They automatically apply an eval expression to events at search time."

Explanation

Data models in Splunk are composed of three distinct dataset types: Event, Search, and Transaction datasets . These types define the structure of each dataset within the data model's hierarchy.

Event datasets are the most common type. They are defined by a constraint—a simple search that filters events relevant to that dataset. For example, a constraint like sourcetype=access_* would filter events to only include web access logs .

Search datasets use an arbitrary Splunk search string, which can include transforming commands, to define the dataset's contents .

Transaction datasets group related events together. They are defined by a transaction definition that identifies one or more group datasets and one or more group-by fields .

❌ Why the other options are incorrect

A. Constraint, field, value:
These are components of dataset definitions, not the dataset types themselves. Constraints filter data , and fields hold values, but they are not dataset categories.

C. Field extraction, regex, delimited:
These are methods for creating fields within a dataset , not the dataset types. You can create auto-extracted, eval, or regex fields, but they do not define a dataset type.

D. Transaction, session ID, metadata:
This option incorrectly mixes components. While transaction is a valid dataset type, session ID and metadata are not types of datasets in Splunk .

📚 References

Splunk Documentation: "There are three types of dataset hierarchies: event, search, and transaction" .

Splunk Documentation: "For a root event dataset or a child dataset of any type, the constraint looks like a simple search... For a root search dataset, the constraint is the dataset search string... For a root transaction dataset, the constraint is the transaction definition" .

Explanation

To view events as a group based on a common field value (JSESSIONID), the transaction command is the appropriate tool. It groups events that share the same value for a specific field (in this case, JSESSIONID), allowing you to correlate and analyze them as a single unit. The | search SD462K101O2F267 then filters the results to only show the transaction that contains that specific session ID.

❌ Why the other options are incorrect

B. index=web sourcetype=access_combined SD462K101O2F267 | table JSESSIONID – This search first filters events with the literal string SD462K101O2F267, then displays only the JSESSIONID field as a table. It does not group events by JSESSIONID; it simply lists the field for matching events.

C. index=web sourcetype=access_combined | highlight JSESSIONID | search SD462K101O2F267 – The highlight command only applies visual formatting to the search results; it does not group or correlate events. This search simply finds events containing the session ID and highlights the field.

D. index=web sourcetype=access_combined JSESSIONID – This is an invalid syntax. In Splunk, JSESSIONID without an equals sign or operator is interpreted as a literal string to search for, not a field. The correct way to search for a field is JSESSIONID=value or by referencing the field in a command.

📚 References

Splunk Docs: transaction command
SPLK-1002 Exam Blueprint: Search Commands → transaction → Grouping events by field.

Explanation

A search macro in Splunk is a knowledge object that contains a reusable piece of SPL (Search Processing Language). Macros allow you to encapsulate complex or frequently used search logic, give it a name, and then use that name in other searches by enclosing it in backticks (e.g., `my_macro`). They can accept arguments to make them dynamic and flexible.

❌ Why the other options are incorrect

A. Lookup definitions in lookup tables
– This describes lookups, not macros. Lookups are used to enrich event data by mapping field values to external data (e.g., CSV files or KV Store). Macros are about reusing search logic, not enriching data.

C. A method to normalize fields
– Field normalization is achieved using field aliases (to rename fields) and the Common Information Model (CIM). Macros are not used for normalizing fields.

D. Categories of search results
– This describes event types, which categorize events based on a search string and add an eventtype field. Macros do not categorize results; they are reusable search snippets.

References

Splunk Documentation – Macros:
"A macro is a reusable piece of search logic that you can use in other searches."

Explanation:

When you manually edit the regular expression generated by the Field Extractor (FX) during the Select Fields or Validate steps, you exit the guided, point-and-click workflow . The Splunk documentation explicitly notes that doing this takes you out of the field extractor workflow . According to the official Field Extractor documentation, you can only abandon the manual editing and return to the automatic workflow if you have not yet tried to preview your regular expression change . Once you click Preview, the option to go back disappears, locking you into the manual editing path .

❌ Why the other options are incorrect

A. There is a limit to the number of fields that can be extracted. There is no such strict limit imposed by editing a regular expression. The Splunk FX can handle multiple fields, and performance limits are distinct from workflow behavior .

B. The user is unable to preview the extractions. This is false. You can always use the Preview button to test your manual edits against sample events and verify accuracy before saving .

C. The extraction is added at index time. This is a fundamental misconception. Fields created with the Field Extractor are search-time operations, applied after data has been indexed, not at index time . Changing index-time fields would require re-indexing data, which is not recommended .

References

Splunk Docs:"You can manually edit the regular expression. However, doing this takes you out of the field extractor workflow."

Splunk Docs: "You can only go back if you have not yet tried to preview a regular expression change."

Explanation:

The stats command in Splunk is used to calculate aggregate statistics over search results. To group results by multiple fields, you list the fields after the BY clause, separated by spaces. In this case, BY page server groups the results by each unique combination of the page and server fields. For example, if you have pages index.html and about.html on servers web01 and web02, you will get four separate rows in the output—each showing the total bytes for that specific page on that specific server.

❌ Why the other options are incorrect

A. | stats sum(bytes) BY page BY server– This is invalid syntax. The stats command supports only one BY clause. You cannot use multiple BY keywords. The correct way to group by multiple fields is to list them after a single BY.

C. | stats sum(bytes) BY page AND server – This is invalid syntax. The AND operator is not used to separate fields in a BY clause. The BY clause expects field names separated by spaces, not logical operators.

D. | stats sum(bytes) BY values(page) values(server) – This is incorrect. The values() function is an aggregation function used within stats to return a multivalue list of all distinct values (e.g., | stats values(page)). It is not part of the BY clause syntax. Placing values() in the BY clause will result in a syntax error.

📚 References

Splunk Documentation – stats command:
"You can specify multiple fields after BY to group results by each unique combination of those fields."

Explanation:

The Splunk Common Information Model (CIM) is a shared semantic model that provides a methodology to normalize data from different sources and source types into a common, consistent format . It acts as a "schema-on-the-fly" applied at search time, allowing you to use the same field names and tags for equivalent events without altering the underlying raw machine data . For instance, the Authentication data model can ingest data from Windows, Cloud Platforms, and VPN logs, ensuring they all use the same fields like src, user, and action .

❌ Why the other options are incorrect

A. The CIM is a prerequisite that any data source must meet to be successfully onboarded into Splunk. This is incorrect. Data can be onboarded without CIM compliance. The CIM is a search-time tool applied after data is indexed, not a prerequisite for ingestion .

C. The CIM defines an ecosystem of apps that can be fully supported by Splunk. This is incorrect. While many apps like Splunk Enterprise Security use the CIM, it does not define an app ecosystem; it is a data normalization model .

D. The CIM is a data exchange initiative between software vendors. This is incorrect. The CIM is an internal Splunk methodology for normalizing data within your deployment, not a protocol for exchanging data between vendors .

📚 References

Splunk Docs: "The Splunk Common Information Model (CIM) is a shared semantic model focused on extracting value from data. The CIM... supports the consistent, normalized treatment of data..."

Explanation:

This search correctly uses the stats command to calculate the total sum of categoryID values for each unique host. The syntax is correct: sum(categoryID) specifies the numeric field to aggregate, and by host defines the grouping field. The result is a table where each row shows a host and the sum of all categoryID values associated with it.

❌ Why the other options are incorrect

A. Sourcetype=access_* | sum bytes by host – This is invalid syntax. There is no standalone sum command in Splunk. The sum() function must be used within a command like stats, chart, or timechart. Additionally, the field name bytes is separated from the function by a space, which is not allowed.

C. Sourcetype=access_* | sum(bytes) by host – This is also invalid syntax for the same reason as A. The sum() function must be used inside stats. A standalone sum(bytes) by host is not recognized by Splunk.

D. Sourcetype=access_* | stats sum by host – This is invalid because the sum function requires a field name. Without specifying a field (e.g., sum(categoryID)), Splunk does not know what to sum, and the command will fail with a syntax error.

📚 References

Splunk Documentation – stats command:
"The stats command requires a function and a field name. For example, sum(categoryID)."

Explanation:

In Splunk, workflow actions are knowledge objects that allow you to interact with external systems or run additional searches based on field values in your events. When you create a workflow action, you must select an Action type. The available types are:

GET (labeled as Link in the configuration interface)
POST
Search

If the action type is set to Link, it corresponds to a GET workflow action. This creates a hyperlink that opens an external URL or resource, with field values passed as query parameters. For example, you can create a GET workflow action that links to a WHOIS lookup website using the $domain$ field from the event.

❌ Why the other options are incorrect

B. PUT – This is not a workflow action type in Splunk. The only supported types are GET, POST, and Search. PUT is an HTTP method used in APIs, but it is not available as a workflow action option.

C. Search – A Search workflow action runs a new search within the same Splunk instance, not a link to an external resource. It opens a new search window or tab with the field value as part of the search query. It is not labeled as "Link."

D. UPDATE – This is not a workflow action type in Splunk. UPDATE is not a supported option in the workflow action configuration.

📚 References

Splunk Documentation – Workflow Actions:
"When you set the Action type to Link, you are creating a GET workflow action."

Explanation:

An event type in Splunk is defined by a search string that categorizes events based on specific criteria. The search string must be a valid Splunk search that returns a set of events. Option C (index=games sourcetype=score player=* score>9999) is a simple, straightforward search that filters events from the games index with the score sourcetype, where the player field exists (player=*) and the score field is greater than 9999. This is exactly the type of search used to define an event type.

❌ Why the other options are incorrect

A. index=games sourcetype=score [search index=players | fields player_id] – This contains a subsearch, which is not allowed when defining an event type. Event types only support simple search strings, not subsearches or complex commands.

B. index=games sourcetype=score | where score>9999 – This uses the where command, which is a post-processing command. Event type definitions cannot contain commands like where, stats, chart, or timechart. They must be simple search filters without piping commands.

D. index=games sourcetype=score | stats count by player – This uses the stats command, which is a transforming command. Event types cannot be defined using transforming commands because they change the structure of the results.

📚 References

Splunk Documentation – Event Types:
"An event type is a search string that categorizes events. It cannot contain subsearches or transforming commands."

Explanation

For the search index=security sourcetype=linux_secure | timechart count by action, the timechart command always plots time on the x‑axis. The underlying field used is _time, which is Splunk's default timestamp field. Each data point on the x‑axis corresponds to a time bucket (e.g., per minute, hour, or day) determined automatically based on the search time range.

❌ Why the other options are incorrect

A. action – The action field is used in the by clause to split the data into separate series (e.g., accept, deny). These values appear in the legend or as separate lines/bars, but they do not populate the x‑axis.

B. sourcetype – The sourcetype is used only to filter events (sourcetype=linux_secure). It does not appear in the output or on the x‑axis.

D. time – While the concept of time is correct, the actual field name is _time (with an underscore). In Splunk exam questions, precision matters. The field is _time, not time.

📘 Additional exam note

The x‑axis in timechart always represents _time.
The y‑axis shows the aggregated values (e.g., count).
The by clause determines the series that are split and displayed separately.

📚 References

Splunk Documentation – timechart command:
"The timechart command creates a time series chart. The x‑axis is always _time."

Explanation:

Why C is correct:The fields command is an internal optimization command in Splunk. By using | fields action productid status, you tell Splunk to keep only these specific fields and discard the rest from the search pipeline. This significantly increases search performance because Splunk can optimize the search head's memory and avoid processing or displaying unnecessary fields in the fields sidebar.

Why A is incorrect: The text after the pipe (|) represents a command (fields) and its arguments, not literal search strings or keywords being searched inside the raw logs.

Why B is incorrect: The search explicitly utilizes the fields command, not the table command.

Why D is incorrect: The fields command does not change the structural layout of the data or format it into a row-and-column grid visualization. It leaves the results in their original raw event format, simply stripping away the metadata of unspecified fields. The table command is required to return a formal table structure.

Reference

Splunk Documentation: Search Reference -> fields.
Performance Rule: Using the fields command early in a search pipeline limits the data that Splunk needs to retain in memory, optimizing search speed and resource consumption.