SPLK-2002 Practice Test 4 — 25 Questions

Question 1

You have added a new indexer to a cluster. The indexer is up, but the Cluster Master does not show it as 'Ready'. What is the most likely cause?

Accepted Answer

The security key on the indexer does not match the Cluster Master. For an indexer to join a cluster and reach 'Ready' status, it must present the same cluster security key (pass4SymmKey under the clustering stanza) as the cluster master. If the keys differ, the indexer can start and appear 'Up' but will be rejected during cluster handshake, so the master never marks it Ready.

Answer

The indexer is missing the license file

Answer

The cluster master is in maintenance mode

Answer

The indexer has not indexed any data yet

Question 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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

Question 16

When adding a new indexer to an existing Indexer Cluster, what is the best practice to ensure the indexer is ready before it starts receiving data?

Accepted Answer

Start the splunk service and wait for the CM to acknowledge registration.. When adding a new indexer to an existing cluster, the correct procedure is to install and configure the indexer with the cluster master's address and the peer replication/search ports, then start the splunkd service and wait for the CM to acknowledge the peer's registration. Only after the CM registers the peer and begins streaming the cluster bundle and replicating buckets should the indexer be considered ready to receive data. This ensures the peer has the correct configuration and bucket state before participating in search and replication.

Answer

Set the indexer to maintenance mode.

Answer

Manually copy index buckets from other peers.

Answer

Restart all existing peers.

Answer

Add the indexer to the indexer discovery list.

Question 17

You are troubleshooting a Search Head Cluster where a member node cannot join the cluster. Which log file on the node is the most useful for diagnosing the communication issue?

Accepted Answer

splunkd.log. splunkd.log is the primary log for the Splunk daemon (splunkd), which handles all core processes including cluster communication, replication, and configuration. When a Search Head Cluster member fails to join, the issue is almost always related to the cluster manager connection, replication ports, or configuration bundle application—all of which are logged in splunkd.log. This log contains detailed error messages about cluster membership, heartbeats, and REST API calls that are essential for diagnosing communication failures.

Answer

web_access.log

Answer

audit.log

Answer

metrics.log

Question 18

Which TWO tools in the Splunk UI assist in performance troubleshooting?

Accepted Answer

Monitoring Console. The Monitoring Console (A) is correct because it is Splunk's dedicated UI for health and performance monitoring, providing dashboards for resource usage, indexing throughput, search performance, and component-level diagnostics across the deployment. The Search Inspector (C) is correct because it appears in the Search app's Job menu and exposes detailed per-search performance data such as run duration, execution costs, search phases, and resource usage, which is essential for troubleshooting slow or inefficient searches. The Deployment Server (B) is incorrect because it is used to distribute apps and configuration to forwarders and clients, not to diagnose performance. The License Master (D) is incorrect because it manages license usage and violations, which is a licensing concern rather than a performance-troubleshooting tool. The Upload Data Wizard (E) is incorrect because it is used to ingest or onboard data, not to analyze or troubleshoot performance.

Answer

Deployment Server

Answer

License Master

Answer

Upload Data Wizard

Question 19

You have determined that a specific app deployed via the Deployment Server is causing indexer errors. Which THREE of the following actions can you take to rectify this?

Accepted Answer

Disable the server class associated with that app. Option A is correct because disabling the server class in the Deployment Server stops the deployment of the problematic app to the indexers, preventing further errors while you investigate. Option C is correct because removing the app folder from $SPLUNK_HOME/etc/deployment-apps on the Deployment Server removes it from the deployment payload, so it will no longer be pushed to clients. Option E is correct because replacing the app in the deployment-apps directory with a known stable version lets the Deployment Server distribute a corrected app, resolving the errors. Option B is not correct because restarting the master node (cluster manager) does not address the app causing indexer errors and is unrelated to deployment remediation. Option D is not correct because manually deleting the app folder on indexer peers is not a supported or persistent fix; the Deployment Server will simply redeploy the app on the next phone-home unless the server class or app is changed.

Answer

Restart the master node

Answer

Manually delete the app folder on all indexer peers

Question 20

You notice that your indexers are using different versions of a lookup file. Where should you look to find the authoritative version of the lookup file if it is being managed by the Cluster Master?

Accepted Answer

$SPLUNK_HOME/etc/master-apps. When the Cluster Master manages indexer configuration via a cluster bundle, the authoritative source is $SPLUNK_HOME/etc/master-apps on the Cluster Master. Apps and lookups placed here are packaged into the cluster bundle and pushed to all peers. The master-apps directory is the staging area for the master's bundle.

Answer

$SPLUNK_HOME/etc/slave-apps

Answer

$SPLUNK_HOME/etc/system/local

Answer

$SPLUNK_HOME/etc/apps