Practice Free SPLK-2002 Exam Online Questions
Question #11
(A high-volume source and a low-volume source feed into the same index.
Which of the following items best describe the impact of this design choice?)
- A . Low volume data will improve the compression factor of the high volume data.
- B . Search speed on low volume data will be slower than necessary.
- C . Low volume data may move out of the index based on volume rather than age.
- D . High volume data is optimized by the presence of low volume data.
Correct Answer: B,C
B,C
Explanation:
The Splunk Managing Indexes and Storage Documentation explains that when multiple data sources
with significantly different ingestion rates share a single index, index bucket management is governed by volume-based rotation, not by source or time. This means that high-volume data causes buckets to fill and roll more quickly, which in turn causes low-volume data to age out prematurely, even if it is relatively recent ― hence Option C is correct.
Additionally, because Splunk organizes data within index buckets based on event time and storage characteristics, low-volume data mixed with high-volume data results in inefficient searches for smaller datasets. Queries that target the low-volume source will have to scan through the same large number of buckets containing the high-volume data, leading to slower-than-necessary search performance ― Option B.
Compression efficiency (Option A) and performance optimization through data mixing (Option D) are not influenced by mixing volume patterns; these are determined by the event structure and compression algorithm, not source diversity. Splunk best practices recommend separating data sources into different indexes based on usage, volume, and retention requirements to optimize both performance and lifecycle management.
Reference (Splunk Enterprise Documentation):
• Managing Indexes and Storage C How Splunk Manages Buckets and Data Aging
• Splunk Indexing Performance and Data Organization Best Practices
• Splunk Enterprise Architecture and Data Lifecycle Management
• Best Practices for Data Volume Segregation and Retention Policies
B,C
Explanation:
The Splunk Managing Indexes and Storage Documentation explains that when multiple data sources
with significantly different ingestion rates share a single index, index bucket management is governed by volume-based rotation, not by source or time. This means that high-volume data causes buckets to fill and roll more quickly, which in turn causes low-volume data to age out prematurely, even if it is relatively recent ― hence Option C is correct.
Additionally, because Splunk organizes data within index buckets based on event time and storage characteristics, low-volume data mixed with high-volume data results in inefficient searches for smaller datasets. Queries that target the low-volume source will have to scan through the same large number of buckets containing the high-volume data, leading to slower-than-necessary search performance ― Option B.
Compression efficiency (Option A) and performance optimization through data mixing (Option D) are not influenced by mixing volume patterns; these are determined by the event structure and compression algorithm, not source diversity. Splunk best practices recommend separating data sources into different indexes based on usage, volume, and retention requirements to optimize both performance and lifecycle management.
Reference (Splunk Enterprise Documentation):
• Managing Indexes and Storage C How Splunk Manages Buckets and Data Aging
• Splunk Indexing Performance and Data Organization Best Practices
• Splunk Enterprise Architecture and Data Lifecycle Management
• Best Practices for Data Volume Segregation and Retention Policies
Question #12
(A customer creates a saved search that runs on a specific interval.
Which internal Splunk log should be viewed to determine if the search ran recently?)
- A . metrics.log
- B . kvstore.log
- C . scheduler.log
- D . btool.log
Correct Answer: C
C
Explanation:
According to Splunk’s Search Scheduler and Job Management documentation, the scheduler.log file, located within the _internal index, records the execution of scheduled and saved searches. This log provides a detailed record of when each search is triggered, how long it runs, and its success or failure status.
Each time a scheduled search runs (for example, alerts, reports, or summary index searches), an entry is written to scheduler.log with fields such as:
sid (search job ID)
app (application context)
savedsearch_name (name of the saved search)
user (owner)
status (success, skipped, or failed)
run_time and result_count
By searching the _internal index for sourcetype=scheduler (or directly viewing scheduler.log), administrators can confirm whether a specific saved search executed as expected and diagnose skipped or delayed runs due to resource contention or concurrency limits.
Other internal logs serve different purposes:
metrics.log records performance metrics.
kvstore.log tracks KV Store operations.
btool.log does not exist ― btool outputs configuration data to the console, not a log file.
Hence, scheduler.log is the definitive and Splunk-documented source for validating scheduled search activity.
Reference (Splunk Enterprise Documentation):
• Saved Searches and Alerts C Scheduler Operation Details
• scheduler.log Reference C Monitoring Scheduled Search Execution
• Monitoring Console: Search Scheduler Health Dashboard
• Troubleshooting Skipped or Delayed Scheduled Searches
C
Explanation:
According to Splunk’s Search Scheduler and Job Management documentation, the scheduler.log file, located within the _internal index, records the execution of scheduled and saved searches. This log provides a detailed record of when each search is triggered, how long it runs, and its success or failure status.
Each time a scheduled search runs (for example, alerts, reports, or summary index searches), an entry is written to scheduler.log with fields such as:
sid (search job ID)
app (application context)
savedsearch_name (name of the saved search)
user (owner)
status (success, skipped, or failed)
run_time and result_count
By searching the _internal index for sourcetype=scheduler (or directly viewing scheduler.log), administrators can confirm whether a specific saved search executed as expected and diagnose skipped or delayed runs due to resource contention or concurrency limits.
Other internal logs serve different purposes:
metrics.log records performance metrics.
kvstore.log tracks KV Store operations.
btool.log does not exist ― btool outputs configuration data to the console, not a log file.
Hence, scheduler.log is the definitive and Splunk-documented source for validating scheduled search activity.
Reference (Splunk Enterprise Documentation):
• Saved Searches and Alerts C Scheduler Operation Details
• scheduler.log Reference C Monitoring Scheduled Search Execution
• Monitoring Console: Search Scheduler Health Dashboard
• Troubleshooting Skipped or Delayed Scheduled Searches
Question #13
(Which of the following must be included in a deployment plan?)
- A . Future topology diagrams of the IT environment.
- B . A comprehensive list of stakeholders, either direct or indirect.
- C . Current logging details and data source inventory.
- D . Business continuity and disaster recovery plans.
Correct Answer: C
C
Explanation:
According to Splunk’s Deployment Planning and Implementation Guidelines, one of the most critical elements of a Splunk deployment plan is a comprehensive data source inventory and current logging details. This information defines the scope of data ingestion and directly influences sizing, architecture design, and licensing.
A proper deployment plan should identify:
All data sources (such as syslogs, application logs, network devices, OS logs, databases, etc.)
Expected daily ingest volume per source
Log formats and sourcetypes
Retention requirements and compliance constraints
This data forms the foundation for index sizing, forwarder configuration, and storage planning. Without a well-defined data inventory, Splunk architects cannot accurately determine hardware capacity, indexing load, or network throughput requirements.
While stakeholder mapping, topology diagrams, and continuity plans (Options A, B, D) are valuable in a broader IT project, Splunk’s official guidance emphasizes logging details and source inventory as mandatory for a deployment plan. It ensures that the Splunk environment is properly sized, licensed, and aligned with business data visibility goals.
Reference (Splunk Enterprise Documentation):
• Splunk Enterprise Deployment Planning Manual C Data Source Inventory Requirements
• Capacity Planning for Indexer and Search Head Sizing
• Planning Data Onboarding and Ingestion Strategies
• Splunk Architecture and Implementation Best Practices
C
Explanation:
According to Splunk’s Deployment Planning and Implementation Guidelines, one of the most critical elements of a Splunk deployment plan is a comprehensive data source inventory and current logging details. This information defines the scope of data ingestion and directly influences sizing, architecture design, and licensing.
A proper deployment plan should identify:
All data sources (such as syslogs, application logs, network devices, OS logs, databases, etc.)
Expected daily ingest volume per source
Log formats and sourcetypes
Retention requirements and compliance constraints
This data forms the foundation for index sizing, forwarder configuration, and storage planning. Without a well-defined data inventory, Splunk architects cannot accurately determine hardware capacity, indexing load, or network throughput requirements.
While stakeholder mapping, topology diagrams, and continuity plans (Options A, B, D) are valuable in a broader IT project, Splunk’s official guidance emphasizes logging details and source inventory as mandatory for a deployment plan. It ensures that the Splunk environment is properly sized, licensed, and aligned with business data visibility goals.
Reference (Splunk Enterprise Documentation):
• Splunk Enterprise Deployment Planning Manual C Data Source Inventory Requirements
• Capacity Planning for Indexer and Search Head Sizing
• Planning Data Onboarding and Ingestion Strategies
• Splunk Architecture and Implementation Best Practices
Question #14
Splunk Enterprise performs a cyclic redundancy check (CRC) against the first and last bytes to prevent the same file from being re-indexed if it is rotated or renamed.
What is the number of bytes sampled by default?
- A . 128
- B . 512
- C . 256
- D . 64
Correct Answer: C
C
Explanation:
Splunk Enterprise performs a CRC check against the first and last 256 bytes of a file by default, as stated in the inputs.conf specification. This is controlled by the initCrcLength parameter, which can be changed if needed. The CRC check helps Splunk Enterprise to avoid re-indexing the same file twice, even if it is renamed or rotated, as long as the content does not change. However, this also means that Splunk Enterprise might miss some files that have the same CRC but different content, especially if they have identical headers. To avoid this, the crcSalt parameter can be used to add some extra information to the CRC calculation, such as the full file path or a custom string. This ensures that each file has a unique CRC and is indexed by Splunk Enterprise. You can read more about crcSalt and initCrcLength in the How log file rotation is handled documentation.
C
Explanation:
Splunk Enterprise performs a CRC check against the first and last 256 bytes of a file by default, as stated in the inputs.conf specification. This is controlled by the initCrcLength parameter, which can be changed if needed. The CRC check helps Splunk Enterprise to avoid re-indexing the same file twice, even if it is renamed or rotated, as long as the content does not change. However, this also means that Splunk Enterprise might miss some files that have the same CRC but different content, especially if they have identical headers. To avoid this, the crcSalt parameter can be used to add some extra information to the CRC calculation, such as the full file path or a custom string. This ensures that each file has a unique CRC and is indexed by Splunk Enterprise. You can read more about crcSalt and initCrcLength in the How log file rotation is handled documentation.
Question #15
Which of the following statements describe a Search Head Cluster (SHC) captain? (Select all that apply.)
- A . Is the job scheduler for the entire SHC.
- B . Manages alert action suppressions (throttling).
- C . Synchronizes the member list with the KV store primary.
- D . Replicates the SHC’s knowledge bundle to the search peers.
Correct Answer: A,D
A,D
Explanation:
The following statements describe a search head cluster captain:
Is the job scheduler for the entire search head cluster. The captain is responsible for scheduling and dispatching the searches that run on the search head cluster, as well as coordinating the search results from the search peers. The captain also ensures that the scheduled searches are balanced across the search head cluster members and that the search concurrency limits are enforced.
Replicates the search head cluster’s knowledge bundle to the search peers. The captain is responsible for creating and distributing the knowledge bundle to the search peers, which contains the knowledge objects that are required for the searches. The captain also ensures that the knowledge bundle is consistent and up-to-date across the search head cluster and the search peers. The following statements do not describe a search head cluster captain:
Manages alert action suppressions (throttling). Alert action suppressions are the settings that prevent an alert from triggering too frequently or too many times. These settings are managed by the search head that runs the alert, not by the captain. The captain does not have any special role in managing alert action suppressions.
Synchronizes the member list with the KV store primary. The member list is the list of search head cluster members that are active and available. The KV store primary is the search head cluster member that is responsible for replicating the KV store data to the other members. These roles are not related to the captain, and the captain does not synchronize them. The member list and the KV store primary are determined by the RAFT consensus algorithm, which is independent of the captain election. For more information, see [About the captain and the captain election] and [About KV store and search head clusters] in the Splunk documentation.
A,D
Explanation:
The following statements describe a search head cluster captain:
Is the job scheduler for the entire search head cluster. The captain is responsible for scheduling and dispatching the searches that run on the search head cluster, as well as coordinating the search results from the search peers. The captain also ensures that the scheduled searches are balanced across the search head cluster members and that the search concurrency limits are enforced.
Replicates the search head cluster’s knowledge bundle to the search peers. The captain is responsible for creating and distributing the knowledge bundle to the search peers, which contains the knowledge objects that are required for the searches. The captain also ensures that the knowledge bundle is consistent and up-to-date across the search head cluster and the search peers. The following statements do not describe a search head cluster captain:
Manages alert action suppressions (throttling). Alert action suppressions are the settings that prevent an alert from triggering too frequently or too many times. These settings are managed by the search head that runs the alert, not by the captain. The captain does not have any special role in managing alert action suppressions.
Synchronizes the member list with the KV store primary. The member list is the list of search head cluster members that are active and available. The KV store primary is the search head cluster member that is responsible for replicating the KV store data to the other members. These roles are not related to the captain, and the captain does not synchronize them. The member list and the KV store primary are determined by the RAFT consensus algorithm, which is independent of the captain election. For more information, see [About the captain and the captain election] and [About KV store and search head clusters] in the Splunk documentation.
Question #16
In an indexer cluster, what tasks does the cluster manager perform? (select all that apply)
- A . Generates and maintains the list of primary searchable buckets.
- B . If Indexer Discovery is enabled, provides the list of available peer nodes to forwarders.
- C . Ensures all peer nodes are always using the same version of Splunk.
- D . Distributes app bundles to peer nodes.
Correct Answer: A,B,D
A,B,D
Explanation:
The correct tasks that the cluster manager performs in an indexer cluster are
A,B,D
Explanation:
The correct tasks that the cluster manager performs in an indexer cluster are
Question #17
A new Splunk customer is using syslog to collect data from their network devices on port 514.
What is the best practice for ingesting this data into Splunk?
- A . Configure syslog to send the data to multiple Splunk indexers.
- B . Use a Splunk indexer to collect a network input on port 514 directly.
- C . Use a Splunk forwarder to collect the input on port 514 and forward the data.
- D . Configure syslog to write logs and use a Splunk forwarder to collect the logs.
Correct Answer: D
D
Explanation:
The best practice for ingesting syslog data from network devices on port 514 into Splunk is to configure syslog to write logs and use a Splunk forwarder to collect the logs. This practice will ensure that the data is reliably collected and forwarded to Splunk, without losing any data or overloading the Splunk indexer. Configuring syslog to send the data to multiple Splunk indexers will not guarantee data reliability, as syslog is a UDP protocol that does not provide acknowledgment or delivery confirmation. Using a Splunk indexer to collect a network input on port 514 directly will not provide data reliability or load balancing, as the indexer may not be able to handle the incoming data volume or distribute it to other indexers. Using a Splunk forwarder to collect the input on port 514 and forward the data will not provide data reliability, as the forwarder may not be able to receive the data from syslog or buffer it in case of network issues. For more information, see [Get data from TCP and UDP ports] and [Best practices for syslog data] in the Splunk documentation.
D
Explanation:
The best practice for ingesting syslog data from network devices on port 514 into Splunk is to configure syslog to write logs and use a Splunk forwarder to collect the logs. This practice will ensure that the data is reliably collected and forwarded to Splunk, without losing any data or overloading the Splunk indexer. Configuring syslog to send the data to multiple Splunk indexers will not guarantee data reliability, as syslog is a UDP protocol that does not provide acknowledgment or delivery confirmation. Using a Splunk indexer to collect a network input on port 514 directly will not provide data reliability or load balancing, as the indexer may not be able to handle the incoming data volume or distribute it to other indexers. Using a Splunk forwarder to collect the input on port 514 and forward the data will not provide data reliability, as the forwarder may not be able to receive the data from syslog or buffer it in case of network issues. For more information, see [Get data from TCP and UDP ports] and [Best practices for syslog data] in the Splunk documentation.
Question #18
If .delta replication fails during knowledge bundle replication, what is the fall-back method for Splunk?
- A . .Restart splunkd.
- B . .delta replication.
- C . .bundle replication.
- D . Restart mongod.
Correct Answer: C
C
Explanation:
This is the fall-back method for Splunk if .delta replication fails during knowledge bundle replication. Knowledge bundle replication is the process of distributing the knowledge objects, such as lookups, macros, and field extractions, from the search head cluster to the indexer cluster1. Splunk uses two methods of knowledge bundle replication: .delta replication and .bundle replication1. .Delta replication is the default and preferred method, as it only replicates the changes or updates to the knowledge objects, which reduces the network traffic and disk space usage1. However, if .delta replication fails for some reason, such as corrupted files or network errors, Splunk automatically switches to .bundle replication, which replicates the entire knowledge bundle, regardless of the changes or updates1. This ensures that the knowledge objects are always synchronized between the search head cluster and the indexer cluster, but it also consumes more network bandwidth and disk space1. The other options are not valid fall-back methods for Splunk.
Option A, restarting splunkd, is not a method of knowledge bundle replication, but a way to restart the Splunk daemon on a node2. This may or may not fix the .delta replication failure, but it does not guarantee the synchronization of the knowledge objects.
Option B, .delta replication, is not a fall-back method, but the primary method of knowledge bundle replication, which is assumed to have failed in the question1.
Option D, restarting mongod, is not a method of knowledge bundle replication, but a way to restart the MongoDB daemon on a node3. This is not related to the knowledge bundle replication, but to the KV store replication, which is a different process3. Therefore, option C is the correct answer, and options A, B, and D are incorrect.
1: How knowledge bundle replication works
2: Start and stop Splunk Enterprise
3: Restart the KV store
C
Explanation:
This is the fall-back method for Splunk if .delta replication fails during knowledge bundle replication. Knowledge bundle replication is the process of distributing the knowledge objects, such as lookups, macros, and field extractions, from the search head cluster to the indexer cluster1. Splunk uses two methods of knowledge bundle replication: .delta replication and .bundle replication1. .Delta replication is the default and preferred method, as it only replicates the changes or updates to the knowledge objects, which reduces the network traffic and disk space usage1. However, if .delta replication fails for some reason, such as corrupted files or network errors, Splunk automatically switches to .bundle replication, which replicates the entire knowledge bundle, regardless of the changes or updates1. This ensures that the knowledge objects are always synchronized between the search head cluster and the indexer cluster, but it also consumes more network bandwidth and disk space1. The other options are not valid fall-back methods for Splunk.
Option A, restarting splunkd, is not a method of knowledge bundle replication, but a way to restart the Splunk daemon on a node2. This may or may not fix the .delta replication failure, but it does not guarantee the synchronization of the knowledge objects.
Option B, .delta replication, is not a fall-back method, but the primary method of knowledge bundle replication, which is assumed to have failed in the question1.
Option D, restarting mongod, is not a method of knowledge bundle replication, but a way to restart the MongoDB daemon on a node3. This is not related to the knowledge bundle replication, but to the KV store replication, which is a different process3. Therefore, option C is the correct answer, and options A, B, and D are incorrect.
1: How knowledge bundle replication works
2: Start and stop Splunk Enterprise
3: Restart the KV store
Question #19
At which default interval does metrics.log generate a periodic report regarding license utilization?
- A . 10 seconds
- B . 30 seconds
- C . 60 seconds
- D . 300 seconds
Correct Answer: C
C
Explanation:
The default interval at which metrics.log generates a periodic report regarding license utilization is 60 seconds. This report contains information about the license usage and quota for each Splunk instance, as well as the license pool and stack. The report is generated every 60 seconds by default, but this interval can be changed by modifying the license_usage stanza in the metrics.conf file. The other intervals (10 seconds, 30 seconds, and 300 seconds) are not the default values, but they can be set by the administrator if needed. For more information, see About metrics.log and Configure metrics.log in the Splunk documentation.
C
Explanation:
The default interval at which metrics.log generates a periodic report regarding license utilization is 60 seconds. This report contains information about the license usage and quota for each Splunk instance, as well as the license pool and stack. The report is generated every 60 seconds by default, but this interval can be changed by modifying the license_usage stanza in the metrics.conf file. The other intervals (10 seconds, 30 seconds, and 300 seconds) are not the default values, but they can be set by the administrator if needed. For more information, see About metrics.log and Configure metrics.log in the Splunk documentation.
Question #20
Which tool(s) can be leveraged to diagnose connection problems between an indexer and forwarder? (Select all that apply.)
- A . telnet
- B . tcpdump
- C . splunk btool
- D . splunk btprobe
Correct Answer: A,B
A,B
Explanation:
The telnet and tcpdump tools can be leveraged to diagnose connection problems between an indexer and forwarder. The telnet tool can be used to test the connectivity and port availability between the indexer and forwarder. The tcpdump tool can be used to capture and analyze the network traffic between the indexer and forwarder. The splunk btool command can be used to check the configuration files of the indexer and forwarder, but it cannot diagnose the connection problems. The splunk btprobe command does not exist, and it is not a valid tool.
A,B
Explanation:
The telnet and tcpdump tools can be leveraged to diagnose connection problems between an indexer and forwarder. The telnet tool can be used to test the connectivity and port availability between the indexer and forwarder. The tcpdump tool can be used to capture and analyze the network traffic between the indexer and forwarder. The splunk btool command can be used to check the configuration files of the indexer and forwarder, but it cannot diagnose the connection problems. The splunk btprobe command does not exist, and it is not a valid tool.