SPLK-2002 Practice Test 6 — 10 Questions

Question 1

What is the primary function of the 'Cluster Secret' in a Splunk Indexer Cluster?

Accepted Answer

To secure the communication between cluster nodes.. The Cluster Secret is a shared passphrase (set via the `pass4SymmKey` attribute in the `[clustering]` stanza of server.conf) that all peer nodes, the cluster master, and search heads use to authenticate each other when joining and communicating within the indexer cluster. It ensures that only nodes possessing the correct secret can participate in replication and cluster operations, effectively securing inter-node communication.

Answer

To define the replication factor.

Answer

To authorize search head access.

Answer

To manage indexer licensing.

Answer

To encrypt data in flight.

Question 2

When using a Search Head Cluster, what is the purpose of the 'captain'?

Accepted Answer

To coordinate search scheduling and replicate configuration bundles.. The captain in a Search Head Cluster coordinates search scheduling and replicates configuration bundles across the cluster members, ensuring consistent search execution and configuration. This is why option E is correct.

Answer

To act as the Cluster Master for indexers.

Answer

To store all bucket data for the indexers.

Answer

To receive data from forwarders.

Answer

To distribute search results to the end user.

Question 3

What is the primary benefit of 'bucket rolling' in an indexer?

Accepted Answer

Allows the indexer to optimize disk I/O by isolating active writing to a single bucket. Bucket rolling closes the currently active (hot) bucket once it reaches a size or age threshold and opens a new hot bucket for incoming data. This isolates all active writes to a single bucket, so the indexer avoids random writes across many files and can optimize disk I/O and caching. Older buckets become warm/cold and are read-only, which further improves write efficiency.

Answer

Enables the indexer to bypass the parsing queue

Answer

Increases the size of the bucket for better compression

Answer

Reduces the requirement for indexes to be searchable

Question 4

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 5

A user wants to restore data from frozen buckets. What is the process for making this data searchable again?

Accepted Answer

Copy to the thawedPath and use the 'rebuild' command. To restore frozen buckets, you copy the bucket files to the thawedPath directory defined in indexes.conf, then run the splunk rebuild command on that bucket directory to regenerate the necessary metadata (such as the .tsidx and bucket manifest files) so Splunk can search the data again. Simply placing files in the thawed path without rebuilding leaves the bucket unrecognized and unsearchable.

Answer

Directly copy files to the warm path

Answer

Change the frozenTimePeriodInSecs

Answer

Run 'splunk restore --bucket'

Question 6

You are troubleshooting a slow indexer cluster. You identify that the 'replication_port' is experiencing high latency. Where is the replication port defined?

Accepted Answer

server.conf. The replication_port setting is defined in server.conf under the [replication_port://<port>] stanza. It specifies the port on which an indexer listens for replication data from peer indexers in an indexer cluster. Since server.conf holds cluster-wide and node-level server settings, this is the correct file for replication port configuration.

Answer

indexes.conf

Answer

inputs.conf

Answer

cluster.conf

Question 7

What is the recommended way to handle an indexer peer that is permanently failing in an Indexer Cluster?

Accepted Answer

Use the 'splunk offline' command on the peer.. The 'splunk offline' command is the supported, graceful way to take an indexer peer out of an indexer cluster. It triggers the peer to flush its buckets, notify the Cluster Master, and allow the cluster to re-replicate any buckets for which the peer was primary, maintaining RF and SF. This is the recommended procedure for permanently failing or decommissioning a peer.

Answer

Ignore the peer and wait for timeout.

Answer

Delete the indexer's data directory manually.

Answer

Update the master node configuration.

Answer

Shutdown the service without notice.

Question 8

Which command is used to check the health of an Indexer Cluster from the Cluster Master CLI?

Accepted Answer

splunk show cluster-status. The command 'splunk show cluster-status' is used on the Cluster Master (now called Cluster Manager) to display the health and status of the indexer cluster, including information about peers, replication, and search factors. It provides a summary of the cluster's overall state.

Answer

splunk cluster-check

Answer

splunk inspect-cluster

Answer

splunk search-peers

Answer

splunk list indexers

Question 9

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 10

In a multi-site indexer cluster, which setting controls the number of copies of data kept per site?

Accepted Answer

site_replication_factor. In a multi-site indexer cluster, site_replication_factor is the setting in server.conf (under the [clustering] stanza) that defines how many copies of each bucket must exist within each site. It works alongside replication_factor, which sets the total number of copies across all sites. This ensures site-level redundancy so that a site failure does not cause data loss.

Answer

max_site_copies

Answer

site_data_count

Answer

cross_site_replication