These questions cover indexer clustering and Search Head Cluster architecture — the core of SPLK-2002 and where the exam expects deep knowledge of how Splunk distributes, replicates, and manages data at enterprise scale.
Question 1
In an indexer cluster, which events trigger automatic primary bucket rebalancing? (Select all that apply.)
- A) A rolling restart completes
- B) A new search head joins the cluster
- C) A peer node joins or rejoins the cluster
- D) The cluster master is manually restarted
Answers: A and C — Rolling restart completion and peer node joining/rejoining
Primary bucket rebalancing distributes primary bucket responsibilities evenly across peer nodes. It runs automatically when:
- A rolling restart completes — after all nodes cycle through their restarts, the master rebalances primaries to ensure even search load distribution
- A peer node joins or rejoins — when a new peer comes online (or returns after failure), the master redistributes primaries to include it
A new search head joining doesn't trigger indexer rebalancing — search heads and indexers are separate tiers. A cluster master manual restart also doesn't trigger rebalancing automatically.
Why primary rebalancing matters for architecture:
Primary buckets serve search queries. If all primaries sit on two of six indexers, those two handle all search I/O while four are idle. Rebalancing restores even search distribution and is one reason rolling restarts are preferred over simultaneous restarts — each peer restart triggers a small rebalance rather than a large disruption.
</details>Question 2
Which of the following are responsibilities of the Search Head Cluster (SHC) captain? (Select all that apply.)
- A) Job scheduling for all searches across SHC members
- B) Managing alert action suppressions (throttling)
- C) Storing the primary copy of indexed data
- D) Replicating the knowledge bundle to search peers
Answers: A, B, and D
The SHC captain is the elected coordinator for the Search Head Cluster. Its responsibilities include:
- Job scheduling: The captain distributes scheduled search jobs across SHC members to balance load and prevent duplicate execution
- Alert suppression: The captain manages alert throttling so the same alert doesn't fire multiple times across members
- Knowledge bundle replication: The captain sends the knowledge bundle (search-time configurations, lookups, apps) to indexer search peers so searches run with current configurations
The captain does not store indexed data — that's the indexers' role. The SHC captain is a coordinator role that rotates among members; any member can become captain.
Captain election: Uses the Raft consensus algorithm. If the captain becomes unavailable, the remaining members elect a new captain automatically.
</details>Question 3
An indexer cluster has 5 peer nodes configured with replication_factor=3 and search_factor=2. Two peer nodes fail simultaneously. What is the cluster's state?
- A) The cluster becomes read-only — searches continue but no new data is indexed
- B) The cluster continues indexing and searching with reduced redundancy
- C) New replicas are created automatically to restore RF=3 immediately
- D) The search factor requirement cannot be met, so searches fail
Answer: B — Continues with reduced redundancy
With replication_factor=3, each bucket has 3 copies across peers. With 5 nodes and 2 failures, 3 nodes remain. Each bucket still has its 3 copies distributed across the surviving 3 nodes — RF=3 is technically still met (just barely).
With search_factor=2, at least 2 searchable copies of each bucket must exist. On the surviving 3 nodes, the searchable copies remain available.
The cluster's response:
- The cluster master detects the 2 failed peers
- It marks the cluster as non-searchable for any buckets that have lost below SF=2 searchable copies
- For buckets still meeting SF requirements, searches continue normally
- The master initiates re-replication to restore RF=3, but this takes time as data moves between surviving nodes
The failure thresholds to know:
| Failures | Impact |
|---|---|
| ≤ RF-1 nodes fail | Data safe, may be below RF temporarily |
| RF or more nodes fail | Potential data loss (copies unavailable) |
| > nodes - SF | Some data becomes unsearchable |
Key Takeaways
- Primary rebalancing triggers on rolling restart completion and peer join/rejoin — not on search head changes
- SHC captain handles job scheduling, alert suppression, and knowledge bundle replication — it does not store data
- Losing fewer than RF nodes keeps the cluster operational with reduced redundancy; re-replication begins automatically to restore RF