Free SPLK-1002 Practice Test Questions 2026

Explanation:

The stats command is used in Splunk to calculate aggregate statistics over a dataset, similar to SQL group-by functions. It relies on internal, dedicated statistical functions to compute values for rows. Why B is Correct

addtotals is an independent command: It is not a function that you can embed inside a stats or chart pipeline clause. Instead, addtotals is a separate, standalone SPL command used to calculate the arithmetic sum of all numeric fields across a row or column after your primary results have already been generated. Writing something like | stats addtotals(price) will cause a search parsing syntax error because the search engine does not recognize it as a valid aggregate function.

Why A, C, and D are Incorrect

A. sum:
This is a fundamental native statistical function used within the stats command (e.g., | stats sum(sales)) to add up all the numerical values found within a specified field across a group of events.

C. count:
This is the most common statistical function. It computes the total number of events or occurrences that match the search criteria. It can be used alone as count or targeted at a specific field value matching like count(eval(status=200)).

D. avg:
This is the native statistical function used to calculate the arithmetic mean (average) of a numerical field's values (e.g., | stats avg(response_time)) across your grouped data logs.

Reference

Splunk Documentation: Search Reference -> Statistical and charting functions.

Core Distinction: Splunk explicitly documents functions like sum, count, and avg under its aggregate function index for transforming commands. Conversely, addtotals maintains its own dedicated entry under Search Reference -> addtotals, classifying it strictly as a command rather than a function.

Explanation

The fillnull command in Splunk is used to replace null (empty or missing) values in specified fields with a value you define. If you do not specify the value argument (e.g., | fillnull), it defaults to replacing null values with 0. This default behavior is explicitly documented and is particularly useful when performing calculations, aggregations, or creating charts where null values would otherwise cause gaps, errors, or misleading results.

❌ Why the other options are incorrect

B. N/A – This is not the default. While you can specify value="N/A" to use this string, it is not the default replacement value. The default is numeric 0, not a text string.

C. NaN – This is not the default. NaN (Not a Number) is a concept used in some programming languages and statistical contexts, but Splunk's fillnull does not use it as a default. The default is 0.

D. NULL – This is not the default. The command is designed to replace null values; it does not leave them as NULL. If you want to keep nulls, you simply do not use fillnull.

References

Splunk Documentation – fillnull command:
"If you do not specify a value, the fillnull command replaces null values with 0."

Explanation:

Field aliases in Splunk are alternate names assigned to a field, and their application is scoped to specific data contexts. According to the official Splunk documentation, a field alias is applied to events belonging to a particular host, source, or sourcetype . For instance, you can alias a field named client_ip to src only for the access_combined sourcetype, while other sourcetypes remain unaffected. The process of field aliasing occurs after field extraction but before lookups in the search-time operation sequence , ensuring that the alias is available for subsequent operations.

❌ Why the other options are incorrect

A. Data found in a lookup table.
This is incorrect. In the search-time sequence, field aliases are processed before lookups . This means any fields added to events by a lookup do not exist yet, so you cannot apply a field alias to them directly. The alias must be defined on the original extracted field, which can then be referenced by the lookup configuration .

B. Either a calculated field or an extracted field.
While you can create aliases for extracted fields (those derived from index-time or search-time extractions) , this is not the whole picture. More importantly, you cannot create an alias for a calculated field. Calculated fields are processed after field aliases in the search-time sequence . Therefore, a calculated field is not available to be aliased when the field aliasing step occurs. This makes the statement inaccurate.

C. Only one single field in a dataset.
While a single alias can only apply to one field , this is a restriction, not the scope of its application. The question asks "to which... can a field alias be applied," which refers to the scope (host, source, sourcetype), not the number of fields it can alias. Additionally, a single field can have multiple aliases .

📚 References

Splunk Documentation: Field aliases are specific to a host, source, or sourcetype and are applied before lookups

Explanation:

Splunk alerts are knowledge objects that monitor your data and trigger actions when certain conditions are met. They are based on searches, and those searches can run in one of two primary modes:

A. in real-time – Real-time alerts run continuously and evaluate events as they are indexed. They can trigger when a single event matches the search criteria or when the number of events over a rolling time window meets a threshold. Real-time alerts are useful for immediate detection of critical events.

B. on a regular schedule
– Scheduled alerts run at defined intervals (e.g., every hour, daily, or using a cron expression). They execute a search over a specific time window and trigger based on the results. Scheduled alerts are ideal for periodic checks, reports, or non‑urgent monitoring.

❌ Why the other option is incorrect

C. and have no matching events
– This is incorrect. Alerts are designed to trigger based on matching events (i.e., results). A search with no matching events is not a valid alert condition. While you can configure an alert to trigger when the count of events is 0 (e.g., "alert when no results"), the alert is still fundamentally based on the search that is expected to return events. The alert does not exist in a vacuum; it requires a search that can produce results, and the "zero results" condition is a specific threshold setting, not a separate alert type.

📚 References

Splunk Documentation – Alerts:
"Alerts are based on searches that run in real-time or on a regular schedule."

Explanation:

Tags are applied to field/value pairs, but they are the last knowledge objects generated in the search-time operation sequence. According to the official Splunk documentation: "Tags come last in the sequence of search-time operations."

This means tags are applied after all other knowledge objects, including extracted fields, field aliases, calculated fields, lookups, and event types .

❌ Why the other options are incorrect

A. Lookups and event types only. – This is incomplete and misleading. While tags can be applied to fields from lookups and event types, this is not a restriction.

B. Extracted fields, field aliases, calculated fields, lookups, and event types. – This is incorrect because tags do not "reference" these objects. Instead, tags are applied to field/value pairs, regardless of how those fields were created.

D. Extracted fields, calculated fields, and field aliases only. – This incorrectly omits lookups and event types, and again misrepresents the relationship.

📚 References

Splunk Docs: "You can apply tags to any field/value pair in an event, whether it is extracted at index time, search time, or added through some other method, such as an event type, lookup, or calculated field."

Search-time operation order: Tags are applied after extracted fields, field aliases, calculated fields, lookups, and event types.

Explanation

The if function in the eval command is a conditional function that evaluates a logical expression and returns one of two values based on whether the condition is true or false. The required syntax follows a standard programming convention:

Boolean expression – The condition to evaluate (e.g., status=200, bytes>1000, like(host, "web%")).
Result if true – The value returned if the condition evaluates to true.
Result if false – The value returned if the condition evaluates to false.

Example:

| eval category = if(bytes > 1000, "Large", "Small") In this example, if bytes is greater than 1000, category is set to "Large"; otherwise, it is set to "Small".

❌ Why the other options are incorrect

B. Result if true, result if false, boolean expression – This reverses the order. The boolean expression must come first; otherwise, Splunk would not know what condition to evaluate.

C. Result if false, result if true, boolean expression – This is incorrect because the boolean expression must come first, and the order of true/false results is swapped. This would produce incorrect values.

D. Boolean expression, result if false, result if true – This places the false result before the true result, which is incorrect. The true result must come before the false result.

📘 Additional exam note
The if function can be nested: if(condition1, value1, if(condition2, value2, value3))
It can also be used with other eval functions like isnull(), isnotnull(), match(), etc.

📚 References

Splunk Documentation – if function:
"The if function takes three arguments: a boolean expression, a value to return if true, and a value to return if false."

Explanation:

Transforming commands in Splunk are those that generate statistical results in a tabular format, often with rows and columns. The commands chart, timechart, stats, and eventstats are all transforming commands that can be used after the transaction command to aggregate or analyze the resulting transaction data. For example, you can group events into transactions using transaction, then use stats to calculate the average duration of transactions, or use timechart to visualize the count of transactions over time.

❌ Why the other options are incorrect

B. chart, timechart, stats, diff – diff is not a transforming command. It is used to compare consecutive events and calculate differences between their field values, and it does not produce the same kind of aggregate tabular output as stats or chart.

C. chart, timechart, datamodel, pivot– datamodel is a command used to search against data models, and pivot is a UI tool, not a command in SPL. Neither is a transforming command that follows transaction.

D. chart, timechart, stats, pivot – pivot is not a command; it is a visual tool used in Splunk Web. Additionally, this option is a near‑duplicate of A but replaces eventstats with pivot, making it incorrect.

References

Splunk Documentation – Transforming Commands:
"Transforming commands include chart, timechart, stats, and eventstats."

Explanation:

This command correctly uses the if function with isnull() to check if the field notNULL is null (or missing). If it is null, the field is assigned the string value "0". If it is not null, the original value of notNULL is preserved. This addresses the scenario where fields contain empty strings or blank values, as Splunk treats empty strings as null for the purposes of the isnull() function.

❌ Why the other options are incorrect

A. | eval notNULL = if(isnull(notNULL), "0" notNULL) – This is invalid syntax because it is missing a comma between "0" and notNULL. The if function requires three arguments separated by commas: condition, true result, false result. Without the comma, Splunk will throw a syntax error.

C. | eval notNULL = "" | nullfill value=0 notNULL – This is incorrect because nullfill is not a valid Splunk command. The correct command for replacing null values is fillnull. Additionally, the eval command does not support fillnull as a subcommand; they are separate commands.

D. | eval notNULL = "" fillnull value=0 notNULL – This is invalid because fillnull is a separate command and cannot be used inside an eval statement. The syntax attempts to chain commands incorrectly, which would result in an error.

References

Splunk Documentation – isnull() function:
"The isnull function returns true if the field is null or missing."

Splunk Documentation – if() function:
"The if function takes three arguments: a boolean expression, a value to return if true, and a value to return if false."

📝 Explanation:

In Splunk, tags are a type of knowledge object and creating them is a permissioned action. The ability to create tags is controlled by a user's role and its assigned capabilities. For example, the power role includes the capability to "tag events," while a user role can create event types but is not explicitly given the same tagging permissions. A user can create a tag directly from the search results by clicking the Actions arrow next to a field-value pair and selecting Edit Actions, but this ability is only available if their role allows it.

❌ Why the other options are incorrect

A. Identify at least one field:value pair → This is a requirement for applying a tag (which field-value pair to associate with the tag), not a permission condition that must be met before the user can create it.

B. Have the Power role at a minimum → Incorrect. While the power role has the capability to create tags, this is not a strict minimum requirement. A custom role can also be created with the necessary capabilities to create tags.

C. Be able to edit the sourcetype the tag applies to → Incorrect. Tags are applied to field-value pairs and are not restricted to a specific sourcetype. They can be applied to any field, including host, source, or IPaddress.

📚 References

Splunk Docs: About tags and aliases

Splunk Docs: About configuring role-based user access

Explanation:

The tostring() function is a valid eval function in Splunk. It is used to convert a numeric value (or a number stored as a string) into a string representation. This is particularly useful when you need to concatenate numbers with text, format output, or use numbers in contexts that require string manipulation.

For example:
| eval message = "The value is " . tostring(value)

❌ Why the other options are incorrect

A. int() – There is no int() function in Splunk's eval. The correct function for converting a value to an integer is tonumber(). For example: | eval int_value = tonumber(string_value).

B. count() – count() is not an eval function. It is an aggregation function used with transforming commands like stats, chart, and timechart. For example: | stats count by host.

C. print() – There is no print() function in Splunk's eval. This is likely a distractor referencing other programming languages (e.g., Python's print). In Splunk, you use eval to assign values to fields, and you view results in the output table.

📚 References

Splunk Documentation – eval functions:
"The tostring function converts a numeric value to a string."

SPLK-1002 Exam Blueprint:
Search Commands → eval → Valid functions.

📘 Explanation:

The Splunk Common Information Model (CIM) add‑on provides a set of pre‑configured data models that normalize field names and event structures across diverse technologies. These data models are 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 model is Authentication.

Authentication → ✅ Included. This data model standardizes logs related to login activity, user authentication attempts, and session creation. It covers fields such as src, user, action, and result. This normalization allows Splunk to correlate authentication events across multiple systems (e.g., Windows, Linux, VPN, Active Directory) and detect suspicious login patterns, brute force attempts, or unauthorized access.

❌ Why Other Options Are Incorrect

A. Access →
❌ Not included. While Splunk CIM has models like Authentication and Change, there is no standalone “Access” data model. Access control is handled through Splunk’s role‑based system, not CIM.

B. Accounting →
❌ Not included. CIM does not provide a financial or accounting data model. Splunk can ingest accounting logs, but they are not standardized under CIM.

C. Authorization →
❌ Not included. CIM does not ship with a dedicated Authorization data model. Authorization events may be partially mapped into Authentication or Change models, but there is no standalone “Authorization” model.

References

Splunk Docs – Overview of the Splunk Common Information Model
Splunk Docs – CIM Data Models Reference
Splunk Enterprise Security Guide – Authentication data model usage

Explanation:

The original eval statement performs two distinct null-handling operations. For field1, it uses isnotnull() to check if the field contains a non-null value; if it does, the original value is retained, but if it is null, the field is assigned the numeric value 0. For field2, it uses isnull() to check for null values; if field2 is null, it assigns the string "NO-VALUE", and otherwise it keeps the existing value. The requirement is therefore to replace nulls in two different fields with two completely different replacement values—one numeric and one textual. The fillnull command in Splunk is designed for this purpose, but it has a critical limitation: each fillnull invocation can accept only one replacement value via the value= argument. If value= is omitted, the command defaults to replacing nulls with 0. Because different fields need different replacements, multiple fillnull commands must be chained together using the pipe character. Option D correctly implements this logic: the first fillnull field1 applies the default 0 to nulls in field1, and the second fillnull value="NO-VALUE" field2 applies the string "NO-VALUE" to nulls in field2. The pipe between them ensures sequential execution, perfectly mirroring the original eval statement.

. Why Other Options Are Incorrect

A. There is no equivalent expression using fillnull – This is incorrect because chaining multiple fillnull commands with different replacement values achieves the exact same result as the original eval statement, so an equivalent expression absolutely exists.

B. ... | fillnull values=(0,"NO-VALUE") fields=(field1,field2) – This option is syntactically invalid. The fillnull command does not support a values= argument that accepts a list, nor does it accept a fields= argument with parentheses. The correct syntax is fillnull value= without any equals sign before the field list. Additionally, even if the syntax were corrected, a single fillnull cannot assign different replacement values to different fields, so both fields would incorrectly receive the same value.

C. ... | fillnull field1 | fillnull value="NO-VALUE" field2 – This option is conceptually identical to Option D and would be correct if it contained the proper pipe character. However, as written, it is missing the pipe between the two fillnull commands. In Splunk, search commands must be separated by pipes; without the pipe, the second fillnull is treated as an invalid argument to the first, causing a syntax error and search failure. This makes Option C incorrect despite its conceptual similarity to the right answer.

References

Splunk Documentation: "If you do not specify a value, fillnull replaces null values with 0" –