Courseiva

CCNA Deployment Architecture And Clustering Questions

29 questions · Deployment Architecture And Clustering · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQhard

A Splunk indexer cluster is configured with a replication factor of 3 and a search factor of 2. The cluster has five peer nodes. A bucket is currently searchable on two peers. The cluster master detects that one of those peers has failed. What immediate action does the cluster master take to maintain the search factor?

A.It marks the bucket as searchable on the failed peer until the peer is restored.
B.It waits for the failed peer to come back online before taking any action.
C.It promotes a non-searchable copy on another peer to searchable status.
D.It initiates replication of a new bucket copy from a searchable peer to a peer without a copy.
AnswerC

When the search factor is at risk, the cluster master immediately promotes an existing non-searchable copy to searchable status to restore the search factor. This ensures that the required number of searchable copies is maintained without waiting for full replication. The master selects a peer that has a non-searchable copy of the bucket and instructs it to make that copy searchable. This is a rapid operation compared to replicating a new copy.

Why this answer

The search factor defines the number of searchable copies required. When a peer hosting a searchable copy fails, the cluster master acts to restore the search factor. Its first choice is to promote an existing non-searchable copy on another peer to searchable status, which is faster than replicating a new copy.

This immediate promotion ensures that searches can still access the required number of searchable copies. Only if no non-searchable copies are available will the master replicate a new copy.

Exam trap

The trap here is thinking that the cluster master always replicates a new bucket copy to fix a search factor violation, when it typically promotes an existing non-searchable copy first.

Practice this question →
2
MCQmedium

A search head cluster is currently running in a degraded state because the 'captain' has failed. What is the expected behavior?

A.The cluster stops processing all searches
B.The cluster automatically reverts to standalone mode
C.A new captain is elected automatically
D.Manual intervention is required to elect a new captain
AnswerC

Search head clustering uses an elected captain to coordinate replication and job scheduling. If the captain fails, the remaining members trigger a captain election automatically, restoring the cluster to a healthy state without manual intervention, so the degraded condition is temporary.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that manual intervention is needed to elect a new captain, when the process is automatic and requires only a quorum of members.

How to eliminate wrong answers

Option A is wrong because the cluster does not stop processing searches; it continues with a newly elected captain. Option B is wrong because the cluster does not revert to standalone mode; it remains a cluster and elects a new captain. Option D is wrong because manual intervention is not required; the election is automatic.

Practice this question →
3
MCQeasy

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

A.To limit the number of users
B.To specify the number of search nodes in the cluster
C.To balance the search load across nodes
D.To define the number of copies of search artifacts
AnswerD

This ensures configuration redundancy among search heads.

Why this answer

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

Practice this question →
4
MCQmedium

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?

A.The search head cluster deployer has not pushed a new configuration bundle, so the captain cannot be elected.
B.The cluster master is down, and without it, the search head cluster cannot elect a captain.
C.The search head cluster is configured with a replication_factor of 3, which is insufficient for captain election.
D.Fewer than three search head members are reachable, preventing a quorum for captain election.
AnswerD

Search head clusters use a quorum-based election process. A majority of members must be reachable for a captain to be elected. With five members, a majority is three. If fewer than three members are reachable, no captain can be elected, and the cluster cannot replicate configurations. This is the most likely cause of the prolonged lack of a captain.

Why this answer

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.

Exam trap

The trap here is assuming that the cluster master or deployer is required for search head captain election, when in fact the search heads elect a captain among themselves based on quorum.

Practice this question →
5
MCQhard

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?

A.Run a rebalance command on the CM
B.Change the site value in server.conf and restart the indexer
C.Delete the indexer and re-add it
D.Modify the indexer's hostname
AnswerB

Editing the `site` field in `server.conf` and restarting the indexer causes it to re-register with the cluster manager, which updates the site mapping. This satisfies the stem's requirement that the cluster recognise the new site assignment, since site membership is read from `server.conf` at startup.

Why this answer

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.

Exam trap

The trap is assuming a cluster-level command (rebalance) or node re-add is needed to change a peer's site, when the actual requirement is editing server.conf and restarting the peer.

How to eliminate wrong answers

Option A is wrong because the rebalance command redistributes bucket copies across peers for balance; it does not change a peer's site assignment. Option C is wrong because deleting and re-adding the indexer is unnecessary and disruptive; the peer can re-register with the new site value. Option D is wrong because changing the hostname does not affect site mapping and would break cluster identity if not coordinated with the master.

Practice this question →
6
MCQmedium

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?

A.web_access.log
B.audit.log
C.splunkd.log
D.metrics.log
AnswerC

splunkd.log records the Search Head Cluster member's captain election, replication and heartbeat activity, so connection refusals, port mismatches or secret errors preventing cluster joining appear there. Other logs cover search-time or indexing concerns, not the cluster membership communication the stem describes.

Why this answer

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.

Exam trap

SPLK-2002 often tests whether candidates know which log file contains cluster-related errors; many mistakenly choose web_access.log or metrics.log because they think all communication is web-based or performance-related.

How to eliminate wrong answers

Option A is wrong because web_access.log only records HTTP/HTTPS access to Splunk Web, not internal cluster communication or daemon-level errors. Option B is wrong because audit.log tracks user authentication and authorization events, not cluster join operations or network communication issues. Option D is wrong because metrics.log contains performance and usage metrics (such as CPU, memory, and queue sizes), not detailed error messages about cluster membership or communication failures.

Practice this question →
7
MCQeasy

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

A.Cluster Master
B.License Master
C.Deployment Server
D.Search Head
AnswerA

The Cluster Master distributes configuration bundles to peer nodes and coordinates the cluster's replication and search factors. It is the central management and communication hub, distinct from indexers that store data and search heads that handle queries.

Why this answer

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.

Exam trap

SPLK-2002 often tests the confusion between the Cluster Master (which manages indexer cluster replication and configuration bundles) and the Deployment Server (which pushes apps to forwarders), since both 'manage configuration' in different scopes.

How to eliminate wrong answers

Option B is wrong because the License Master only tracks license usage and does not distribute configuration bundles or manage cluster replication. Option C is wrong because the Deployment Server pushes apps and configurations to universal/heavy forwarders and other clients, not to indexer cluster peers as part of cluster bundle management. Option D is wrong because the Search Head queries indexers and does not manage cluster configuration bundles; search head clustering is a separate concern.

Practice this question →
8
MCQmedium

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

A.All indexing stops immediately
B.Search heads stop returning results
C.Data replication across sites is forced immediately
D.Indexer peers continue to accept and index data
AnswerD

Indexer peers hold replicated buckets and continue indexing incoming data independently; the master only coordinates replication and search head functions. A brief master outage therefore does not halt ingestion, satisfying the scenario's short-duration unreachability constraint.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that the cluster master is a single point of failure for indexing; in reality, peers continue to index for a short period, but prolonged outage can cause issues.

How to eliminate wrong answers

Option A is wrong because indexing does not stop immediately; peers continue to index data even without the master. Option B is wrong because search heads can still return results from peers that are up, though search affinity may be affected. Option C is wrong because data replication across sites is not forced immediately; replication continues according to configured policies, and the master's absence does not trigger immediate forced replication.

Practice this question →
9
MCQmedium

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

A.Upgrade the Cluster Master first, then the indexer peers
B.Upgrade the search heads first
C.Upgrade all components simultaneously
D.Upgrade the indexer peers first, then the Cluster Master
AnswerA

The cluster master coordinates replication and peer management, so upgrading it first ensures it can manage peers running the newer version. Upgrading peers before the master risks version incompatibility and search degradation during the rolling upgrade.

Why this answer

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.

Exam trap

The trap is assuming that upgrading peers first or all at once is faster, but it can cause version mismatches and cluster outages.

How to eliminate wrong answers

Option B is wrong because upgrading search heads first is not recommended; search heads should be upgraded after indexers to ensure compatibility. Option C is wrong because upgrading all components simultaneously can cause downtime and compatibility issues. Option D is wrong because upgrading indexer peers before the Cluster Master can lead to version incompatibility and cluster instability.

Practice this question →
10
MCQeasy

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

A.The Search Head
B.The indexer peer itself
C.The Deployment Server
D.The Cluster Master
AnswerD

The Cluster Master (now manager) coordinates the indexer cluster: it controls bucket replication and search factor, and tells peers which buckets to hold. This satisfies the stem's requirement for the component that assigns buckets, not the peers or search heads themselves.

Why this answer

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.

Exam trap

The trap is assuming that the indexer peer itself or the search head manages bucket assignment, but only the Cluster Master has that orchestration role.

How to eliminate wrong answers

Option A is wrong because the Search Head is responsible for search requests and knowledge object management, not bucket assignment. Option B is wrong because an indexer peer does not assign buckets; it receives instructions from the Cluster Master. Option C is wrong because the Deployment Server is used for configuration management of forwarders, not for indexer cluster bucket assignment.

Practice this question →
11
MCQmedium

A Splunk administrator is configuring a search head cluster with three members. They want to ensure that if the captain fails, the cluster can still elect a new captain and continue operating. Which configuration must be in place to allow captain election to succeed?

A.At least two search head members must be operational and able to communicate.
B.All three search head members must be online to elect a captain.
C.The cluster master must be online to participate in the election.
D.The deployer must be configured to automatically promote a new captain.
AnswerA

For a three-member search head cluster, a quorum is a majority, which is two members. If the captain fails, the remaining two members can still form a quorum and elect a new captain. Therefore, at least two members must be operational and able to communicate for captain election to succeed. This ensures high availability and continued operation.

Why this answer

In a search head cluster, captain election requires a quorum, which is a majority of the configured members. For a three-member cluster, a quorum is two members. If the captain fails, the remaining two members can communicate and elect a new captain, ensuring continued operation.

This design provides fault tolerance. The cluster master and deployer are external components and do not participate in the election process.

Exam trap

The trap here is believing that all members must be online or that an external component like the deployer or cluster master is needed for captain election, when only a quorum of search head members is required.

Practice this question →
12
MCQmedium

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

A.It acts as the primary user interface node
B.It manages the cluster membership and configuration replication
C.It stores all the search results
D.It performs all the searches for the cluster
AnswerB

The captain is elected from the cluster members and uniquely handles cluster membership changes, configuration replication and coordination of search artefact replication. Other members run searches and hold replicated knowledge objects but do not perform these central management duties.

Why this answer

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.

Exam trap

SPLK-2002 often tests whether candidates think the captain is a 'super search head' that does all the work — the trap is picking 'performs all searches' or 'primary UI node' when the captain's real job is cluster management and config replication.

How to eliminate wrong answers

Option A is wrong because all SHC members can serve as user interface nodes — users can be load-balanced across any member, not just the captain. Option C is wrong because search results are not stored centrally on the captain; results are held in each search head's dispatch directory and replicated as needed, not owned by the captain. Option D is wrong because all members perform searches — the captain does not monopolize search execution; in fact, the captain also runs searches like any other member.

Practice this question →
13
MCQmedium

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?

A.The cluster is in a complete state because the cluster master immediately redistributes all buckets evenly across the three peers.
B.The cluster is in a degraded state until peer2 receives the necessary bucket copies to meet the replication factor.
C.The cluster is in a complete state because all three peers are now online.
D.The cluster is in a complete state because the search factor of 2 is still satisfied by the remaining two peers.
AnswerB

When a peer goes offline, the cluster master marks the buckets that were on that peer as under-replicated. The cluster enters a degraded state if the number of available copies falls below the replication factor. While peer2 was offline, other peers may have been unable to maintain three copies. Upon rejoin, the master initiates replication to bring the cluster back to a complete state, so it remains degraded until replication finishes.

Why this answer

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.

Exam trap

The trap here is assuming that the cluster becomes complete as soon as all peers are online, ignoring the need to restore missing bucket copies to meet the replication factor.

Practice this question →
14
MCQhard

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

A.The number of searchable copies of each bucket
B.The maximum number of concurrent searches
C.The number of indexer peers in the cluster
D.The number of search heads allowed in the cluster
AnswerA

The search_factor sets how many searchable copies of each bucket the cluster maintains, separate from the replication_factor that governs total copies. Raising it increases search capacity and resilience, satisfying the stem's requirement to define searchable replica count across peer nodes.

Why this answer

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.

Exam trap

SPLK-2002 often tests the confusion between replication_factor (total copies) and search_factor (searchable copies), so candidates who pick 'number of peers' or 'concurrent searches' miss the bucket-copy distinction.

How to eliminate wrong answers

Option B is wrong because the maximum number of concurrent searches is governed by search head and indexer capacity settings (e.g., max_searches_per_cpu), not search_factor. Option C is wrong because the number of indexer peers is a cluster topology fact, not a factor setting — search_factor does not control peer count. Option D is wrong because the number of search heads is unrelated to search_factor; search head count is a deployment decision and not constrained by this cluster setting.

Practice this question →
15
MCQeasy

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

A.Search Head
B.Indexer Peer
C.Cluster Master
D.Deployment Server
AnswerB

Indexer peers store the bucket index files, including rawdata journals, tsidx files and bloom filters, on their local disk. This satisfies the stem's constraint that the component holding bucket data must be the peer itself, not the cluster manager, which only coordinates replication and searchability across peers.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that the Cluster Master stores index data or that the Search Head does, when in fact only the indexer peers store buckets.

How to eliminate wrong answers

Option A is wrong because the Search Head is responsible for search orchestration, knowledge object management, and presenting results; it does not store index buckets. Option C is wrong because the Cluster Master manages the cluster topology, replication, and search factor, but it does not store bucket data. Option D is wrong because the Deployment Server distributes configurations and apps to forwarders and other components; it has no role in storing indexed data.

Practice this question →
16
Multi-Selectmedium

Which TWO are common causes of 'Search Head Cluster' configuration replication failures?

Select 2 answers
A.Incorrect pass4SymmKey on one of the nodes
B.Too many concurrent searches
C.Incorrect license master configuration
D.Mismatch in server names
E.Network firewall blocking port 8089
AnswersA, E

Cluster members authenticate replication traffic using the shared pass4SymmKey secret. A mismatch on any single node prevents that member from joining the replication channel, so configuration bundles never propagate, directly producing the search head cluster replication failures the stem describes.

Why this answer

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.

Exam trap

The trap is selecting performance-related issues (like too many searches) as causes of replication failure, when replication is a separate control-plane process that depends on authentication and network connectivity.

Practice this question →
17
MCQmedium

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?

A.Use the local/ directory for configuration files that should not be replicated
B.Move files to the var/run directory
C.Set the configuration to immutable in server.conf
D.Use the shcluster/ directory
AnswerA

The local directory is specifically ignored by the SHC replication mechanism.

Why this answer

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.

Exam trap

SPLK-2002 often tests whether candidates know that local/ directories are excluded from bundle replication, confusing it with other directories like shcluster/ or var/run.

How to eliminate wrong answers

Option B is wrong because var/run is a runtime directory for process IDs and state files, not a location for configuration that should survive bundle replication. Option C is wrong because setting configurations to immutable in server.conf is not a supported mechanism for protecting local user configurations in a search head cluster. Option D is wrong because there is no shcluster/ directory for configuration; the shcluster directory under $SPLUNK_HOME/etc is used for cluster state, not for user configuration.

Practice this question →
18
MCQmedium

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

A.The new node only receives new data
B.The cluster forces a reindex of all historical data
C.The cluster redistributes buckets only if necessary to meet factors
D.All historical data is immediately copied to the new node
AnswerC

Adding an indexer triggers bucket redistribution solely when replication or search factors are unmet, not automatically. Existing buckets stay put unless the cluster needs to satisfy those factor requirements across peers. This preserves historical data placement while maintaining availability, matching the stem's scenario of a newly added indexer.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that adding a peer triggers automatic full data redistribution, when in reality the cluster only replicates buckets as needed to satisfy RF/SF.

How to eliminate wrong answers

Option A is wrong because it is only partially true — the new peer does receive new data, but the cluster may also replicate existing buckets to it if RF/SF require it. Option B is wrong because the cluster never forces a full reindex of historical data; reindexing is a manual, destructive operation and is not part of peer addition. Option D is wrong because the cluster does not immediately copy all historical data to a new peer; bucket distribution is governed by RF/SF and the CM's bucket assignment logic, not a blanket copy.

Practice this question →
19
MCQeasy

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

A.The License Master
B.The Deployment Server
C.The Search Head
D.The Cluster Master
AnswerA

The license master is the single Splunk instance that holds and distributes licence entitlements to all other members of a clustered deployment. It centralises licence management so peers and search heads do not each require separate licence files, satisfying the central-point requirement.

Why this answer

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.

Exam trap

SPLK-2002 often tests the confusion between the License Master and the Cluster Master, since both are central management components, but only the License Master handles licensing.

How to eliminate wrong answers

Option B (Deployment Server) is wrong because it distributes apps and configurations to forwarders, not licenses. Option C (Search Head) is wrong because search heads consume licenses but do not manage them. Option D (Cluster Master) is wrong because it manages indexer clustering (bucket replication, search affinity) but not licensing.

Practice this question →
20
MCQmedium

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

A.The indexer's role
B.The license server path
C.The search head affinity index
D.The site assignment
AnswerD

Critical for multisite replication logic.

Why this answer

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.

Exam trap

SPLK-2002 often tests the distinction between general clustering attributes (like master_uri, pass4SymmKey) and multisite-specific attributes (like site), causing candidates to choose a generic role or license setting instead of the site assignment.

How to eliminate wrong answers

Option A is wrong because the indexer's role (peer, master, search head) is defined by the clustering configuration and is not the multisite-specific attribute required for joining. Option B is wrong because the license server path is unrelated to site assignment and is configured in server.conf but does not affect cluster joining. Option C is wrong because 'search head affinity index' is not a valid configuration attribute for indexers; search affinity is a search head setting, not an indexer joining requirement.

Practice this question →
21
MCQmedium

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?

A.Configure the search head to use only the originating peer for searches by setting search_factor to 0 and disabling replication.
B.Disable indexer clustering and revert the peers to standalone indexers, then configure the search head to query each indexer directly.
C.Set replication_factor to 1 in the cluster manager's server.conf under [clustering] and push the configuration to all peers.
D.Set the cluster manager to maintenance mode and manually assign buckets to peers using the splunk CLI bucket command.
AnswerB

Indexer clustering inherently replicates buckets across peers to ensure high availability and data recovery. To guarantee that data never leaves the originating peer, you must not use clustering. Reverting to standalone indexers and having the search head query them directly (e.g., via distributed search) ensures each indexer holds only its own data, satisfying the compliance requirement.

Why this answer

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.

Exam trap

The trap here is assuming that replication_factor or search_factor can enforce data locality, when they actually control copy counts and searchable copies, not the physical placement of buckets.

Practice this question →
22
MCQeasy

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

A.Faster indexing performance
B.Reduced license costs
C.Smaller storage footprint
D.High availability of search and user interface
AnswerD

A Search Head Cluster replicates search artefacts and configuration across multiple search head members, so if one member fails another continues serving searches and the user interface. This redundancy provides the high availability that a single search head cannot offer.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that a Search Head Cluster improves indexing or reduces licensing costs, when its actual value is search/UI high availability and horizontal scaling.

How to eliminate wrong answers

Option A is wrong because indexing performance is determined by indexer capacity, not search head architecture — search heads do not index data. Option B is wrong because license costs are based on daily indexed volume and are unaffected by whether you run one search head or a cluster. Option C is wrong because an SHC actually increases storage footprint (each member holds replicated configurations and search artifacts), not reduces it.

Practice this question →
23
MCQhard

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

A.The number of buckets per indexer
B.The number of users
C.Network latency between sites
D.The number of search heads
AnswerC

Searching across all sites requires the search head to dispatch and gather results from indexers in every site, so inter-site network latency directly determines how quickly results return. Higher latency slows cross-site searches more than any other listed factor.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that hardware resources like bucket count or user load are the primary factors in multisite search performance, when in fact network latency between sites is the critical bottleneck for cross-site searches.

How to eliminate wrong answers

Option A is wrong because the number of buckets per indexer affects local disk I/O and bucket replication, but it does not directly determine cross-site search latency; bucket count is more relevant to replication and search efficiency within a site. Option B is wrong because the number of users affects concurrent search load and resource contention, but it is not the primary factor for cross-site search performance; user count impacts overall cluster load, not the inherent latency of multisite searches. Option D is wrong because the number of search heads affects search concurrency and load balancing, but it does not directly influence the latency of searches that must traverse sites; more search heads can improve parallelism but do not reduce network latency between sites.

Practice this question →
24
MCQmedium

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?

A.Site-aware routing
B.Data locality
C.Load balancing
D.Search affinity
AnswerD

Search affinity routes searches to indexers in the same site as the search head, reducing cross-site traffic and latency. This satisfies the requirement to prioritise same-site searches. Other features, such as search head clustering replication or indexer discovery, address availability and distribution, not site-based prioritisation.

Why this answer

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.

Exam trap

The trap here is confusing search affinity with indexer-side site awareness or generic load balancing; candidates pick 'site-aware routing' because it sounds correct, but the SHC feature is specifically named search affinity.

How to eliminate wrong answers

Option A is wrong because 'site-aware routing' is not a Splunk SHC feature name; site awareness exists for indexers and multisite clustering, but the SHC search placement feature is called search affinity. Option B is wrong because data locality is a general concept (keeping compute near data) and is not the specific Splunk SHC configuration knob. Option C is wrong because load balancing distributes searches across SHC members for capacity, not for site proximity to indexers.

Practice this question →
25
MCQeasy

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

A.To handle incoming data from universal forwarders
B.To manage the indexer cluster's configuration and bucket state
C.To serve the Splunk user interface
D.To search across all indexers
AnswerB

The Cluster Master manages the indexer cluster's configuration and bucket state, satisfying the stem's requirement for its primary function. It coordinates replication and search factors, instructs peers on bucket fix-up, and maintains the cluster's overall health, rather than handling search requests or indexing data itself.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that the cluster master handles data ingestion or search, when its primary role is configuration and bucket state management.

How to eliminate wrong answers

Option A is wrong because handling incoming data from universal forwarders is the role of indexers (or heavy forwarders), not the cluster master. Option C is wrong because serving the Splunk user interface is done by the search head, not the cluster master. Option D is wrong because searching across all indexers is performed by the search head, which distributes the search to indexers; the cluster master does not search.

Practice this question →
26
MCQeasy

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

A.A shared SSL certificate
B.A dedicated storage partition
C.A specialized Splunk App
D.The same security key
AnswerD

Every search head cluster member must hold an identical security key, which encrypts and authenticates replication and cluster traffic between members. Without the matching key, a search head cannot join or communicate within the cluster.

Why this answer

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.

Exam trap

SPLK-2002 often tests the distinction between the security key and SSL certificates, as both are security-related and used in cluster communication, but only the security key is mandatory for joining.

How to eliminate wrong answers

Option A is wrong because while SSL certificates are used for secure communication between cluster members, they are not the prerequisite for joining; the security key is the authentication mechanism. Option B is wrong because a dedicated storage partition is not required for cluster membership; Splunk can use any available storage, though best practices recommend separate partitions for performance. Option C is wrong because no specialized Splunk App must be installed on all members before joining; the clustering is configured via built-in settings, not an app.

Practice this question →
27
MCQmedium

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?

A.The data is permanently lost
B.The indexers continue to work normally indefinitely
C.You will be unable to distribute new configuration updates
D.You can restore the configuration from the peer nodes
AnswerC

Without the master-apps backup, the new cluster master cannot recover the configuration bundle that replication distributes to peers. Configuration updates therefore fail to propagate, satisfying the stem's permanent-loss constraint. Peer data and search remain intact, but centralised configuration management is lost until the bundle is rebuilt manually.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that losing the cluster master causes data loss; in reality, data is on peers, and the real loss is the ability to distribute configuration updates.

How to eliminate wrong answers

Option A is wrong because indexed data lives on the peer nodes, not on the master; losing the master does not delete buckets. Option B is wrong because while peers keep running with their cached configuration, they cannot receive new configuration updates, and cluster management functions (fixup, rebalance, peer addition) are impaired. Option D is wrong because peers do not store the authoritative master-apps bundle; they only hold the replicated configuration they received, so you cannot reconstruct the master's full configuration set from them.

Practice this question →
28
MCQhard

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

A.To remove a node from the cluster
B.To update the license configuration
C.To verify the synchronization status of all indexer peers
D.To force a cluster rebalance
AnswerC

The command queries cluster peers and reports each peer's status, including whether it is up, down, or in a degraded replication state. This lets an administrator confirm that all indexer peers are synchronised and actively participating in bucket replication across the cluster.

Why this answer

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.

Exam trap

SPLK-2002 often tests whether candidates know the difference between read-only diagnostic commands (list cluster-peers) and state-changing commands (remove cluster-peers, rebalance cluster-data).

How to eliminate wrong answers

Option A is wrong because removing a node from the cluster is done with 'splunk remove cluster-peers' or by decommissioning, not with list. Option B is wrong because license configuration is managed via license manager commands and the licensing endpoint, not cluster-peers. Option D is wrong because forcing a rebalance is done with 'splunk rebalance cluster-data' or via the master's UI/API, not with list.

Practice this question →
29
Multi-Selecthard

Which THREE factors should be considered when planning the hardware requirements for a multisite indexer cluster?

Select 3 answers
A.Disk I/O throughput
B.The color of the server chassis
C.Inter-site network latency and bandwidth
D.The total number of indexer peers
E.The number of concurrent web users
AnswersA, C, D

Disk I/O throughput directly governs indexing and search performance, since indexers constantly read and write bucket data. In a multisite cluster, replication and searchable copy factors multiply this load across sites, so sustained throughput per indexer must be sized against peak ingest plus inter-site replication traffic.

Why this answer

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.

Exam trap

SPLK-2002 often tests the confusion between indexer hardware factors and search head or user-related factors, tempting candidates to select user count as a hardware consideration for indexers when it is not a primary driver.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Deployment Architecture And Clustering questions.

Start 20-question session