CCNA High Availability And Distributed Search Questions

MCQmedium

When adding a new indexer to an existing Indexer Cluster, what is the best practice to ensure the indexer is ready before it starts receiving data?

A.Start the splunk service and wait for the CM to acknowledge registration.

B.Set the indexer to maintenance mode.

C.Manually copy index buckets from other peers.

D.Restart all existing peers.

E.Add the indexer to the indexer discovery list.

AnswerA

The peer must complete the handshake with the CM to be active.

Why this answer

When adding a new indexer to an existing cluster, the correct procedure is to install and configure the indexer with the cluster master's address and the peer replication/search ports, then start the splunkd service and wait for the CM to acknowledge the peer's registration. Only after the CM registers the peer and begins streaming the cluster bundle and replicating buckets should the indexer be considered ready to receive data. This ensures the peer has the correct configuration and bucket state before participating in search and replication.

Exam trap

SPLK-2002 often tests whether candidates know the correct onboarding sequence for a new indexer peer — specifically that the CM must acknowledge registration before the peer is considered ready — versus disruptive or manual workarounds like copying buckets or restarting peers.

How to eliminate wrong answers

Option B is wrong because maintenance mode is used to temporarily stop a peer from receiving new data or participating in searches — it is not a step for onboarding a new peer. Option C is wrong because manually copying index buckets from other peers bypasses the cluster's replication mechanism and can corrupt bucket metadata or violate replication/search factor guarantees. Option D is wrong because restarting all existing peers is disruptive and unnecessary; the CM handles peer onboarding without cluster-wide restarts.

Option E is wrong because indexer discovery is a forwarder-side mechanism for finding indexers, not a step for registering a new peer with the cluster master.

Practice this question →

MCQeasy

Which component is responsible for distributing configuration bundles to indexers in a cluster?

A.Deployment Server

B.Cluster Master

C.License Master

D.Indexer Peer

E.Search Head

AnswerB

The Cluster Master distributes configuration bundles to peer nodes, satisfying the requirement for centralised configuration management across the indexer cluster. It coordinates bundle replication, pushing updated configurations to indexers and triggering restarts when needed. This role is unique to the Cluster Master, distinguishing it from search heads and licence managers.

Why this answer

In an indexer cluster, the Cluster Master (now Cluster Manager) is responsible for distributing configuration bundles to the indexers (peers). It coordinates the application of configuration changes and ensures that all peers receive the latest bundle. The Deployment Server is used for standalone Splunk instances, not for indexer clusters.

Exam trap

The trap is confusing the Deployment Server with the Cluster Master — candidates may think the Deployment Server distributes configurations to all Splunk components, but in an indexer cluster, the Cluster Master is responsible for bundle distribution.

How to eliminate wrong answers

Option A is wrong because the Deployment Server is used to distribute configurations to universal forwarders and other standalone Splunk instances, not to indexer cluster peers; indexer clusters use the cluster master for bundle distribution. Option C is wrong because the License Master manages licensing and does not distribute configuration bundles. Option D is wrong because an Indexer Peer receives configuration bundles but does not distribute them to other peers.

Option E is wrong because a Search Head is not involved in distributing configuration bundles to indexers; search heads may receive bundles from the cluster master in a search head cluster, but that is a different context.

Practice this question →

MCQmedium

A Splunk architect is deploying an Indexer Cluster with site awareness. The cluster has three sites: site1, site2, and site3. The replication factor is 3, and the search factor is 2. The architect wants to ensure that searchable copies are distributed across sites for high availability. Which of the following configurations should be applied?

A.Set site_replication_factor to origin:1, total:3 and site_search_factor to origin:1, total:2.

B.Set site_replication_factor to origin:1, total:2 and site_search_factor to origin:1, total:2.

C.Set site_replication_factor to origin:2, total:3 and site_search_factor to origin:2, total:3.

D.Set site_replication_factor to origin:1, total:1 and site_search_factor to origin:1, total:1.

AnswerA

This configuration ensures that each bucket has one copy at its origin site and a total of three copies across all sites, meaning one copy in each of the three sites. The search factor of origin:1, total:2 ensures that at least one searchable copy exists at the origin site and a total of two searchable copies across sites, providing high availability for searches.

Why this answer

To distribute searchable copies across three sites with a replication factor of 3 and search factor of 2, you set site_replication_factor to origin:1, total:3 and site_search_factor to origin:1, total:2. This ensures one copy per site and at least two searchable copies across sites.

Exam trap

The trap here is setting the total replication factor to match the number of sites without considering the search factor, or setting origin copies too high, which can cause uneven distribution.

Practice this question →

MCQeasy

What is the recommended method to distribute configuration changes across a Search Head Cluster?

A.Using the Deployment Server.

B.Updating the captain only.

C.Using the 'splunk apply shcluster-bundle' command.

D.Manual file copying to each node.

E.Using a shared network drive.

AnswerC

The splunk apply shcluster-bundle command pushes a configuration bundle from the deployer to all cluster members, restarting search heads as needed. This is the supported mechanism for distributing configuration changes across a Search Head Cluster, satisfying the stem's requirement.

Why this answer

The recommended method to distribute configuration changes across a Search Head Cluster is to use the 'splunk apply shcluster-bundle' command from the deployer. This command pushes the configuration bundle to all members, ensuring consistency and leveraging the cluster's built-in replication and restart mechanisms.

Exam trap

SPLK-2002 often tests the confusion between the Deployment Server (for forwarders) and the deployer (for SHC), causing candidates to select the Deployment Server as the distribution method for SHC configuration.

How to eliminate wrong answers

Option A is wrong because the Deployment Server is used for forwarders and non-clustered components, not for SHC members; using it on SHC members is unsupported. Option B is wrong because updating only the captain does not propagate changes to other members; the captain is not a configuration master in that sense. Option D is wrong because manual file copying is error-prone, unsupported, and bypasses the cluster's consistency checks.

Option E is wrong because a shared network drive is not a supported distribution method and can cause file locking and consistency issues.

Practice this question →

MCQeasy

In an Indexer Cluster, what is the primary role of the Cluster Master (CM) regarding bucket management?

A.Directing search requests to specific indexers.

B.Indexing incoming forwarder data.

C.Maintaining the bucket registry and managing replication status.

D.Storing raw data and serving search requests.

E.Aggregating search results from indexers.

AnswerC

The Cluster Master coordinates bucket replication across peer indexers, tracking which buckets exist, their searchable and replicated states, and triggering fixes when copies fall short. This registry function is what maintains the replication factor the cluster promises.

Why this answer

The Cluster Master (now called Cluster Manager in newer Splunk versions) maintains the bucket registry — the authoritative map of which buckets exist, their states (hot/warm/cold), and their replication status across peer indexers. It coordinates replication and searchability but does not index data or serve searches itself.

Exam trap

SPLK-2002 often tests the confusion between the Cluster Master's coordination role and the peer indexers' data storage/indexing role — candidates pick 'storing raw data' or 'directing searches' because those sound like central functions, but they belong to peers and search heads respectively.

How to eliminate wrong answers

Option A is wrong because directing search requests to specific indexers is the role of the search head (and its search head cluster captain), not the Cluster Master. Option B is wrong because indexing incoming forwarder data is performed by peer indexers, not the CM — the CM does not index. Option D is wrong because storing raw data and serving search requests is the role of peer indexers (and search heads for search), not the CM.

Option E is wrong because aggregating search results from indexers is done by the search head, not the CM.

Practice this question →

Multi-Selecthard

Which THREE of the following are risks if the replication_factor is too low?

Select 3 answers

A.Slower indexing speed.

B.Data loss if an indexer fails.

C.Inability to meet search factor requirements.

D.Increased downtime during peer maintenance.

E.Higher CPU usage on the CM.

AnswersB, C, D

A low replication_factor means fewer searchable copies exist across indexers, so a single indexer failure can leave some buckets with no surviving replica, causing permanent loss of that indexed data. This directly satisfies the stem's data-loss risk, since replication is the mechanism protecting against indexer failure.

Why this answer

In Splunk indexer clustering, replication_factor determines how many copies of each bucket are maintained across peer nodes, so setting it too low directly creates availability and durability risks. Option B is correct because with a low replication_factor there are fewer bucket copies than needed to tolerate failures, so if an indexer (peer) holding a copy fails, buckets can be lost or go missing until recovered. Option C is correct because the search factor (number of searchable copies) can never exceed the replication_factor; if replication_factor is set below the desired search factor, the cluster cannot meet its search factor requirements.

Option D is correct because with minimal replicas, taking a peer offline for maintenance removes a copy and can push buckets below the replication factor, causing degraded search availability and longer downtime while the cluster re-replicates or recovers. Option A is not correct because indexing speed is not directly governed by replication_factor in this way, and Option E is not correct because the cluster manager's CPU usage is not a defined risk of a low replication_factor.

Exam trap

SPLK-2002 often tests the misconception that replication_factor affects indexing performance or master CPU load, when it actually governs fault tolerance and searchability constraints (SF <= RF).

Practice this question →

Multi-Selectmedium

Which TWO of the following are features of the Indexer Cluster Master?

Select 2 answers

A.Performing data parsing.

B.Managing bucket replication.

C.Authenticating users.

D.Monitoring indexer health.

E.Routing search results to users.

AnswersB, D

Bucket replication is a master-level function: the master coordinates replication of buckets across peer indexers, instructing peers to copy and search replicated data. This satisfies the stem's requirement for a genuine Indexer Cluster Master feature, distinct from search head or peer responsibilities.

Why this answer

Option B is correct because the Indexer Cluster Master coordinates bucket replication across peer indexers, managing the replication factor and ensuring each bucket is copied to the required number of peers. Option D is correct because the Master continuously monitors the health of peer indexers, tracking which peers are up or down and handling their status within the cluster. Option A is incorrect because data parsing is performed by indexers (and heavy forwarders), not by the cluster master.

Option C is incorrect because user authentication is handled by the search head or an external authentication system, not the indexer cluster master. Option E is incorrect because routing search results to users is a function of the search head, not the cluster master.

Exam trap

SPLK-2002 often tests the distinction between the roles of the cluster master, indexers, and search heads, causing candidates to confuse data parsing (indexer) or user authentication (search head) with cluster master responsibilities.

Practice this question →

Multi-Selecteasy

Which THREE of the following are key components of a disaster recovery plan for Splunk?

Select 3 answers

A.Off-site storage of frozen buckets.

B.Regular backup of the etc/ directory.

C.Increasing the replication factor.

D.Documented restoration procedures.

E.Continuous indexing of all data.

AnswersA, B, D

Frozen buckets are the archived, read-only index data moved to cheaper storage. Keeping copies off-site protects that indexed data from site-wide loss such as fire or flood, directly satisfying the disaster recovery plan's need for recoverable data at a separate location.

Why this answer

Option A is correct because frozen buckets are the archived, long-term data that must be preserved off-site so that after a disaster the indexed data can be restored and re-thawed or searched via a separate archive indexer. Option B is correct because the etc/ directory holds all critical Splunk configuration — indexes.conf, props.conf, transforms.conf, server.conf, authentication, and apps — and a regular backup of it is essential to rebuild the deployment. Option D is correct because a DR plan is only effective if it includes documented, tested restoration procedures that specify the order of recovery (license master, indexers, search heads) and the exact steps to restore buckets and configurations.

Option C is not a DR component; replication factor is a data-availability setting within a cluster and does not by itself constitute a disaster recovery plan. Option E is not a DR component either; continuously indexing all data is a normal ingestion practice, not a recovery mechanism, and it does not address restoring service after a disaster.

Exam trap

SPLK-2002 often tests whether candidates confuse operational resilience features (replication factor, continuous indexing) with actual DR plan components (off-site archives, etc/ backups, documented procedures), so options C and E are planted as plausible but incorrect choices.

Practice this question →

MCQeasy

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

A.To secure the communication between cluster nodes.

B.To define the replication factor.

C.To authorize search head access.

D.To manage indexer licensing.

E.To encrypt data in flight.

AnswerA

The cluster secret is the shared credential that authenticates inter-node traffic, so every peer and indexer must present it before joining replication or search traffic. It therefore secures node-to-node communication across the cluster, satisfying the stem's requirement for the secret's primary function.

Why this answer

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.

Exam trap

SPLK-2002 often tests the confusion between authentication (Cluster Secret) and encryption (SSL/TLS certificates), leading candidates to pick 'encrypt data in flight' when asked about the Cluster Secret's primary function.

How to eliminate wrong answers

Option B is wrong because the replication factor is defined by the `replication_factor` attribute in the `[clustering]` stanza, not by the Cluster Secret. Option C is wrong because search head authorization to the indexer cluster is controlled by the search head's own `pass4SymmKey` matching the cluster's secret plus the `[clustering]` mode settings, not by the secret's primary function. Option D is wrong because licensing is managed by the license master and license pool configuration, entirely unrelated to the Cluster Secret.

Option E is wrong because encryption of data in flight is handled by SSL/TLS certificates (`serverCert`, `sslConfig`), not by the Cluster Secret, which only provides authentication.

Practice this question →

Multi-Selecteasy

Which TWO of the following are valid ways to monitor the status of an Indexer Cluster?

Select 2 answers

A.Checking the license usage logs.

B.Using the CLI command 'splunk show cluster-status'.

C.Using the Monitoring Console.

D.Reviewing the forwarder logs.

E.Running a search on the indexers directly.

AnswersB, C

Running 'splunk show cluster-status' on a cluster member returns replication and search-factor compliance, peer counts and any ongoing fixup. It satisfies the stem by giving a supported CLI method to monitor indexer cluster health directly from a node.

Why this answer

Option B is correct because the Splunk CLI command 'splunk show cluster-status' (run on a cluster manager or member) reports the health and status of the indexer cluster, including peer and search head connectivity and replication status. Option C is correct because the Monitoring Console provides a dedicated Indexer Clustering dashboard that surfaces cluster health, peer status, replication and search factor compliance, and bucket-fixup activity. Option A is incorrect because license usage logs track license consumption, not cluster health or peer status.

Option D is incorrect because forwarder logs show data forwarding activity and connectivity from the forwarder's perspective, not the status of the indexer cluster itself. Option E is incorrect because running a search on indexers tests search functionality but does not provide a valid, supported method for monitoring overall indexer cluster status.

Exam trap

SPLK-2002 often tests the confusion between cluster monitoring and other monitoring tasks like license usage or forwarder health, leading candidates to select irrelevant options.

Practice this question →

MCQhard

A Splunk architect is designing a Search Head Cluster (SHC) with five members. The customer requires that searches continue to run even if the captain is unavailable. Which of the following best describes the captain election process and the impact on search activity?

A.The captain is elected by the cluster manager; if the captain fails, the cluster manager appoints a new captain, and searches are paused until the appointment.

B.The captain is a static role assigned during SHC initialization; if it fails, an administrator must manually promote a new captain before searches can resume.

C.The captain is elected by the license manager; if the captain fails, the license manager designates a new captain, and searches continue only on the new captain.

D.The captain is elected by a majority vote of all members; if the captain fails, a new election occurs, and searches continue uninterrupted.

AnswerD

The captain is elected by a majority of SHC members using a consensus protocol. If the captain becomes unavailable, the remaining members detect the failure and hold a new election. During this brief period, searches can still be dispatched because search heads operate independently for search execution; only configuration replication is paused until a new captain is elected.

Why this answer

The captain is elected by a majority of SHC members. If it fails, a new election occurs, and searches continue because each search head can independently dispatch searches. Configuration replication pauses briefly but does not affect search execution.

Exam trap

The trap here is confusing the SHC captain with the Indexer Cluster manager or assuming that search execution depends on the captain.

Practice this question →

MCQhard

If an Indexer Cluster has a replication_factor of 3 and search_factor of 2, how many searchable copies of a bucket are maintained across the cluster?

A.5

B.2

C.4

D.1

E.3

AnswerB

The search_factor of 2 directly determines how many searchable copies of each bucket the cluster maintains, satisfying the stem's stated search_factor constraint. Replication_factor governs total copies (3), not searchable ones, so it is irrelevant here. Microsoft Entra ID plays no role in Splunk indexer replication.

Why this answer

In an Indexer Cluster, the search_factor defines how many searchable copies of each bucket are maintained across the cluster. With a search_factor of 2, exactly two searchable copies of each bucket exist. The replication_factor (3) determines the total number of copies (searchable plus non-searchable), but the search_factor specifically governs searchable copies.

Exam trap

SPLK-2002 often tests whether candidates confuse replication_factor (total copies) with search_factor (searchable copies) — the trap is selecting the replication_factor value when the question explicitly asks for searchable copies.

How to eliminate wrong answers

Option A is wrong because 5 is the sum of replication_factor and search_factor, which has no meaning in Splunk's cluster model — the factors are not additive. Option C is wrong because 4 is not derived from either factor; it might be confused with replication_factor plus one, but that's not a Splunk concept. Option D is wrong because 1 would mean only a single searchable copy, which would provide no search redundancy and contradicts the search_factor of 2.

Option E is wrong because 3 is the replication_factor (total copies), not the search_factor — the question specifically asks for searchable copies.

Practice this question →

Multi-Selectmedium

Which THREE of the following are common causes for a Search Head Cluster member to lose contact with the captain?

Select 3 answers

A.Service load is too high causing timeouts.

B.License master is offline.

C.The indexer cluster is busy.

D.Network instability.

E.Replication port is blocked by firewall.

AnswersA, D, E

Excessive search load starves the captain heartbeat, so the member's periodic captain communication times out and it drops out of the cluster. This satisfies the stem's timeout constraint directly: resource contention, not network failure, breaks captain contact.

Why this answer

Option A is correct because a Search Head Cluster member under excessive service load can fail to respond to the captain's periodic heartbeats within the configured timeout, causing the captain to mark it as down and lose contact. Option D is correct because network instability (packet loss, latency, or intermittent connectivity) disrupts the heartbeat and replication traffic between members and the captain, breaking the cluster communication. Option E is correct because the captain and members communicate over the replication port (default 9887), so if a firewall blocks that port, the member cannot exchange heartbeats or replicate artifacts and loses contact with the captain.

Option B is not a cause because the license master is unrelated to SHC captain heartbeat communication; a member can remain in contact with the captain even if licensing is unavailable. Option C is not a cause because indexer cluster load affects search and indexing performance, not the SHC internal captain-member heartbeat channel.

Exam trap

SPLK-2002 often tests the distinction between SHC internal communication (captain heartbeats on port 9887) and external dependencies (license master, indexer cluster), tricking candidates into selecting irrelevant options like license master offline.

Practice this question →

MCQmedium

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

A.Ignore the peer and wait for timeout.

B.Delete the indexer's data directory manually.

C.Update the master node configuration.

D.Shutdown the service without notice.

E.Use the 'splunk offline' command on the peer.

AnswerE

Running 'splunk offline' triggers graceful shutdown, letting the peer flush buckets and transfer primary copies to other peers before leaving the cluster. This satisfies the stem's requirement for handling a permanently failing peer, since the cluster rebalances replication and search factor without data loss.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that a failing peer can simply be ignored or manually cleaned up, when the supported procedure is the graceful 'splunk offline' command that preserves cluster replication factors.

How to eliminate wrong answers

Option A is wrong because ignoring the peer and waiting for timeout leaves the cluster in a degraded state and delays bucket fixup, risking data unavailability. Option B is wrong because manually deleting the indexer's data directory bypasses cluster coordination and can cause data loss or inconsistent bucket states. Option C is wrong because updating the master node configuration does not remove a failing peer; the peer must be taken offline through the proper command.

Option D is wrong because shutting down the service without notice skips the graceful flush and notification, potentially leaving buckets in a non-searchable state and forcing the CM to perform fixup without proper handoff.

Practice this question →

MCQeasy

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

A.splunk cluster-check

B.splunk show cluster-status

C.splunk inspect-cluster

D.splunk search-peers

E.splunk list indexers

AnswerB

Running splunk show cluster-status on the Cluster Master returns cluster health, including replication and search factor status and peer availability. This directly satisfies the stem's constraint of checking Indexer Cluster health from the Cluster Master CLI rather than the monitoring console.

Why this answer

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.

Exam trap

The trap is confusing similar-sounding commands — candidates may pick 'splunk cluster-check' or 'splunk inspect-cluster' because they sound plausible, but the correct command is 'splunk show cluster-status'.

How to eliminate wrong answers

Option A is wrong because 'splunk cluster-check' is not a valid Splunk CLI command. Option C is wrong because 'splunk inspect-cluster' is not a valid command. Option D is wrong because 'splunk search-peers' is not a valid command for checking cluster health.

Option E is wrong because 'splunk list indexers' is not a valid command; while there are commands to list peers, the standard health check command is show cluster-status.

Practice this question →

MCQhard

You notice that your indexer cluster has 'Streaming' buckets that are not yet searchable. What is the most likely cause?

A.The indexer is in maintenance mode.

B.The indexer disk is full.

C.The license is expired.

D.The search factor is not met for these buckets.

E.The Cluster Master is down.

AnswerD

Streaming buckets hold replicated raw data that becomes searchable only once the search factor is satisfied, meaning enough searchable copies exist across peer nodes. Until that replication completes, the bucket remains non-searchable, so an unmet search factor is the cause.

Why this answer

In an indexer cluster, a bucket transitions from 'streaming' to 'searchable' only after the search factor (SF) is satisfied — meaning the required number of searchable copies exist across peers. If SF is not met (e.g., a peer holding a searchable copy is down), the bucket remains in the streaming state and cannot be searched. This is the canonical cause of 'streaming buckets not yet searchable' in Splunk clustering.

Exam trap

SPLK-2002 often tests the distinction between replication factor and search factor — candidates pick 'disk full' or 'CM down' because those sound like cluster-wide failures, but the specific symptom 'streaming not searchable' maps only to unmet SF.

How to eliminate wrong answers

Option A is wrong because maintenance mode on an indexer primarily affects its ability to receive new data and participate in fixups, but it doesn't directly define the streaming-to-searchable transition — SF satisfaction does. Option B is wrong because a full disk triggers bucket freezing/rollover and indexing pauses, not a persistent 'streaming but not searchable' state. Option C is wrong because an expired license blocks new indexing entirely rather than leaving buckets stuck in streaming.

Option E is wrong because if the Cluster Master is down, existing searchable buckets remain searchable; only new bucket replication and fixup operations stall.

Practice this question →

MCQmedium

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

A.To act as the Cluster Master for indexers.

B.To store all bucket data for the indexers.

C.To receive data from forwarders.

D.To distribute search results to the end user.

E.To coordinate search scheduling and replicate configuration bundles.

AnswerE

The captain is the elected Search Head Cluster member that runs the scheduler and replicates configuration bundles to peers, satisfying the stem's coordination requirement. This centralises search artefact distribution while other members handle user searches, with re-election on failure.

Why this answer

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.

Exam trap

SPLK-2002 often tests the confusion between the roles of Cluster Master (for indexers) and Captain (for search head clusters), leading candidates to pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because the Cluster Master is a separate role for indexer clusters, not search head clusters. Option B is wrong because bucket data is stored on indexers, not on the search head cluster captain. Option C is wrong because receiving data from forwarders is the role of indexers or heavy forwarders, not the search head cluster captain.

Option D is wrong because distributing search results to end users is handled by the search head that initiated the search, not specifically the captain.

Practice this question →

MCQeasy

Which type of bucket is used for the most recent data and is generally searchable?

A.Warm

B.Cold

C.Frozen

D.Thawed

E.Hot

AnswerE

Hot buckets hold the most recent, actively written data and remain searchable, satisfying the stem's requirement for current, queryable events. As data ages it rolls to warm, then cold, then frozen, which are slower or archival, so only hot meets both the recency and searchability constraints.

Why this answer

Hot buckets contain the most recent, actively written data and are the only bucket type that is both writable and searchable in real time. When data ages or reaches a size threshold, hot buckets roll to warm, which are searchable but no longer written to. Therefore hot is the correct answer for 'most recent data and generally searchable.'

Exam trap

SPLK-2002 often tests bucket lifecycle ordering and searchability; candidates confuse 'warm' as the most recent because it is the first rolled bucket, but hot is the actively written, most recent bucket.

How to eliminate wrong answers

Option A is wrong because warm buckets contain older data that has already rolled from hot; they are searchable but are not the most recent. Option B is wrong because cold buckets hold even older data, are searchable but slower, and are candidates for archiving. Option C is wrong because frozen buckets are archived or deleted data that is no longer searchable unless thawed.

Option D is wrong because thawed buckets are restored from archive (frozen) and are searchable but are not the most recent data.

Practice this question →

MCQhard

What happens to a search job if the Search Head Cluster captain goes down during an active search?

A.The search head cluster becomes read-only.

B.Indexers stop processing data.

C.A new captain is elected and search jobs are recovered.

D.The entire cluster must be restarted.

E.The search job is canceled immediately.

AnswerC

Search Head Cluster members maintain replicated search artefacts and the captain role is elected dynamically. When the captain fails, a new captain is elected and in-flight search jobs are recovered from replicated state, so searches continue rather than being lost.

Why this answer

In a Search Head Cluster, the captain is a dynamically elected member that coordinates configuration replication and search scheduling. If the captain goes down, a new captain is elected from the remaining members, and active search jobs are recovered and continue. This provides high availability and fault tolerance.

Exam trap

The trap is thinking that the loss of the captain halts all searches or requires a restart, but the cluster is designed for automatic failover and job recovery.

How to eliminate wrong answers

Option A is wrong because the search head cluster does not become read-only; it continues to operate with a new captain. Option B is wrong because indexers are independent of the search head cluster captain; they continue processing data. Option D is wrong because a full cluster restart is not required; the cluster is designed for automatic failover.

Option E is wrong because search jobs are not canceled; they are recovered by the new captain.

Practice this question →

MCQmedium

What is the effect of setting 'forwarder_site_failover=true' in the indexer discovery stanza?

A.It mandates the use of SSL.

B.It increases the replication factor.

C.Forwarders will stop sending data if the local site is down.

D.Forwarders can failover to indexers in another site.

E.The indexer discovery service is disabled.

AnswerD

Setting `forwarder_site_failover=true` lets universal forwarders switch to indexers in a different site when their local site's indexers become unavailable, satisfying the cross-site resilience requirement. Indexer discovery normally restricts forwarders to their own site; this parameter overrides that restriction, enabling failover across sites during an outage.

Why this answer

Setting `forwarder_site_failover=true` in the indexer discovery stanza enables forwarders to send data to indexers in another site if the local site's indexers are unavailable. This provides site-level redundancy and ensures data continues to flow during a site outage.

Exam trap

SPLK-2002 often tests the confusion between site failover and other settings like SSL or replication factor, leading candidates to select options that are unrelated to the failover behavior.

How to eliminate wrong answers

Option A is wrong because SSL usage is controlled by `sslCertPath` and `sslPassword` settings, not by `forwarder_site_failover`. Option B is wrong because the replication factor is a cluster-level setting on the indexer cluster, not affected by forwarder site failover. Option C is wrong because the setting enables failover, not stops data; forwarders will attempt to send to other sites.

Option E is wrong because indexer discovery remains enabled; this setting only controls failover behavior.

Practice this question →

MCQhard

When using a load balancer in front of a search head cluster, why is session affinity (sticky sessions) recommended?

A.To increase the replication speed.

B.To prevent unauthorized access.

C.To improve indexing performance.

D.To maintain session persistence and search job state.

E.To reduce the number of license tokens.

AnswerD

Sticky sessions bind each client to one cluster member via the load balancer, so the search job's artefacts and replication state remain on that node. Without affinity, subsequent requests could hit another member lacking the job's state, breaking search continuity.

Why this answer

Session affinity (sticky sessions) ensures that all requests from a given client are routed to the same search head for the duration of a session. In a Splunk search head cluster, search jobs and their artifacts (results, job state, dispatch directory) are stored locally on the search head that initiated the job. If a subsequent request lands on a different search head, that node has no knowledge of the job, causing errors or lost results.

Sticky sessions preserve the mapping between the client and the search head that owns the job.

Exam trap

The trap is confusing session affinity with high availability or load distribution — candidates may think sticky sessions improve performance or security, when the real reason is preserving search job state on a specific search head.

How to eliminate wrong answers

Option A is wrong because replication speed is determined by the replication factor and network bandwidth between cluster members, not by load balancer session affinity. Option B is wrong because preventing unauthorized access is the job of authentication and authorization mechanisms (LDAP, SAML, RBAC), not session affinity. Option C is wrong because indexing performance is handled by indexers and is unrelated to how the load balancer distributes search head traffic.

Option E is wrong because license token consumption is governed by daily indexing volume and license configuration, not by session affinity.

Practice this question →

MCQhard

When configuring search affinity for a multi-site cluster, what is the behavior if no indexers are available in the local site?

A.The search fails immediately.

B.The search head queries indexers in other sites.

C.The search head waits for the local indexer to return.

D.The search head only returns partial results.

E.The search head reports an error to the user.

AnswerB

Search affinity prefers local-site indexers, but when none are available the search head falls back to indexers in other sites rather than failing. This preserves search availability across the multi-site cluster, satisfying the stem's scenario of local-site unavailability.

Why this answer

In a Splunk multi-site cluster, search affinity is a performance optimization that prefers indexers in the same site as the search head to reduce latency and WAN traffic. However, it is not a hard constraint: if no indexers in the local site are available (e.g., all are down, busy, or in maintenance mode), the search head automatically falls back to querying indexers in other sites. This ensures search continuity and availability, which is a core design goal of Splunk's distributed search architecture.

Exam trap

SPLK-2002 often tests the misconception that search affinity is a strict requirement, leading candidates to incorrectly choose options that suggest search failure or waiting, when in fact Splunk automatically falls back to remote sites.

How to eliminate wrong answers

Option A is wrong because search affinity is a preference, not a requirement; Splunk is designed for high availability and will not fail a search simply because local indexers are unavailable. Option C is wrong because the search head does not block or wait indefinitely for local indexers to return; it actively redirects the search to remote sites to avoid delays. Option D is wrong because the search head does not return partial results; it queries remote indexers to retrieve the complete result set.

Option E is wrong because no error is reported to the user; the fallback to remote sites is transparent and automatic.

Practice this question →