SPLK-2001 Practice Questions

By default, the Splunk REST API endpoint used to retrieve search results (/services/search/jobs/{searchid}/results) returns all fields that are extracted for each event. This includes the raw event data (raw), default metadata fields (such as sourcetype), and all fields extracted at search time. For the given metrics events, fields like name and instantaneouskbps are extracted from the key-value pairs within the raw data. Therefore, without any specific parameters to limit the field list in the API call, all listed fields will be included in the response for each event.

Not applicable, as all provided options are correct.

1. Splunk Enterprise REST API Reference Manual: In the documentation for the GET services/search/jobs/{searchid}/results endpoint

the description for the query parameter f (also known as fieldlist) explicitly states: "A comma-separated list of fields to return. If you do not specify a list of fields

all fields are returned." This confirms that the default behavior is to return every field associated with the search results. (See Splunk Enterprise 9.1.0 Documentation

Home > REST API Reference Manual > search/jobs/{searchid}/results).

2. Splunk Enterprise Search Manual: The manual describes how Splunk extracts fields at search time. For the internal logs

which often use a key-value pair format

Splunk automatically extracts these pairs as fields. The example event clearly shows fields like group

name

and instantaneouskbps which would be extracted and thus available in the API results. (See Splunk Enterprise 9.1.0 Documentation

Home > Search Manual > Get started with search > Use fields to search).

Report acceleration works by creating a summary of the data generated by a search up to its first transforming command. For this process to be successful, several criteria must be met. The search must contain a transforming command (e.g., stats, chart, timechart) to define the statistical summary that will be accelerated. All commands preceding this transforming command must be streamable, meaning they can operate on events one by one. Non-streaming commands would require the entire dataset, defeating the purpose of the summary. Finally, event sampling is incompatible with report acceleration because sampling uses a subset of data, while acceleration builds a complete summary of all relevant data.

C. Use a standard Splunk visualization.

The type of visualization used to display report results is independent of the backend search acceleration process and does not affect whether a report can be accelerated.

1. Splunk Enterprise Documentation

Knowledge Manager Manual

"Manage report acceleration": This section explicitly lists the requirements for a search to be eligible for report acceleration.

"The search must include a transforming command such as stats

chart

timechart

top

rare

or sistats." (Supports option B)

"The commands in the search string that come before the first transforming command must be streamable." (Supports option D)

"The search cannot use event sampling." (Supports option A)

2. Splunk Enterprise Documentation

Search Manual

"Types of commands": This document defines and distinguishes between streaming and transforming commands

which is foundational to understanding the requirements for report acceleration.

"About transforming commands": Explains that these commands "transform the specified cell values for each event into numerical values that Splunk software can use for statistical purposes." This is the core function that report acceleration leverages.

"Streaming commands": Defines streaming commands as those that "run on each event as it is returned by a search." This is a prerequisite for the pre-transforming part of an accelerated search.

There are three primary reasons why the dashboard might not be visible on the new instance. First, if the dashboard's permissions were set to "Private," it would be saved in the user's specific directory (etc/users//myApp/local), not the app's main directory (etc/apps/myApp/). Consequently, it would not be included when the app is packaged and moved. Second, deleting the myApp/local directory before packaging would discard all UI-driven changes and customizations, including the updated dashboard. Finally, even if the dashboard is moved correctly, the user's role on the new instance might lack the necessary permissions to view objects within myApp, making the dashboard invisible to that user.

D. This path points to the default navigation file for the Search & Reporting app, not a dashboard view within myApp. Changes to a dashboard in myApp would not be saved here.

1. For Answer A: Splunk Enterprise Documentation

Knowledge Manager Manual

"Manage knowledge object permissions". This section explains that private objects are user-and-app-specific and are not available to other users. It also details that these configurations are stored in $SPLUNKHOME/etc/users///local

which is outside the standard app directory ($SPLUNKHOME/etc/apps/) used for packaging.

2. For Answer C: Splunk Enterprise Documentation

Admin Manual

"Configuration file directories". This document outlines the configuration file system

stating that user-level changes made through Splunk Web are saved in local directories. Deleting the local directory within an app effectively reverts it to its default state

removing any customizations.

3. For Answer B: Splunk Enterprise Documentation

Securing Splunk Enterprise

"About users and roles". This manual describes how roles define a user's access to Splunk resources. A user's role must grant read access to an app and its knowledge objects for them to be visible. If the user's role on the new instance is configured differently

access can be denied.

Indexer acknowledgement for the HTTP Event Collector (HEC) is a setting configured on a per-token basis to ensure data durability. It is not enabled by default. It can be enabled through two primary methods:

1. Via the Splunk Web user interface, by selecting the "Enable indexer acknowledgement" checkbox during the creation of a new HEC token.

2. Programmatically via the REST API, by setting the useACK parameter to 1 (or true) in the POST request to the services/data/inputs/http endpoint when creating a new token. This allows for automated and scripted configuration of HEC tokens with guaranteed delivery enabled.

A. Indexer acknowledgement is disabled by default for HEC tokens to optimize for performance over guaranteed delivery. It must be explicitly enabled.

D. Indexer acknowledgement is a per-token setting, not a global one. Global HEC settings manage aspects like the port number and SSL, but not data delivery guarantees for individual tokens.

1. Splunk Enterprise Documentation

Getting Data In Manual

"Use indexer acknowledgment": This document explicitly states

"Indexer acknowledgment is not enabled by default for HEC tokens." It then provides instructions for enabling it via Splunk Web: "On the Select Source page

select the Enable indexer acknowledgment checkbox." (Reference: Splunk Enterprise 9.x Documentation

Getting Data In

Chapter: "Set up and use HTTP Event Collector in Splunk Web"

Section: "Enable indexer acknowledgment for an HEC token").

2. Splunk Enterprise Documentation

REST API Reference Manual

"data/inputs/http/{name}": The documentation for the POST method on the services/data/inputs/http/{name} endpoint lists the available parameters for creating an HEC token. It includes the useACK parameter

described as: "Set to true to enable indexer acknowledgement." The API accepts boolean true/false or integer 1/0 values. (Reference: Splunk Enterprise 9.x Documentation

REST API Reference Manual

Endpoints: data/inputs/http/{name}

Method: POST).

The Splunk KV (Key-Value) Store is a lookup and storage component designed for Splunk applications to manage and maintain stateful information. It excels at handling structured data that requires frequent updates or modifications. Use cases include storing checkpoint data for modular inputs to track their progress (A), managing the state of a workflow like an incident review system (B), and saving application-specific data such as user preferences or session information as they interact with an app (D). These tasks leverage the KV Store's ability to act as a persistent database within the Splunk environment.

C. Splunk has a dedicated and highly optimized feature called "metrics indexes" for ingesting, storing, and analyzing high-volume metrics data. The KV Store is not designed for this purpose.

1. Splunk Enterprise Admin Manual

"About the KV Store": This section explicitly states

"The KV Store lets you store and retrieve data within your Splunk apps

and is a way to manage and maintain stateful information." This supports the general principle behind options A

B

and D.

2. Splunk Enterprise Developing Views and Apps for Splunk Web

"About the KV Store": This document provides specific examples of KV Store use cases

including: "Tracking a workflow

such as an incident-review system" (directly supporting option B) and "Keeping a list of environment information" (analogous to storing application state

supporting option D).

3. Splunk Enterprise Developing Apps for Splunk Cloud Platform and Splunk Enterprise

"Store stateful information in your Splunk app": This guide details that the KV Store is ideal for "Managing a workflow

" "Keeping track of an application's state

" and "Storing user metadata

" which directly validates options B and D. It also covers checkpointing for modular inputs

a key use case for state management (supporting option A).

4. Splunk Enterprise Metrics manual

"Overview of metrics": This document describes the separate subsystem for handling metrics. It states

"Splunk platform metrics data is stored in metrics indexes

which are optimized for the storage and retrieval of metrics data." This confirms that option C is incorrect as it describes the function of metrics indexes

not the KV Store.

The Splunk KV (Key-Value) Store is a lookup feature that stores data as collections of records. Each record within a collection is fundamentally a JSON document. When adding data to a KV Store collection, whether through the REST API or using SPL commands like outputlookup, the data must be structured in JSON format. While source data can originate from formats like CSV, it must first be processed by Splunk's search pipeline into field-value pairs, which are then converted into JSON documents for insertion into the KV Store. The KV Store itself does not natively ingest or parse XML, CSV, or TXT formats.

B, C, D: These options are incorrect because the KV Store does not natively accept XML, CSV, or TXT formats. Data from these sources must be parsed and transformed into a JSON structure before it can be added to a KV Store collection.

1. Splunk Enterprise Admin Manual

"About the KV Store": This document explicitly states the data format. "The KV Store stores data as key-value pairs in a JSON document format. The data is stored in collections

and is searchable as a lookup." (Splunk Documentation

Admin Manual

Version 9.x

Part of "Use lookups"

Section "About the KV Store").

2. Splunk Enterprise REST API User Manual

"storage/collections/data/{collection}": The documentation for the POST method

used to create records in a collection

specifies that the request body must be in JSON format and requires the Content-Type: application/json header. Example requests consistently show a JSON payload. (Splunk Documentation

REST API User Manual

Version 9.x

Endpoints reference

Section "storage/collections/data/{collection}").

3. Splunk Enterprise Developing Views and Apps for Splunk Web

"An overview of the KV Store": This guide reinforces the core architecture. "The KV Store lets you store and retrieve data within your Splunk apps. The KV Store stores data as key-value pairs in collections. Each collection is a set of records

and each record is a JSON document." (Splunk Documentation

Developing Views and Apps for Splunk Web

Version 9.x

Chapter "Store and retrieve data"

Section "An overview of the KV Store").

The Splunk REST API search/jobs endpoint accepts standard Splunk time modifiers for the earliesttime and latesttime arguments.

- latesttime=rt is the correct syntax to initiate a real-time search.

- latesttime=now is a valid keyword representing the current time when the search is executed.

- earliesttime=-5h@h is a valid relative time modifier that specifies a time five hours ago, snapped to the beginning of that hour.

The syntax in option D is invalid.

D. earliesttime=rt10m@m is incorrect because the underscore () is not a valid operator in Splunk's time modifier syntax. The correct format for a relative real-time specifier uses a hyphen (-) or plus (+).

1. Splunk Enterprise REST API Reference Manual

search/jobs endpoint documentation.

Section: POST search/jobs > Arguments

Content: The documentation for the latesttime argument explicitly states

"To run a real-time search that runs indefinitely

specify rt for the latesttime." This validates option A. The documentation for both earliesttime and latesttime specifies they accept a "time string

" which includes keywords like now and relative time modifiers. This validates options B and C.

2. Splunk Enterprise Search Manual

"Specify time ranges in your search".

Section: "Relative time modifiers"

Content: This section details the syntax for relative time

including the use of snap-to-time units (@). It provides examples like -60m@h

which confirms the structure of -5h@h is valid. This validates option C.

3. Splunk Enterprise Search Manual

"Specify time ranges in your search".

Section: "Use the now() keyword"

Content: This section states

"You can use the now() keyword to refer to the current time when the search is run." This validates option B.

4. Splunk Enterprise Search Manual

"About real-time searches and reports".

Section: "Time ranges for real-time searches"

Content: This section explains that to specify a time window for a real-time search

you use a relative time format such as rt-5m. It does not list any syntax using an underscore (rt)

confirming that the format in option D is invalid.

The /services/auth/login endpoint is the designated REST API endpoint for authenticating with a Splunk instance. A client application sends a POST request containing user credentials (username and password) to this endpoint. Upon successful validation, the Splunk server responds with a session key (or token). This session key must then be included in the Authorization header of all subsequent API requests to access protected resources, thereby maintaining an authenticated session. This is the standard and primary method for programmatic login via the REST API.

B. The /services/session endpoint is used to manage properties of an existing session, not to create a new one by logging in.

C. This is a syntactically incorrect and non-existent endpoint path, improperly combining segments from different valid endpoints.

D. The /servicesNS prefix is for accessing resources within a specific namespace (user/app context), and authentication/login is not the correct path for the login function.

1. Splunk Enterprise 9.2.1 REST API Reference Manual:

Reference: Endpoints > auth/login

Details: The documentation explicitly states

"Use this endpoint to log in to Splunk and create a session key." It details the required POST method and parameters (username

password) to authenticate and receive a session key.

2. Splunk Enterprise 9.2.1 REST API User Manual:

Reference: Access the REST API > Authentication and authorization

Details: This section describes the authentication process

stating: "To authenticate with Splunk Enterprise

send a POST request containing your username and password to the /services/auth/login endpoint. Splunk Enterprise responds with a session key if the credentials are valid."

The services/collector path is the base endpoint for the Splunk HTTP Event Collector (HEC) used for data ingestion. The provided data is a structured JSON object, which is specifically handled by the /services/collector/event endpoint. Since /services/collector/event is not an available option, the base path services/collector is the most appropriate choice. This correctly identifies the data collection service, distinguishing it from REST API endpoints used for configuration or endpoints for different data types.

A. data/inputs/http/{name} is a REST API endpoint for configuring a specific HEC token, not for sending event data.

B. services/collector/raw is the HEC endpoint for sending unstructured, raw text data, not structured JSON objects.

D. data/inputs/http is the base REST API endpoint for managing HEC configurations, not for ingesting data.

1. Splunk Enterprise Documentation

Getting Data In Manual

"Set up and use HTTP Event Collector in Splunk Web": This document specifies the different HEC endpoints. It states

"The two types of HEC endpoints are the /services/collector/event endpoint

for JSON-formatted events

and the /services/collector/raw endpoint

for raw text." This confirms that the provided JSON data is intended for an endpoint under the /services/collector path and that the /raw endpoint is incorrect.

2. Splunk Enterprise Documentation

REST API Reference Manual

"data/inputs/http": This reference describes the endpoints for managing HEC tokens. It states

"Use this endpoint to create

view

and edit HTTP Event Collector tokens." This confirms that the data/inputs/http path (options A and D) is for configuration

not data ingestion.

3. Splunk Enterprise Documentation

Getting Data In Manual

"Format events for HTTP Event Collector": This section details the required JSON wrapper for the /event endpoint. It clarifies that structured JSON like the example is the intended format for the event collector

distinguishing it from the /raw endpoint. The base path for this functionality is services/collector.

The provided configuration snippet, access = read : [ ], write : [ admin ] export - system, is used to define permissions and sharing for Splunk knowledge objects. This type of configuration belongs in a metadata file (.meta). For an administrator to apply a persistent, local change to an app's knowledge objects, the configuration should be placed in the local.meta file within that app's metadata directory. This ensures the changes are not overwritten during app upgrades. The path $APPHOME/metadata/local.meta is the standard, correct location for this purpose.

A. $APPHOME/default/app.conf

This file defines the properties of the application itself, such as its version and label, not the permissions of the knowledge objects within it.

B. $APPHOME/local/default.meta

This path is incorrect. Metadata files (.meta) are located in a metadata directory, not directly within the local directory of an app.

D. $SPLUNKHOME/etc/system/local/server.conf

This file is used for system-wide server settings, such as networking and indexing configurations, not for managing app-specific knowledge object permissions.

---

1. Splunk Enterprise Documentation

Admin Manual

"Manage knowledge object permissions": This section explicitly states that permissions are set in .meta files. It provides the correct file path: "Permissions for an object are stored in a file called .meta in the metadata directory for that app. For example

$SPLUNKHOME/etc/apps//metadata/local.meta." This directly supports answer C.

2. Splunk Enterprise Documentation

Admin Manual

"Configuration file precedence": This document explains that administrators should make changes in local directories to override default settings and ensure that changes persist after upgrades. This reinforces the use of local.meta over default.meta for administrative changes.

3. Splunk Enterprise Documentation

Admin Manual

"app.conf": The specification for app.conf confirms its role is to define app properties and UI behavior

with no stanzas for knowledge object access control. This refutes option A.

4. Splunk Enterprise Documentation

Admin Manual

"server.conf": The specification for server.conf details its use for global server settings. It contains no attributes or stanzas related to the access or export settings for knowledge objects. This refutes option D.