SPLK-2002 Multiple Select — 20 Questions

Question 1

Which TWO of the following are valid ways to monitor the status of an Indexer Cluster?

Accepted Answer

Using the CLI command 'splunk show cluster-status'.. Option B is correct because the Splunk CLI command 'splunk show cluster-status' (run on a cluster manager or member) reports the health and status of the indexer cluster, including peer and search head connectivity and replication status. Option C is correct because the Monitoring Console provides a dedicated Indexer Clustering dashboard that surfaces cluster health, peer status, replication and search factor compliance, and bucket-fixup activity. Option A is incorrect because license usage logs track license consumption, not cluster health or peer status. Option D is incorrect because forwarder logs show data forwarding activity and connectivity from the forwarder's perspective, not the status of the indexer cluster itself. Option E is incorrect because running a search on indexers tests search functionality but does not provide a valid, supported method for monitoring overall indexer cluster status.

Answer

Checking the license usage logs.

Answer

Reviewing the forwarder logs.

Answer

Running a search on the indexers directly.

Question 2

Which THREE of the following are common causes for a Search Head Cluster member to lose contact with the captain?

Accepted Answer

Service load is too high causing timeouts.. Option A is correct because a Search Head Cluster member under excessive service load can fail to respond to the captain's periodic heartbeats within the configured timeout, causing the captain to mark it as down and lose contact. Option D is correct because network instability (packet loss, latency, or intermittent connectivity) disrupts the heartbeat and replication traffic between members and the captain, breaking the cluster communication. Option E is correct because the captain and members communicate over the replication port (default 9887), so if a firewall blocks that port, the member cannot exchange heartbeats or replicate artifacts and loses contact with the captain. Option B is not a cause because the license master is unrelated to SHC captain heartbeat communication; a member can remain in contact with the captain even if licensing is unavailable. Option C is not a cause because indexer cluster load affects search and indexing performance, not the SHC internal captain-member heartbeat channel.

Answer

License master is offline.

Answer

The indexer cluster is busy.

Question 3

Which TWO performance-related tasks should be performed on a regular basis?

Accepted Answer

Reviewing the Search Activity dashboard. Option A is correct because reviewing the Search Activity dashboard on a regular basis reveals search performance metrics such as search concurrency, runtimes, and skipped or queued searches, allowing administrators to identify and address performance degradation proactively. Option E is correct because monitoring index storage usage regularly helps prevent indexes from reaching disk capacity limits, which would cause indexing to pause or searches to fail, and it supports capacity planning and retention policy tuning. Option B is not appropriate because deleting all historical data is destructive and unnecessary; retention should be managed through configured policies, not wholesale deletion. Option C is wrong because restarting indexers daily is disruptive and does not improve performance; indexers should only be restarted for maintenance or troubleshooting. Option D is incorrect because license capacity is a purchased entitlement that cannot and should not be increased daily as a performance task.

Answer

Deleting all historical data

Answer

Restarting all indexers daily

Answer

Increasing license capacity daily

Question 4

Which THREE of the following are risks if the replication_factor is too low?

Accepted Answer

Data loss if an indexer fails.. In Splunk indexer clustering, replication_factor determines how many copies of each bucket are maintained across peer nodes, so setting it too low directly creates availability and durability risks. Option B is correct because with a low replication_factor there are fewer bucket copies than needed to tolerate failures, so if an indexer (peer) holding a copy fails, buckets can be lost or go missing until recovered. Option C is correct because the search factor (number of searchable copies) can never exceed the replication_factor; if replication_factor is set below the desired search factor, the cluster cannot meet its search factor requirements. Option D is correct because with minimal replicas, taking a peer offline for maintenance removes a copy and can push buckets below the replication factor, causing degraded search availability and longer downtime while the cluster re-replicates or recovers. Option A is not correct because indexing speed is not directly governed by replication_factor in this way, and Option E is not correct because the cluster manager's CPU usage is not a defined risk of a low replication_factor.

Answer

Slower indexing speed.

Answer

Higher CPU usage on the CM.

Question 5

Which THREE metrics are critical for monitoring indexer health in the Monitoring Console?

Accepted Answer

Memory usage. Memory usage (A) is critical because indexers rely heavily on RAM for the index cache and search-time processing, and excessive memory pressure can cause swapping, slow searches, or crashes. Disk I/O latency (D) is critical because indexers continuously write buckets to disk and read them during searches, so high latency directly degrades indexing throughput and search performance. CPU utilization (E) is critical because indexing pipelines, search processing, and bucket merging are CPU-intensive, and sustained high utilization indicates the indexer is saturated. The number of active apps (B) and number of logged-in users (C) are not indexer health metrics; they relate to user activity or app deployment rather than the performance and stability of the indexing tier.

Answer

Number of active apps

Answer

Number of logged-in users

Question 6

You are investigating why an indexer node is not reporting to the Cluster Master. Which THREE of the following are the most likely causes?

Accepted Answer

The security key ('pass4SymmKey') is mismatched. Option B is correct because the pass4SymmKey in the [clustering] stanza of server.conf must match across all cluster members and the master; a mismatch prevents the indexer from authenticating and registering with the Cluster Master. Option C is correct because indexers communicate with the master over the management port (default 8089), so a firewall blocking that port stops the indexer from reporting its status. Option E is correct because an indexer must be configured with the cluster-member role (mode = slave in [clustering]) to join and report to the master; without it, the instance never registers. Option A is not a cause because warm bucket count affects disk usage and search performance, not cluster registration. Option D is not a cause because the replication port (default 9887) is used for peer-to-peer bucket replication between indexers, not for reporting to the Cluster Master.

Answer

The indexer has too many warm buckets

Answer

The replication port is blocked by a firewall

Question 7

An Indexer Cluster is in 'Maintenance Mode'. Which THREE of the following implications must be considered during this time?

Accepted Answer

The peers will continue to index incoming data normally. In Splunk maintenance mode, option A is correct because the indexer peers keep indexing incoming data normally; maintenance mode only suppresses certain master-level activities, not data ingestion. Option B is correct because the cluster master stops alerting on missing buckets, so replication/primacy violations are not reported during this window. Option E is correct because the master also halts bucket fix-up activities, meaning it will not attempt to search for and replicate or restore missing bucket copies. Option C is wrong because the master does not force an immediate bucket re-balance in maintenance mode; rebalancing is a separate, manual operation. Option D is wrong because searches are not automatically disabled by maintenance mode; search functionality continues unless separately restricted.

Answer

The Master will force a bucket re-balance immediately

Answer

All searches will be automatically disabled

Question 8

Which TWO items are stored in the index directory?

Accepted Answer

TSIDX files. In Splunk, the index directory (e.g., $SPLUNK_HOME/var/lib/splunk/defaultdb/db) stores the indexed data itself, which includes both the rawdata files (compressed journal slices) and the TSIDX files that hold the time-series index used to locate events quickly, so options B and C are correct. TSIDX files map timestamps and terms to the rawdata slices, and the rawdata files are the compressed, bucket-organized copies of the ingested events. License master keys are not stored in the index directory; they are managed by the license manager (in $SPLUNK_HOME/etc/licenses or the license pool configuration). Search logs are written to $SPLUNK_HOME/var/log/splunk (e.g., search.log per search job), not the index directory. App configuration files live under $SPLUNK_HOME/etc/apps (and related etc directories), not in the index storage.

Answer

License master keys

Answer

Search logs

Answer

App configuration files

Question 9

Which THREE components are part of the Splunk index directory structure?

Accepted Answer

coldPath. In Splunk's indexes.conf, each index defines three path settings that make up its on-disk directory structure: coldPath (B), homePath (D), and thawedPath (E). homePath holds the hot and warm buckets (the newly written, actively searchable data), coldPath stores buckets that have rolled from warm to cold, and thawedPath is where archived buckets are restored when an admin runs the rebuild command to bring them back online. These three are the actual configurable path attributes of an index, so B, D, and E are correct. The other options are not valid index path settings: hotPath (A) and warmPath (C) do not exist as separate configuration keys because hot and warm buckets both reside under homePath, so they are not part of the index directory structure.

Answer

hotPath

Answer

warmPath

Question 10

Which TWO are common causes of 'Search Head Cluster' configuration replication failures?

Accepted Answer

Incorrect pass4SymmKey on one of the nodes. Option A is correct because the search head cluster uses the pass4SymmKey in server.conf to authenticate and encrypt replication traffic between members; if one node has a different key, the captain cannot push configurations and replication fails. Option E is correct because configuration replication and cluster communication occur over the management port 8089 (REST/mgmt), so a firewall blocking 8089 between members prevents the captain from replicating bundles to peers. Option B is not a cause of replication failure—concurrent searches affect search performance and resource contention, not the config replication mechanism. Option C is unrelated: the license master governs licensing, not the SHC's internal replication of configurations. Option D is not a valid cause; server names need not match across cluster members, and replication depends on the shared pass4SymmKey and reachable management port, not identical hostnames.

Answer

Too many concurrent searches

Answer

Incorrect license master configuration

Answer

Mismatch in server names

Question 11

Which THREE factors should be considered when planning the hardware requirements for a multisite indexer cluster?

Accepted Answer

Disk I/O throughput. Option A (Disk I/O throughput) is correct because indexers must sustain high-throughput writes for incoming data and fast reads for searches, so IOPS and disk latency directly determine indexing and search performance. Option C (Inter-site network latency and bandwidth) is correct because in a multisite indexer cluster, replication and searchable-copy traffic crosses sites, and WAN latency/bandwidth affects replication factor satisfaction, search affinity, and site failover behavior. Option D (The total number of indexer peers) is correct because the number of peers determines replication and search factor distribution across sites, quorum requirements, and the aggregate storage/CPU capacity needed to hold replicated buckets. Option B (chassis color) is irrelevant since it has no bearing on performance, capacity, or cluster topology. Option E (number of concurrent web users) is not a hardware-sizing factor for the indexer cluster itself; user count affects search load indirectly, but the question asks about indexer cluster hardware planning, which is driven by data volume, replication/search factors, and peer count.

Answer

The color of the server chassis

Answer

The number of concurrent web users

Question 12

Which TWO of the following are features of the Indexer Cluster Master?

Accepted Answer

Managing bucket replication.. Option B is correct because the Indexer Cluster Master coordinates bucket replication across peer indexers, managing the replication factor and ensuring each bucket is copied to the required number of peers. Option D is correct because the Master continuously monitors the health of peer indexers, tracking which peers are up or down and handling their status within the cluster. Option A is incorrect because data parsing is performed by indexers (and heavy forwarders), not by the cluster master. Option C is incorrect because user authentication is handled by the search head or an external authentication system, not the indexer cluster master. Option E is incorrect because routing search results to users is a function of the search head, not the cluster master.

Answer

Performing data parsing.

Answer

Authenticating users.

Answer

Routing search results to users.

Question 13

Which TWO methods are recommended to optimize search performance when dealing with large datasets?

Accepted Answer

Use data models and acceleration. Option A (Use data models and acceleration) is correct because data models in Splunk allow you to define structured, reusable datasets, and acceleration pre-computes and stores the results of those models (or reports) so that subsequent searches run against the accelerated summaries rather than scanning the full raw dataset, dramatically reducing search time on large volumes of data. Option D (Filter searches using indexed fields) is correct because indexed fields (such as host, source, sourcetype, and any custom indexed fields) are stored in the index and can be used in the base search to prune the data before it is retrieved, minimizing the amount of data scanned and thus improving performance. Option B (Use the 'transaction' command) is not recommended for optimization because transaction is a memory- and CPU-intensive command that groups events and can severely degrade performance on large datasets. Option C (Increase the number of indexers) is not a search-performance optimization method per se; it is a scaling/architecture change that adds hardware and complexity rather than optimizing how searches are written or executed. Option E (Disable all authentication) is a security anti-pattern and has no bearing on search performance.

Answer

Use the 'transaction' command

Answer

Increase the number of indexers

Answer

Disable all authentication

Question 14

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 15

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 16

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 17

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 18

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 19

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 20

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