Free SPLK-1002 Practice Test Questions 2026

Explanation:

The CIM Add-on is a collection of pre-configured data models that serve as a search-time schema for normalizing data . The key resource for this process is the Data Models chapter of the CIM manual, which provides reference tables for the fields and tags that constitute each data model .

The documentation explicitly states that you should "refer to the reference tables to determine what tags and fields are expected for each dataset in a data model as you work to normalize a new data source to the CIM" . This involves using the tables to identify the correct tags that need to be applied to your data and the standard field names that your fields should be mapped to via aliases .

❌ Why the other options are incorrect

B. Run a search using the authentication command.
There is no standard authentication command used for CIM normalization. While Authentication is the name of a CIM data model, the process involves configuration, not a specific search command.

C. Consult the CIM event type reference tables.
The CIM manual provides data model reference tables . The tables outline required tags and expected fields, not "event type reference tables." The concept of event types is a separate part of the normalization process (used to apply tags), but it is the data model tables that are the central reference .

D. Run a search using the correlation command.
There is no standard correlation command in Splunk for this purpose. Normalization is achieved by configuring event types and field aliases, not by running a correlation search .

📚 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. Refer to the reference tables to determine what tags and fields are expected for each dataset in a data model as you work to normalize a new data source to the CIM" .

📝 Explanation:

Splunk protects the integrity of accelerated data models by locking them against structural changes. The official documentation states this explicitly: "After you accelerate a data model, you cannot edit it. To make changes to an accelerated data model, you must disable its acceleration" .

This restriction ensures that the pre-computed data summaries (which run against the full _raw data for speed) remain consistent with the data model's definition. Once acceleration is disabled, you can freely edit the data model's structure and constraints . After making your edits, you must re-enable acceleration to rebuild the summary from scratch, which can be resource-intensive for large deployments .

❌ Why the other options are incorrect

A. An accelerated data model can be edited once its .tsidx file has expired.
– The .tsidx file is Splunk's index file structure, not a data model acceleration summary. There is no expiration that unlocks editing; acceleration must be manually disabled.

B. An accelerated data model can be edited from the Pivot tool.
– The Pivot tool is for creating reports using data models, not for editing the data model structure itself . Structural edits must be done in the Data Models management page after disabling acceleration.

D. It cannot be edited. A new data model would need to be created.
– This is incorrect. You are allowed to edit an accelerated data model, but the process explicitly requires you to de-accelerate it first .

📚 References

Splunk Knowledge Manager Manual: "After you accelerate a data model, you cannot edit it. To make changes to an accelerated data model, you must disable its acceleration" .

Explanation

Tags in Splunk are knowledge objects applied to field-value pairs (e.g., host=webserver01 with tag production). Their primary purpose is to group related data together by adding meaningful labels that make it easier to search, filter, and understand events. For example, you can tag all events from a specific IP address range as internal or external, allowing you to quickly identify or group those events in searches.

❌ Why the other options are incorrect

A. Tags look for less specific data. – This is the opposite of what tags do. Tags add specificity and context to data, making it more meaningful and easier to categorize. They do not make searches less specific.

B. Tags visualize data with graphs and charts. – Visualization is done by charting commands like timechart, chart, and geostats, not by tags. Tags are metadata labels; they do not create visualizations.

D. Tags add fields to the raw event data. – Tags do not add fields to _raw or indexed data. They are applied at search time and do not alter the original raw event. They are search-time knowledge objects, not index-time modifications.

📚 References

Splunk Documentation – Tags:
"Tags are search-time knowledge objects that help you group related data together and make events easier to understand."

Explanation:

To create a GET workflow action, you are required to provide the following information:

A. A name of the workflow action – This is a unique identifier for the workflow action. It is used internally to reference the action in configurations and permissions.

B. A URI where the user will be directed at search time – This is the destination URL (Uniform Resource Identifier) that the workflow action will open when a user clicks on it. The URI can include field names enclosed in dollar signs (e.g., http://whois.net/whois/$domain$) to pass event data to the external resource.

C. A label that will appear in the Event Action menu at search time – This is the text displayed to users in the Event Actions dropdown when they click on an event. The label should be descriptive so users understand what the action will do (e.g., "Lookup IP on VirusTotal").

❌ Why the other option is incorrect

D. A name for the URI where the user will be directed at search time
– This is not a required field. The URI itself is the destination URL; you do not provide a separate "name" for the URI. The workflow action has its own name (option A), and the URI is simply the target address. This option is redundant and does not exist in the configuration.

References

Splunk Documentation – Workflow Actions:
"To create a GET workflow action, you need a name, a label, and a URI. The label appears in the Event Action menu."

Explanation

Splunk offers three search modes—Fast, Smart, and Verbose—that control how many fields are returned and displayed in the fields sidebar and event data. Among these, Verbose is the only mode that automatically returns all extracted fields in the fields sidebar. This mode is designed for maximum visibility and analysis, ensuring that every field extracted from the events is available for inspection, filtering, and use in subsequent searches.

❌ Why the other options are incorrect

A. Fast
– This mode is optimized for performance. It returns only the fields required for the search (such as _time, host, source, sourcetype) and any fields you explicitly specify with the fields command. It does not automatically return all extracted fields, making it the least comprehensive mode but the fastest.

B. Smart
– This is the default search mode. It returns interesting fields (those that appear in at least 20% of events, or a configurable threshold) and any fields you have manually selected. It strikes a balance between performance and visibility. However, it does not return all extracted fields; many fields may be extracted but not displayed in the sidebar unless they meet the interesting threshold or are manually selected.

📚 References

Splunk Documentation – Search Modes:
"Verbose search mode returns all fields from the events. Fast mode returns only the fields necessary for the search. Smart mode returns interesting fields and selected fields."

Explanation:

When creating a data model, the root event dataset is the one that requires at least one constraint, as this is fundamental to its definition . This constraint is a simple search that filters out irrelevant events, defining the initial scope of the dataset. For example, a constraint might look like sourcetype=access_* to capture web access logs . Without at least one constraint, a root event dataset cannot be saved .

❌ Why the other options are incorrect

B. Root transaction dataset:
Instead of a search constraint, this dataset requires a transaction definition. Its creation requires a Dataset Name, Dataset ID, and at least one Group Dataset .

C. Root child dataset:
This is contradictory terminology. Child datasets are not root datasets by definition; they are created under a parent and inherit its constraints .

D. Root search dataset:
This uses a complete, arbitrary SPL search string as its definition, not a simple constraint .

📚References

Splunk Docs:
"Root event datasets are defined by a constraint: a simple search that filters out events that aren't relevant to the dataset" .

Splunk Docs:
"Root transaction dataset definitions require a Dataset Name and Dataset ID and at least one Group Dataset"

Explanation:

transaction groups events based on common field values, time constraints (e.g., maxspan, maxpause), and start/end conditions (e.g., startswith, endswith). It is ideal for correlating related events across multiple sources or time periods, such as grouping all events from a single user session or a multi-step workflow. The transaction command adds a duration field and can handle complex event grouping logic.

stats groups events by field values and calculates statistical aggregations (e.g., count, sum, avg, min, max) for each group. It is more efficient for summarizing data and does not preserve individual events in the same way transaction does. It is often used for reporting and dashboarding.

❌ Why the other options are incorrect

A. eval, coalesce
– The eval command is used to create or manipulate fields, not to group events. The coalesce function returns the first non-null value from a list of fields; it does not perform grouping. Neither command is used for grouping events.

C. stats, format
– While stats is correct, format is used to format subsearch results into a single string for use in search conditions, not for grouping events.

D. top, rare
– The top and rare commands display the most frequent and least frequent values of a field, respectively. While they provide summaries, they do not group events in the way stats or transaction do.

📚 References

Splunk Documentation – transaction command:
"The transaction command groups related events into a single transaction."

Splunk Documentation – stats command:
"The stats command calculates aggregate statistics over the search results."

Explanaton:

The search sourcetype=cisco_esa | transaction mid, dcid, icid | timechart avg(duration) groups events from the Cisco ESA (Email Security Appliance) logs into transactions based on three fields: mid (message ID), dcid (delivery connection ID), and icid (incoming connection ID). By specifying these fields, Splunk ensures that events from the same email message, delivery connection, and incoming connection are grouped into a single transaction.

When transaction groups events, it automatically adds several fields to the result set, including:

duration – the total time (in seconds) from the first event to the last event in the transaction.
eventcount – the number of events in the transaction.
open_txn – indicates whether the transaction is still open (evicted).

The timechart avg(duration) then takes these duration values, buckets them by time (e.g., per hour or per day), and calculates the average duration of all transactions that completed in each time bucket. This produces a time‑based chart showing the average elapsed time of transactions over time.

❌ Why the other options are incorrect

B. The average time for each event within each transaction
– This is incorrect because duration measures the total span of the transaction, not the average time per event. To get the average time per event, you would need to calculate duration / eventcount, which is not being done here.

C. The average time between each transaction
– This would require measuring the gaps between transactions (e.g., the time from the end of one transaction to the start of the next). The duration field does not measure inter‑transaction intervals; it measures intra‑transaction spans. To calculate time between transactions, you would need additional logic (e.g., streamstats or eventstats), which is not present in this search.

References

Splunk Documentation – transaction command:
"The transaction command adds a duration field that indicates the time span of the transaction."

Splunk Documentation – timechart command:
"The timechart command creates a time series chart with statistical aggregation."

Explanation

During the validation step of the Field Extractor (FX) workflow, you are presented with a preview of the extracted fields and their values for a sample of events. At this stage, you can remove values that are not a match for the field you are defining. This allows you to clean up false positives or incorrect extractions before finalizing the field extraction. For example, if the extractor mistakenly identifies a value that does not belong to the field, you can uncheck or deselect it to exclude it from the extraction.

❌ Why the other options are incorrect

B. You can validate where the data originated from
– The Field Extractor does not include a step to validate the data origin (e.g., source file, host, or index). It only focuses on extracting fields from the events that are already returned in the search results.

C. You cannot modify the field extraction
– This is false. The validation step is specifically designed to allow you to modify the extraction by removing incorrect values, adjusting the delimiter, or refining the regular expression. You are actively encouraged to validate and correct the extraction before saving.

References

Splunk Documentation – Field Extractor:
"In the validation step, you can remove values that are not a match for the field you want to define."

📘 Explanation:

The Splunk Common Information Model (CIM) add‑on provides standardized data models that normalize field names and event structures across diverse technologies. This normalization is critical for apps like Splunk Enterprise Security, which rely on consistent schemas for correlation searches, dashboards, and reporting.

From the given options, the valid CIM data models are Alerts and Email.

B.Alerts → ✅ Included.
The Alerts data model standardizes information about triggered alerts from multiple sources. It includes fields such as alert_type, severity, action, and vendor_product. This allows Splunk to correlate and report on alerts consistently, regardless of whether they originate from firewalls, IDS/IPS, or other monitoring tools.

D.Email → ✅ Included.
The Email data model normalizes logs from email servers and gateways. It covers fields like src_user, recipient, subject, and action. This enables detection of phishing attempts, monitoring of outbound/inbound email traffic, and integration with security dashboards.

❌ Why Other Options Are Incorrect

A. User permissions
→ Not included. CIM does not provide a data model for user permissions or role management. Splunk handles access control through its own role‑based access system, separate from CIM.

C. Databases
→ Not included. While Splunk can ingest database logs via DB Connect, CIM does not ship with a dedicated database data model. Database activity may be mapped into other models (e.g., Authentication or Change), but there is no standalone “Databases” model in CIM.

References

Splunk Docs – Overview of the Splunk Common Information Model
Splunk Docs – CIM Data Models Reference
Splunk Enterprise Security Guide – CIM usage in correlation searches

📝Explanation:

Splunk processes knowledge objects in a defined sequence at search time. The official documentation states that calculated fields are processed after search-time field extraction and field aliasing, but before lookups, event types, and tags [citation:2][citation:5][citation:6].

This sequence determines what a calculated field can reference. Because they are processed so early, they can reference fields that have been extracted from your events, including those from inline extractions (EXTRACT-) or field transforms (REPORT-) [citation:1][citation:2]. For example, a calculated field's eval expression can use a field like Depth or response_time that has already been extracted from the raw data [citation:1][citation:9].

❌ Why the other options are incorrect

A. Tags:
Incorrect. Tags are applied much later in the search-time sequence (after lookups). A calculated field cannot reference a tag because it doesn't exist as a field value at that point in the processing order [citation:5][citation:6][citation:9].

C. Output fields for a lookup:
Incorrect. Lookups are processed after calculated fields. This means that any fields added to your events by a lookup are unavailable when the calculated field's eval expression is evaluated. Referencing them would cause an error [citation:2][citation:5].

D. Fields generated from a search string:
This option is not a standard Splunk concept for this context and is incorrect.

📚 References

Splunk Docs:"Calculated fields can reference all types of field extractions. They can't reference lookups, event types, or tags." [citation:5][citation:6][citation:9]

SPLK-1002 Exam Blueprint: Knowledge Objects → Calculated fields → Source field requirements.

Explanation

This search string is NOT valid because the chart command does not support using multiple fields with the over clause separated by a comma. The over clause accepts only one field (or _time) to define the primary grouping (rows). Using over host, status is invalid syntax and will produce an error.

❌ Why the other options are valid

B. index=web status=50* | chart count over host by status
This is valid. It uses over host (primary grouping) and by status (secondary grouping, columns). This creates a pivot‑table style output with rows for each host and columns for each status value.

C. index=web status=50* | chart count by host, status
This is also valid. The chart command allows listing multiple fields after by, separated by commas. This groups results by the combination of host and status, producing a flat table. It does not use over, so it is a different output format but still valid syntax.

References

Splunk Documentation – chart command:
"The over clause takes a single field. To use multiple fields, use the by clause."

SPLK-1002 Exam Blueprint:
Search Commands → chart → over and by clause syntax.