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

Question 1

If you need to move a bucket from one peer to another in an indexer cluster manually, how should you proceed?

Accepted Answer

Use the Cluster Master to trigger a rebalance. To move a bucket between peers in an indexer cluster, the correct approach is to use the Cluster Master to trigger a rebalance (or a fixup). The CM orchestrates bucket placement according to replication and search factors, and a rebalance redistributes buckets across peers to balance load. Manually moving files bypasses the CM's metadata and corrupts cluster state.

Answer

Edit the bucket.json file on the peer

Answer

Delete the bucket directory from the peer

Answer

Use the 'mv' command on the filesystem

Question 2

A Splunk indexer cluster has a replication_factor of 3 and a search_factor of 2. The cluster manager is configured with site_replication_factor = origin:2, total:3 and site_search_factor = origin:1, total:2 for a multisite cluster with two sites. A peer in site1 fails and is removed from the cluster. What happens to the buckets that were replicated on that failed peer?

Accepted Answer

The cluster manager immediately creates new replicas on other peers in site1 to satisfy origin:2, and if site1 lacks capacity, it creates replicas in site2 to satisfy total:3.. When a peer fails in a multisite cluster, the cluster manager initiates bucket fixup to restore the configured site_replication_factor and site_search_factor. It prioritizes creating copies within the same site to meet the origin requirement, but will use the other site if necessary to achieve the total count. This ensures that data remains highly available and searchable even after a peer loss.

Answer

The cluster manager promotes the remaining searchable copies in site1 to primary buckets and stops replicating to site2 to avoid cross-site traffic.

Answer

The cluster manager waits for the failed peer to come back online before taking any action, because multisite replication requires all original peers to be available.

Answer

The buckets on the failed peer are marked as searchable only in site2, and the cluster manager reduces the replication_factor to 2 to compensate.

Question 3

A Splunk administrator is deploying a multisite indexer cluster with two sites: site1 and site2. The cluster master is configured with site1 as the primary site. The administrator wants to ensure that search affinity is honored and that the cluster can tolerate the loss of an entire site. Which two configurations are required to achieve these goals? (Choose two.)

Accepted Answer

Set site_search_factor to origin:1, total:2.. To tolerate the loss of an entire site in a multisite cluster, you must configure site_replication_factor and site_search_factor so that each site holds a complete set of copies. With two sites, site_replication_factor should be set to origin:2, total:4 to ensure each site has two copies, and site_search_factor to origin:1, total:2 to ensure each site has a searchable copy. These settings guarantee that if one site fails, the other site can continue to serve searches without data loss.

Answer

Set replication_factor to at least 2 and search_factor to at least 1.

Answer

Set search_affinity to true on all search heads.

Answer

Set multisite to true in the cluster master's server.conf.

Question 4

When planning a deployment, which component is required to act as the primary communication hub for managing configuration bundles in an Indexer Cluster?

Accepted Answer

Cluster Master. The Cluster Master (now called Cluster Manager in newer versions) is the central coordination point for an indexer cluster. It manages the replication and search factors, distributes configuration bundles to peer nodes, and coordinates bucket replication and fixup. It is the required primary communication hub for configuration bundle management in an indexer cluster.

Answer

License Master

Answer

Deployment Server

Answer

Search Head

Question 5

You are configuring a Search Head Cluster and need to ensure that local user configurations are not overwritten by cluster-wide bundles. What is the correct way to handle these local configurations?

Accepted Answer

Use the local/ directory for configuration files that should not be replicated. In a Search Head Cluster, configurations are replicated from the deployer or captain via bundles, but files in the local/ directory of an app or system are not replicated and are preserved on each member. To keep local user configurations from being overwritten by cluster-wide bundles, you place them in the local/ directory, which takes precedence and is not overwritten by replicated configurations.

Answer

Move files to the var/run directory

Answer

Set the configuration to immutable in server.conf

Answer

Use the shcluster/ directory

Question 6

When implementing a multisite indexer cluster, what happens if the cluster master becomes unreachable for a short duration?

Accepted Answer

Indexer peers continue to accept and index data. In a multisite indexer cluster, if the cluster master becomes unreachable for a short duration, indexer peers continue to accept and index data. The master is responsible for coordinating replication and search affinity, but peers can operate independently for a period. Indexing does not stop immediately, and search heads can still return results from available peers. Replication across sites is not forced immediately; it continues based on existing policies.

Answer

All indexing stops immediately

Answer

Search heads stop returning results

Answer

Data replication across sites is forced immediately

Question 7

Which component in an Indexer Cluster is responsible for assigning buckets to peers?

Accepted Answer

The Cluster Master. In an indexer cluster, the Cluster Master (also called the master node) is responsible for coordinating replication and managing bucket assignment to peers. It tells peers which buckets to replicate and where to search. It does not handle data indexing itself but orchestrates the cluster.

Answer

The Search Head

Answer

The indexer peer itself

Answer

The Deployment Server

Question 8

You are deploying a Search Head Cluster across multiple data centers. Which feature allows you to prioritize searches performed by users in the same site as the indexers?

Accepted Answer

Search affinity. Search affinity is the Search Head Cluster feature that keeps a search on a search head located in the same site as the indexers holding the data, minimizing cross-site traffic. When search affinity is enabled, the SHC captain assigns searches to members based on the site of the indexers that own the relevant buckets. This is distinct from indexer discovery or site-aware routing, which operate at the indexer/forwarder layer rather than the search head layer.

Answer

Site-aware routing

Answer

Data locality

Answer

Load balancing

Question 9

What is the primary function of the 'search_factor' in an indexer cluster?

Accepted Answer

The number of searchable copies of each bucket. The search_factor in an indexer cluster determines how many searchable copies of each bucket exist across the cluster, i.e., the number of peers that hold a searchable (indexed) copy of the data. It is set on the cluster master and must be less than or equal to the replication factor. This directly affects search performance and availability because searches can be distributed across more peers.

Answer

The maximum number of concurrent searches

Answer

The number of indexer peers in the cluster

Answer

The number of search heads allowed in the cluster

Question 10

A new indexer is added to a cluster. How does the cluster handle the historical data that already exists on other indexers?

Accepted Answer

The cluster redistributes buckets only if necessary to meet factors. When a new peer joins an indexer cluster, the Cluster Master does not automatically copy all historical buckets to it. Instead, the CM evaluates whether the cluster's replication and search factors are still satisfied; if adding the peer is needed to meet RF/SF for under-replicated buckets, those buckets are replicated to the new node. Otherwise, the new peer only receives newly indexed data going forward.

Answer

The new node only receives new data

Answer

The cluster forces a reindex of all historical data

Answer

All historical data is immediately copied to the new node

Question 11

When configuring a Search Head Cluster, what is the purpose of the 'replication_factor' setting in server.conf?

Accepted Answer

To define the number of copies of search artifacts. In an SHC, the replication_factor defines how many copies of the search-related configurations are replicated across members.

Answer

To limit the number of users

Answer

To specify the number of search nodes in the cluster

Answer

To balance the search load across nodes

Question 12

In an indexer cluster, what happens if the cluster master is permanently lost and you do not have a backup of the 'master-apps' directory?

Accepted Answer

You will be unable to distribute new configuration updates. The cluster master stores cluster-wide configuration in $SPLUNK_HOME/etc/master-apps, which is bundled and pushed to peers via the configuration replication mechanism. If the master is lost without a backup of master-apps, you can rebuild a master and rejoin peers, but the custom configurations (indexes, props, transforms, etc.) that were only on the master are gone, so you cannot distribute new or updated configuration bundles. Data itself resides on the peers and is not lost, and peers continue serving searches with their last-received configuration.

Answer

The data is permanently lost

Answer

The indexers continue to work normally indefinitely

Answer

You can restore the configuration from the peer nodes

Question 13

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 14

Which of the following is a key advantage of using a Search Head Cluster over a single search head?

Accepted Answer

High availability of search and user interface. A Search Head Cluster (SHC) provides high availability and horizontal scaling for search and UI workloads: if one member fails, others continue serving searches, and users can be load-balanced across members. The captain coordinates configuration replication and artifact replication, but the core benefit is resilience and capacity for search, not indexing. Indexing is handled by indexers, not search heads, so SHC does not improve indexing performance.

Answer

Faster indexing performance

Answer

Reduced license costs

Answer

Smaller storage footprint

Question 15

You are tasked with upgrading an Indexer Cluster. Which order of operations is recommended by Splunk best practices?

Accepted Answer

Upgrade the Cluster Master first, then the indexer peers. Splunk best practices recommend upgrading the Cluster Master first, then the indexer peers. This is because the Cluster Master must be running a version that is compatible with the peers, and it manages the upgrade process. After the master is upgraded, peers can be upgraded in a rolling fashion to maintain cluster availability.

Answer

Upgrade the search heads first

Answer

Upgrade all components simultaneously

Answer

Upgrade the indexer peers first, then the Cluster Master