SPLK-2002 Practice Test 9 — 10 Questions

Question 1

You are troubleshooting slow search performance across the indexer cluster. Which THREE of the following could be potential causes?

Accepted Answer

The indexers have high CPU usage. Option A is correct because high CPU usage on the indexers directly degrades search performance, as indexers must parse, search, and return results from buckets, and CPU saturation slows query processing and result aggregation. Option C is correct because when search concurrency limits are reached on the search head, additional searches are queued or throttled, which manifests as slow search performance for users. Option D is correct because bucket re-balancing in an indexer cluster involves copying and moving buckets between peers, consuming disk I/O, network bandwidth, and CPU, which competes with search workloads and slows them down. Option B is not correct because the KV store on the search head supports features like saved searches, lookups, and knowledge objects, but disabling it does not directly cause slow search performance across the indexer cluster. Option E is not correct because approaching the daily license limit triggers license violations and search warnings or blocking, but it is not a direct cause of slow search performance.

Answer

The KV store on the search head is disabled

Answer

The Splunk license is close to the daily limit

Question 2

Which TWO types of storage can be used for indexer data?

Accepted Answer

Object storage (SmartStore). Option D (Object storage (SmartStore)) is correct because Splunk indexers can store bucket data remotely in object storage such as S3, Azure Blob, or GCS via SmartStore, keeping only cache and metadata locally. Option E (Local attached storage) is correct because indexers traditionally write buckets to locally attached disks (e.g., direct-attached SAS/SATA/NVMe volumes) as their primary index storage. Option A (USB flash drives) is not a supported or recommended indexer storage medium due to reliability and performance limits. Option B (Search head cache) is incorrect because the search head cache accelerates searches and is not indexer data storage. Option C (Temporary memory storage) is incorrect because indexer data must persist; RAM is used only for transient in-memory processing, not as a storage type for indexer data.

Answer

USB flash drives

Answer

Search head cache

Answer

Temporary memory storage

Question 3

Which THREE factors commonly cause high CPU utilization on indexers?

Accepted Answer

Excessive data model acceleration jobs. Option A is correct because data model acceleration runs scheduled searches that build and periodically rebuild summary datasets on the indexer, and these background jobs consume significant CPU cycles, especially with many accelerated models. Option B is correct because complex or inefficient search queries (heavy use of wildcards, large time ranges, expensive commands like transaction, join, or stats) force the indexer to process large volumes of events and drive CPU utilization up. Option E is correct because high ingestion volume increases parsing, indexing, and pipeline processing work on the indexer, which is CPU-intensive and scales directly with the amount of incoming data. Option C does not belong because network latency affects search dispatch and data transfer speeds, not indexer CPU consumption. Option D does not belong because low disk space causes indexing to pause or block and triggers disk-related warnings, but it does not itself raise CPU utilization.

Answer

Network latency between indexers

Answer

Low disk space

Question 4

Which TWO of these factors determine when a bucket rolls from hot to warm?

Accepted Answer

maxDataSize. In Splunk index lifecycle management, a bucket rolls from hot to warm based on the index's maxDataSize (option A), which sets the size threshold (in MB, or auto/auto_high_volume) that a hot bucket may reach before it rolls to warm, and maxHotSpanSecs (option D), which sets the maximum age in seconds a hot bucket may remain hot before rolling. These two settings are the specific hot-to-warm rollover triggers configured in indexes.conf. The other options do not govern this transition: maxWarmDBCount (B) limits how many warm buckets are retained before older ones roll to cold, maxTotalDataSizeMB (C) controls total index size for freezing/retention, and frozenTimePeriodInSecs (E) defines the retention period after which buckets are frozen and deleted.

Answer

maxWarmDBCount

Answer

maxTotalDataSizeMB

Answer

frozenTimePeriodInSecs

Question 5

When planning a Splunk upgrade, which THREE of the following actions are considered best practices for maintaining system health?

Accepted Answer

Perform a mock upgrade in a staging environment. Option B is correct because performing a mock upgrade in a staging environment lets you validate the upgrade path, catch configuration or app issues, and rehearse rollback procedures before touching production. Option C is correct because verifying compatibility with all installed apps and add-ons ensures that third-party and custom components support the target Splunk version, preventing broken searches, dashboards, or data ingestion after the upgrade. Option E is correct because a full backup of indexer buckets and configuration files (such as $SPLUNK_HOME/etc and the index directories) provides a recovery point if the upgrade fails or corrupts data, which is essential for maintaining system health. Option A is not a best practice because the license master should generally be upgraded first (or in the correct order relative to other components) so it can properly serve licenses to upgraded peers. Option D is not a best practice because indexers should typically be upgraded before search heads, since search heads depend on indexers being available and compatible for search functionality.

Answer

Upgrade the license master last

Answer

Run the upgrade on the search heads before the indexers

Question 6

Which THREE factors influence the disk I/O performance of an indexer cluster?

Accepted Answer

Search concurrency. Search concurrency (A) is correct because concurrent searches generate simultaneous read operations against index buckets, and higher concurrency increases disk I/O load and contention on the indexers. Daily ingestion volume (B) is correct because the volume of data ingested per day determines how much data must be written to disk, merged, and later read, directly driving I/O throughput and IOPS requirements. Storage latency/type (D) is correct because the underlying disk technology (SSD vs. HDD, RAID configuration, SAN/NAS latency) fundamentally bounds the achievable read/write performance of the indexer. Deployment server latency (C) is not a factor because the deployment server distributes configuration/apps to forwarders and does not handle index-time data path I/O. Number of users logged in (E) is not a direct factor because user count alone does not determine I/O; it is the searches and ingest those users generate that matter.

Answer

Deployment server latency

Answer

Number of users logged in

Question 7

What is the impact of placing a very high number of indexes on a single indexer?

Accepted Answer

Increased file handle usage and potential performance degradation. Placing a very high number of indexes on a single indexer increases the number of open file handles because each index maintains multiple bucket files (rawdata, tsidx, etc.). This can lead to file handle exhaustion, increased memory usage for bucket metadata, and overall performance degradation, especially during search and indexing.

Answer

Reduced licensing costs

Answer

Improved search speed

Answer

Faster data ingestion

Question 8

Which THREE configuration files are most important when tuning indexer performance?

Accepted Answer

server.conf. server.conf is correct because it holds core indexer-level settings such as parallel ingestion pipelines (parallelIngestionPipelines) and general server tuning parameters that directly govern indexing throughput. limits.conf is correct because it controls resource limits like maxKBps (throttling), maxHotBuckets, and various queue sizes that determine how much data the indexer can process concurrently. indexes.conf is correct because it defines per-index properties such as maxDataSize, maxHotBuckets, maxWarmDBCount, and homePath/coldPath, which directly affect indexer storage and search performance. inputs.conf is not among the top three tuning files here since it mainly configures data inputs (stanzas, sourcetypes, host) rather than indexer performance limits. web.conf is not correct because it configures the Splunk Web UI and search head presentation settings, not indexer performance.

Answer

inputs.conf

Answer

web.conf

Question 9

A user reports that they cannot see data from an indexer peer in the Monitoring Console. Which service should you check first to ensure the MC is able to communicate with the remote instance?

Accepted Answer

splunkd. The Monitoring Console (MC) communicates with distributed instances via the splunkd management port (default 8089) to collect health and performance data. If the MC cannot see data from an indexer peer, the first service to verify is splunkd on the remote instance, because splunkd must be running and reachable for the MC to poll it. This makes splunkd the correct first check.

Answer

splunkweb

Answer

mongod

Answer

Deployment Client

Question 10

A search head cluster is currently running in a degraded state because the 'captain' has failed. What is the expected behavior?

Accepted Answer

A new captain is elected automatically. In a Splunk search head cluster, the captain is elected dynamically from the pool of members. If the captain fails, the remaining members automatically hold a new election and a new captain is chosen, allowing the cluster to continue operating with minimal disruption.

Answer

The cluster stops processing all searches

Answer

The cluster automatically reverts to standalone mode

Answer

Manual intervention is required to elect a new captain