SPLK-2002 Practice Test 11 — 15 Questions

Question 1

How can you verify the current health and performance of your indexers using the Monitoring Console?

Accepted Answer

Indexer: Instance dashboard. The Indexer: Instance dashboard in the Monitoring Console provides detailed health and performance metrics for individual indexers, including CPU, memory, disk usage, and search performance. This dashboard is specifically designed to verify the health and performance of indexers, making B the correct choice.

Answer

License usage dashboard

Answer

Deployment Health dashboard

Answer

Search Performance dashboard

Question 2

Which command helps you understand if your search is retrieving too much data from the disk by analyzing the 'index_time' and 'search_time'?

Accepted Answer

Search Inspector. The Search Inspector in Splunk is a built-in tool that provides detailed performance metrics for a specific search job, including the time spent on index_time (disk I/O) and search_time (processing). By examining these timings, you can determine if the search is reading excessive data from disk, which often indicates inefficiencies like lack of filtering or improper use of indexes. It is specifically designed for this diagnostic purpose, making it the correct choice.

Answer

Monitoring Console Search Activity Dashboard

Answer

btool

Answer

splunkd log analysis

Question 3

An Indexer Cluster is experiencing 'Search Factor' violations. Which component is responsible for orchestrating the fix-up process to restore the search factor?

Accepted Answer

The Cluster Master. In an Indexer Cluster, the Cluster Master (now called Cluster Manager in newer versions) is the component responsible for orchestrating fix-up. When a Search Factor violation occurs (fewer searchable copies than the configured search factor), the Cluster Master identifies which buckets need additional searchable copies and directs peers to replicate them, restoring the search factor.

Answer

The Indexer Peer containing the missing copies

Answer

The Search Head

Answer

The Deployment Server

Question 4

A user complains that a search is slow despite having a small time range. The Search Inspector reveals 'event_count' is high, but 'scanned_count' is also high. What is the likely cause?

Accepted Answer

The search is not using an indexed field to filter data. A high 'scanned_count' alongside a high 'event_count' means Splunk is reading many events from disk even though the time range is small — the search is not narrowing the dataset with an indexed field (like index, sourcetype, host, or source) before the base search runs. Without an indexed filter, Splunk must scan raw buckets and apply filtering at search time, which is far slower. Adding an indexed field to the base search dramatically reduces scanned_count.

Answer

The indexer has too much memory

Answer

Data model acceleration is failing

Answer

The search head is underpowered

Question 5

A Search Head Cluster is experiencing frequent 'Search Head Captain Election' messages in the logs. What is the most likely cause?

Accepted Answer

Network latency or instability between SHC members. Frequent Search Head Captain Election messages indicate that the captain is changing often, which is typically caused by network latency or instability between SHC members. The captain election process relies on consensus and heartbeats; if members cannot communicate reliably, elections are triggered. The other options would cause different symptoms, such as search failures or licensing warnings, but not frequent elections.

Answer

The indexer cluster is offline

Answer

The KV store is running

Answer

The license is expired

Question 6

Which TWO factors must be considered when balancing resource allocation between search and indexing?

Accepted Answer

Disk I/O contention. Disk I/O contention (D) is a correct factor because search queries read index buckets from disk while indexing writes and merges bucket data, so both workloads compete for the same storage throughput and IOPS, directly affecting performance balance. Search and indexing CPU competition (E) is also correct because search processes (such as search heads running the search pipeline) and indexing processes (such as indexers parsing, merging, and writing events) both consume CPU cycles, so allocating CPU between them determines how quickly searches return versus how fast data is indexed. The other options do not belong: the number of forwarders (A) affects ingest volume and licensing but is not itself a resource-balancing factor between search and indexing, web UI accessibility (B) is a client access concern unrelated to resource contention, and app installation count (C) is a configuration/management metric that does not directly govern the search-versus-indexing resource tradeoff.

Answer

Number of forwarders

Answer

Web UI accessibility

Answer

App installation count

Question 7

Which THREE of the following are key components of a disaster recovery plan for Splunk?

Accepted Answer

Off-site storage of frozen buckets.. Option A is correct because frozen buckets are the archived, long-term data that must be preserved off-site so that after a disaster the indexed data can be restored and re-thawed or searched via a separate archive indexer. Option B is correct because the etc/ directory holds all critical Splunk configuration — indexes.conf, props.conf, transforms.conf, server.conf, authentication, and apps — and a regular backup of it is essential to rebuild the deployment. Option D is correct because a DR plan is only effective if it includes documented, tested restoration procedures that specify the order of recovery (license master, indexers, search heads) and the exact steps to restore buckets and configurations. Option C is not a DR component; replication factor is a data-availability setting within a cluster and does not by itself constitute a disaster recovery plan. Option E is not a DR component either; continuously indexing all data is a normal ingestion practice, not a recovery mechanism, and it does not address restoring service after a disaster.

Answer

Increasing the replication factor.

Answer

Continuous indexing of all data.

Question 8

Which metric is the best predictor of the storage needed for an indexer in a cluster?

Accepted Answer

Daily ingestion volume. Daily ingestion volume is the primary driver of indexer storage requirements because Splunk's storage footprint is a function of how much data is ingested per day multiplied by retention period and replication/search factor. Other metrics like forwarder count or user count do not directly determine bytes stored.

Answer

Number of forwarders

Answer

Search concurrency

Answer

Number of users

Question 9

What is the effect of using the 'tstats' command in a search?

Accepted Answer

It queries the TSIDX files directly, improving speed. The tstats command queries the TSIDX (time-series index) files directly, which store indexed field-value pairs and metadata. By bypassing the raw event data and using the TSIDX, tstats can return results much faster than regular search commands, especially for statistical queries on indexed fields. This makes it ideal for large-scale data analysis where speed is critical.

Answer

It increases the number of concurrent searches allowed

Answer

It bypasses the parsing queue

Answer

It forces the use of more CPU cores

Question 10

Which TWO actions can improve the performance of a Splunk search head?

Accepted Answer

Adding more nodes to a search head cluster. Option A is correct because adding more nodes to a search head cluster distributes the search workload across multiple search heads, allowing concurrent searches to be parallelized and reducing the load on any single node, which directly improves search performance and scalability. Option E is correct because increasing system memory on the search head allows more search artifacts, result sets, and in-memory operations (such as those used by the search scheduler and knowledge objects) to be cached, reducing disk I/O and speeding up search execution. Option B is not correct because reducing the number of forwarders decreases data ingestion, not search performance, and may actually reduce the data available for searches. Option C is not correct because increasing license volume only allows more data to be indexed per day; it does not improve search speed or search head performance. Option D is not correct because disabling the indexer cluster would remove data replication and distributed search capabilities, harming availability and performance rather than improving it.

Answer

Reducing the number of forwarders

Answer

Increasing the license volume

Answer

Disabling the indexer cluster

Question 11

Which TWO areas should be checked when troubleshooting slow data ingestion?

Accepted Answer

Parsing queue fill percentage. When troubleshooting slow data ingestion, the parsing queue fill percentage (B) must be checked because the parsing queue sits between the indexer's input pipeline and the aggregation stage; if it fills up, events back up and ingestion throughput drops, indicating parsing or indexer processing is the bottleneck. The output queue fill percentage (E) should also be checked because the output queue feeds events from the parsing/aggregation stage to the indexing pipeline; a high fill percentage signals that indexing (disk I/O, bucket creation) cannot keep up, throttling ingestion. License master usage (A) is not a per-ingestion performance metric — license violations block or warn on ingestion volume but do not directly explain slow throughput. User authentication speed (C) affects search/login latency, not the data ingestion pipeline. Search head memory usage (D) is relevant to search performance and knowledge object execution, not to indexer-side ingestion speed.

Answer

License master usage

Answer

User authentication speed

Answer

Search head memory usage

Question 12

You notice that your indexer cluster has 'Streaming' buckets that are not yet searchable. What is the most likely cause?

Accepted Answer

The search factor is not met for these buckets.. In an indexer cluster, a bucket transitions from 'streaming' to 'searchable' only after the search factor (SF) is satisfied — meaning the required number of searchable copies exist across peers. If SF is not met (e.g., a peer holding a searchable copy is down), the bucket remains in the streaming state and cannot be searched. This is the canonical cause of 'streaming buckets not yet searchable' in Splunk clustering.

Answer

The indexer is in maintenance mode.

Answer

The indexer disk is full.

Answer

The license is expired.

Answer

The Cluster Master is down.

Question 13

Which configuration file and stanza are used to define the bucket lifecycle policy for a custom index named 'customer_data'?

Accepted Answer

indexes.conf [customer_data]. The bucket lifecycle policy for an index is defined in indexes.conf within the stanza for that index. The stanza name is the index name, so for 'customer_data', it's [customer_data]. This file contains settings like homePath, coldPath, frozenTimePeriodInSecs, and other retention-related parameters.

Answer

datamodels.conf [customer_data]

Answer

server.conf [customer_data]

Answer

inputs.conf [customer_data]

Question 14

A Splunk indexer cluster is configured with a replication factor of 3 and a search factor of 2. The cluster has five peer nodes. A bucket is currently searchable on two peers. The cluster master detects that one of those peers has failed. What immediate action does the cluster master take to maintain the search factor?

Accepted Answer

It promotes a non-searchable copy on another peer to searchable status.. The search factor defines the number of searchable copies required. When a peer hosting a searchable copy fails, the cluster master acts to restore the search factor. Its first choice is to promote an existing non-searchable copy on another peer to searchable status, which is faster than replicating a new copy. This immediate promotion ensures that searches can still access the required number of searchable copies. Only if no non-searchable copies are available will the master replicate a new copy.

Answer

It marks the bucket as searchable on the failed peer until the peer is restored.

Answer

It waits for the failed peer to come back online before taking any action.

Answer

It initiates replication of a new bucket copy from a searchable peer to a peer without a copy.

Question 15

A Splunk search head cluster has five members. The captain is responsible for coordinating configuration replication and search artifacts. The administrator notices that the captain has not been elected for over an hour, and the cluster is unable to replicate configurations. Which condition is the most likely cause?

Accepted Answer

Fewer than three search head members are reachable, preventing a quorum for captain election.. In a search head cluster, captain election requires a quorum, which is a majority of the configured members. For a five-member cluster, at least three members must be reachable and able to communicate. If fewer than three are available, no captain can be elected, and configuration replication halts. This is a common failure mode when multiple search heads are down or network-partitioned. The cluster master and deployer are not involved in this election process.

Answer

The search head cluster deployer has not pushed a new configuration bundle, so the captain cannot be elected.

Answer

The cluster master is down, and without it, the search head cluster cannot elect a captain.

Answer

The search head cluster is configured with a replication_factor of 3, which is insufficient for captain election.