SPLK-2002 Deployment Architecture And Clustering Practice Test 3 — 15 Questions

Question 1

When designing a large-scale multisite cluster, which factor most significantly impacts the search performance when running searches across all sites?

Accepted Answer

Network latency between sites. In a multisite indexer cluster, search heads must dispatch search requests to indexers in all sites and then merge results back. When a search spans all sites, the search head sends the search to peer nodes in every site, and results must traverse the WAN between sites. Network latency between sites directly adds to the round-trip time for each search phase (map and reduce), making it the dominant factor affecting cross-site search performance.

Answer

The number of buckets per indexer

Answer

The number of users

Answer

The number of search heads

Question 2

In an Indexer Cluster, which component stores the 'bucket' index files?

Accepted Answer

Indexer Peer. In a Splunk Indexer Cluster, the indexer peers are the nodes that actually receive, index, and store the raw data in the form of buckets. Buckets are directories containing rawdata, index files, and metadata, and they reside on the indexer peers' filesystems. The cluster master coordinates replication and searchability, but it does not store the bucket files themselves.

Answer

Search Head

Answer

Cluster Master

Answer

Deployment Server

Question 3

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 4

What must be installed on all Search Head Cluster members before they can join the cluster?

Accepted Answer

The same security key. All Search Head Cluster members must share the same security key (also called the cluster key or passphrase) to authenticate and join the cluster. This key is set via the `splunk edit shcluster-config -secret` command or in `server.conf` under `[shclustering]` with the `pass4SymmKey` setting. Without an identical key, members cannot establish trust and will fail to form the cluster.

Answer

A shared SSL certificate

Answer

A dedicated storage partition

Answer

A specialized Splunk App

Question 5

You want to move an indexer peer to a different site in an existing multisite cluster. What is the procedure to ensure the cluster recognizes the new site mapping?

Accepted Answer

Change the site value in server.conf and restart the indexer. To move a peer to a different site, you change the site value in the [general] stanza of server.conf on that peer and restart Splunk. On restart, the peer re-registers with the cluster master and reports its new site, and the master updates its site mapping accordingly. No rebalance or re-add is required for the site change itself, though a rebalance may be desired afterward to redistribute bucket copies.

Answer

Run a rebalance command on the CM

Answer

Delete the indexer and re-add it

Answer

Modify the indexer's hostname

Question 6

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 7

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 8

What is the primary function of the 'Cluster Master' in an Indexer Cluster?

Accepted Answer

To manage the indexer cluster's configuration and bucket state. The Cluster Master (now called Cluster Manager in newer versions) in an Indexer Cluster is responsible for managing the cluster's configuration and bucket state. It coordinates replication, tells indexers which buckets to replicate, manages search affinity, and handles peer registration. It does not handle data ingestion or serve the UI.

Answer

To handle incoming data from universal forwarders

Answer

To serve the Splunk user interface

Answer

To search across all indexers

Question 9

When configuring a Search Head Cluster, what does the 'captain' role do that other members do not?

Accepted Answer

It manages the cluster membership and configuration replication. The captain in a Search Head Cluster (SHC) is elected from among the members and is responsible for managing cluster membership, replicating configuration changes (via the deployer-pushed configs and the SHC's internal replication), and coordinating artifact replication. Other members perform searches and serve users but do not handle these cluster-management duties.

Answer

It acts as the primary user interface node

Answer

It stores all the search results

Answer

It performs all the searches for the cluster

Question 10

When adding a new indexer to a multisite cluster, which attribute must be correctly set in the configuration before joining the cluster?

Accepted Answer

The site assignment. In a multisite indexer cluster, each indexer must be assigned to a site (site0, site1, etc.) via the 'site' attribute in server.conf under the [general] stanza or in the clustering stanza. This site assignment determines replication and search affinity behavior, so it must be correctly set before the indexer joins the cluster.

Answer

The indexer's role

Answer

The license server path

Answer

The search head affinity index

Question 11

In an indexer cluster, why might you use the 'splunk list cluster-peers' command?

Accepted Answer

To verify the synchronization status of all indexer peers. The 'splunk list cluster-peers' command queries the cluster master and returns the status of all peer nodes, including whether each peer is Up, Down, or in a degraded state, along with its replication and searchability status. It is the standard CLI tool for verifying peer synchronization and health in an indexer cluster. It does not modify cluster state; it is read-only diagnostic output.

Answer

To remove a node from the cluster

Answer

To update the license configuration

Answer

To force a cluster rebalance

Question 12

Which component in Splunk is required to be the central point for managing licenses in a clustered environment?

Accepted Answer

The License Master. In a Splunk clustered environment, the License Master is the central component that manages and distributes licenses to all licensees (indexers, search heads, etc.). It enforces license usage limits and provides a single point of administration for licensing.

Answer

The Deployment Server

Answer

The Search Head

Answer

The Cluster Master

Question 13

You manage a Splunk indexer cluster with three peer nodes, a cluster manager, and a search head. The search head is configured with the cluster manager's URI in its server.conf under [clustering]. A new compliance requirement mandates that all searchable data copies must remain on the original peer that indexed the data, and replication to other peers is strictly prohibited. What should you do to meet this requirement while keeping the cluster functional?

Accepted Answer

Disable indexer clustering and revert the peers to standalone indexers, then configure the search head to query each indexer directly.. Indexer clustering is designed to replicate buckets across peers for fault tolerance and search efficiency. It does not support a mode where buckets are permanently pinned to their originating peer. The only way to meet a strict data locality requirement is to avoid clustering altogether and use standalone indexers with distributed search, ensuring that each indexer only stores and serves its own data.

Answer

Configure the search head to use only the originating peer for searches by setting search_factor to 0 and disabling replication.

Answer

Set replication_factor to 1 in the cluster manager's server.conf under [clustering] and push the configuration to all peers.

Answer

Set the cluster manager to maintenance mode and manually assign buckets to peers using the splunk CLI bucket command.

Question 14

A Splunk indexer cluster has three peer nodes (peer1, peer2, peer3) and one cluster master. The replication factor is 3 and the search factor is 2. Peer2 suffers a disk failure and goes offline for 48 hours. After peer2 is repaired and rejoins the cluster, the cluster master begins replicating buckets to it. Which statement accurately describes the state of the cluster immediately after peer2 rejoins?

Accepted Answer

The cluster is in a degraded state until peer2 receives the necessary bucket copies to meet the replication factor.. In an indexer cluster, the replication factor dictates how many total copies of each bucket must exist. When a peer is offline, buckets that had copies on that peer fall below the replication factor, causing a degraded state. Upon the peer's return, the cluster master replicates the missing copies to it. The cluster only returns to a complete state after all buckets again have the required number of copies, not merely when all peers are online.

Answer

The cluster is in a complete state because the cluster master immediately redistributes all buckets evenly across the three peers.

Answer

The cluster is in a complete state because all three peers are now online.

Answer

The cluster is in a complete state because the search factor of 2 is still satisfied by the remaining two peers.

Question 15

A Splunk search head cluster has five members. The captain is responsible for coordinating configuration replication and search artifacts. The administrator notices that the captain has not been elected for over an hour, and the cluster is unable to replicate configurations. Which condition is the most likely cause?

Accepted Answer

Fewer than three search head members are reachable, preventing a quorum for captain election.. In a search head cluster, captain election requires a quorum, which is a majority of the configured members. For a five-member cluster, at least three members must be reachable and able to communicate. If fewer than three are available, no captain can be elected, and configuration replication halts. This is a common failure mode when multiple search heads are down or network-partitioned. The cluster master and deployer are not involved in this election process.

Answer

The search head cluster deployer has not pushed a new configuration bundle, so the captain cannot be elected.

Answer

The cluster master is down, and without it, the search head cluster cannot elect a captain.

Answer

The search head cluster is configured with a replication_factor of 3, which is insufficient for captain election.