SPLK-2002 Practice Test 3 — 30 Questions

Question 1

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

Accepted Answer

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

Answer

It acts as the primary user interface node

Answer

It stores all the search results

Answer

It performs all the searches for the cluster

Question 2

When managing indexer clustering, what is the impact of a high 'replication_factor' on indexing performance?

Accepted Answer

Increases indexing latency due to synchronous replication requirements. A high replication_factor means each bucket must be replicated to more indexer peers before the data is considered safely indexed. Because replication is synchronous for hot buckets in an indexer cluster, the indexing pipeline waits for acknowledgments from all required peers, increasing indexing latency. This is the direct performance impact.

Answer

Allows for faster data ingestion without resource constraints

Answer

Improves search speed by reducing data density

Answer

Decreases indexer storage requirements

Question 3

An Indexer Cluster is in 'Maintenance Mode'. Which THREE of the following implications must be considered during this time?

Accepted Answer

The peers will continue to index incoming data normally. In Splunk maintenance mode, option A is correct because the indexer peers keep indexing incoming data normally; maintenance mode only suppresses certain master-level activities, not data ingestion. Option B is correct because the cluster master stops alerting on missing buckets, so replication/primacy violations are not reported during this window. Option E is correct because the master also halts bucket fix-up activities, meaning it will not attempt to search for and replicate or restore missing bucket copies. Option C is wrong because the master does not force an immediate bucket re-balance in maintenance mode; rebalancing is a separate, manual operation. Option D is wrong because searches are not automatically disabled by maintenance mode; search functionality continues unless separately restricted.

Answer

The Master will force a bucket re-balance immediately

Answer

All searches will be automatically disabled

Question 4

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

Accepted Answer

A new captain is elected and search jobs are recovered.. 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.

Answer

The search head cluster becomes read-only.

Answer

Indexers stop processing data.

Answer

The entire cluster must be restarted.

Answer

The search job is canceled immediately.

Question 5

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

Accepted Answer

The search head queries indexers in other sites.. 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.

Answer

The search fails immediately.

Answer

The search head waits for the local indexer to return.

Answer

The search head only returns partial results.

Answer

The search head reports an error to the user.

Question 6

You are troubleshooting a configuration bundle replication issue in an Indexer Cluster. The peers are not receiving the latest configuration from the Master. What is the first thing you should check on the Cluster Master?

Accepted Answer

splunk validate cluster-bundle. When peers are not receiving the latest configuration bundle, the first diagnostic step on the Cluster Master is to validate the bundle with 'splunk validate cluster-bundle'. This command checks the bundle for syntax errors, invalid configurations, or missing files before it is pushed to peers, and it reports exactly what is wrong so you can fix the source rather than guessing.

Answer

Check the replication_port

Answer

Restart the Master

Answer

Check /etc/apps for errors

Question 7

What is the purpose of the 'homePath.maxDataSizeMB' setting in indexes.conf?

Accepted Answer

Limits the total size of all hot/warm buckets in the homePath. homePath.maxDataSizeMB sets the maximum total size, in megabytes, of all hot and warm buckets stored in the index's homePath. When this limit is reached, Splunk rolls the oldest warm buckets to the coldPath to free space, making it a retention and capacity control for the homePath volume.

Answer

Sets the maximum size of a single hot bucket

Answer

Limits the number of buckets to 100

Answer

Sets the size limit for the cold path

Question 8

Which TWO items are stored in the index directory?

Accepted Answer

TSIDX files. In Splunk, the index directory (e.g., $SPLUNK_HOME/var/lib/splunk/defaultdb/db) stores the indexed data itself, which includes both the rawdata files (compressed journal slices) and the TSIDX files that hold the time-series index used to locate events quickly, so options B and C are correct. TSIDX files map timestamps and terms to the rawdata slices, and the rawdata files are the compressed, bucket-organized copies of the ingested events. License master keys are not stored in the index directory; they are managed by the license manager (in $SPLUNK_HOME/etc/licenses or the license pool configuration). Search logs are written to $SPLUNK_HOME/var/log/splunk (e.g., search.log per search job), not the index directory. App configuration files live under $SPLUNK_HOME/etc/apps (and related etc directories), not in the index storage.

Answer

License master keys

Answer

Search logs

Answer

App configuration files

Question 9

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?

Accepted Answer

2. 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.

Answer

5

Answer

4

Answer

1

Answer

3

Question 10

Which THREE components are part of the Splunk index directory structure?

Accepted Answer

coldPath. In Splunk's indexes.conf, each index defines three path settings that make up its on-disk directory structure: coldPath (B), homePath (D), and thawedPath (E). homePath holds the hot and warm buckets (the newly written, actively searchable data), coldPath stores buckets that have rolled from warm to cold, and thawedPath is where archived buckets are restored when an admin runs the rebuild command to bring them back online. These three are the actual configurable path attributes of an index, so B, D, and E are correct. The other options are not valid index path settings: hotPath (A) and warmPath (C) do not exist as separate configuration keys because hot and warm buckets both reside under homePath, so they are not part of the index directory structure.

Answer

hotPath

Answer

warmPath

Question 11

When tuning search performance, what is the 'join' command's primary drawback in terms of resource usage?

Accepted Answer

It consumes significant memory on the search head. The join command in Splunk loads the entire subsearch result set into memory on the search head and holds it while matching against the main search results. This in-memory hash/merge operation is memory-intensive and can trigger search head memory pressure or the subsearch result limit. That memory cost on the search head is the command's primary resource drawback.

Answer

It requires data to be fully ingested before searching

Answer

It causes high disk I/O on the indexer

Answer

It disables parallel processing

Question 12

A Splunk architect is calculating the storage requirement for an index that receives 500GB of raw data per day, with a 30-day retention period and a standard 50% compression ratio. If the raw data volume doubles, how should the retention period be modified to maintain the original storage footprint?

Accepted Answer

Decrease retention to 15 days. If the raw data volume doubles, to maintain the same storage footprint, the retention period must be halved. Originally, 500GB/day for 30 days with 50% compression yields a certain storage size. Doubling the daily volume to 1000GB/day means you can only retain half as many days for the same total storage. Thus, retention should decrease to 15 days.

Answer

Keep retention at 30 days

Answer

Decrease retention to 7 days

Answer

Increase retention to 60 days

Question 13

When upgrading a cluster, you have successfully upgraded the Master. Now you are moving to the Indexer Peers. What is the recommended order for upgrading the peers?

Accepted Answer

One by one, ensuring the cluster returns to a healthy state before moving to the next. Splunk's documented rolling upgrade procedure for indexer clusters requires upgrading peers one at a time (or in small batches), waiting for the cluster to return to a healthy state (all buckets searchable, replication and search factors met) before proceeding to the next peer. This preserves data availability and prevents search failures during the upgrade window. The Master must be upgraded first, then peers, then search heads.

Answer

The peers must be upgraded before the Master

Answer

Half the cluster, then the other half

Answer

All peers at once

Question 14

An indexer cluster is suffering from 'bucket repair' loops. What is the most likely cause related to the bucket lifecycle?

Accepted Answer

Bucket corruption preventing indexer recovery. Bucket repair loops in an indexer cluster occur when the cluster master repeatedly attempts to fix or replicate a bucket that cannot reach a healthy state, usually because the bucket's data files are corrupted on disk. Corruption prevents the indexer from validating the bucket checksum, so the master keeps triggering repair operations that fail again, producing the loop.

Answer

Insufficient replication factor

Answer

Excessive search concurrency

Answer

Misconfigured cold path

Question 15

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

Accepted Answer

Maintaining the bucket registry and managing replication status.. 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.

Answer

Directing search requests to specific indexers.

Answer

Indexing incoming forwarder data.

Answer

Storing raw data and serving search requests.

Answer

Aggregating search results from indexers.

Question 16

You have added a new indexer to a cluster. The indexer is up, but the Cluster Master does not show it as 'Ready'. What is the most likely cause?

Accepted Answer

The security key on the indexer does not match the Cluster Master. For an indexer to join a cluster and reach 'Ready' status, it must present the same cluster security key (pass4SymmKey under the clustering stanza) as the cluster master. If the keys differ, the indexer can start and appear 'Up' but will be rejected during cluster handshake, so the master never marks it Ready.

Answer

The indexer is missing the license file

Answer

The cluster master is in maintenance mode

Answer

The indexer has not indexed any data yet

Question 17

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

Accepted Answer

Incorrect pass4SymmKey on one of the nodes. Option A is correct because the search head cluster uses the pass4SymmKey in server.conf to authenticate and encrypt replication traffic between members; if one node has a different key, the captain cannot push configurations and replication fails. Option E is correct because configuration replication and cluster communication occur over the management port 8089 (REST/mgmt), so a firewall blocking 8089 between members prevents the captain from replicating bundles to peers. Option B is not a cause of replication failure—concurrent searches affect search performance and resource contention, not the config replication mechanism. Option C is unrelated: the license master governs licensing, not the SHC's internal replication of configurations. Option D is not a valid cause; server names need not match across cluster members, and replication depends on the shared pass4SymmKey and reachable management port, not identical hostnames.

Answer

Too many concurrent searches

Answer

Incorrect license master configuration

Answer

Mismatch in server names

Question 18

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

Accepted Answer

Disk I/O throughput. Option A (Disk I/O throughput) is correct because indexers must sustain high-throughput writes for incoming data and fast reads for searches, so IOPS and disk latency directly determine indexing and search performance. Option C (Inter-site network latency and bandwidth) is correct because in a multisite indexer cluster, replication and searchable-copy traffic crosses sites, and WAN latency/bandwidth affects replication factor satisfaction, search affinity, and site failover behavior. Option D (The total number of indexer peers) is correct because the number of peers determines replication and search factor distribution across sites, quorum requirements, and the aggregate storage/CPU capacity needed to hold replicated buckets. Option B (chassis color) is irrelevant since it has no bearing on performance, capacity, or cluster topology. Option E (number of concurrent web users) is not a hardware-sizing factor for the indexer cluster itself; user count affects search load indirectly, but the question asks about indexer cluster hardware planning, which is driven by data volume, replication/search factors, and peer count.

Answer

The color of the server chassis

Answer

The number of concurrent web users

Question 19

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

Accepted Answer

Managing bucket replication.. 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.

Answer

Performing data parsing.

Answer

Authenticating users.

Answer

Routing search results to users.

Question 20

Which TWO methods are recommended to optimize search performance when dealing with large datasets?

Accepted Answer

Use data models and acceleration. Option A (Use data models and acceleration) is correct because data models in Splunk allow you to define structured, reusable datasets, and acceleration pre-computes and stores the results of those models (or reports) so that subsequent searches run against the accelerated summaries rather than scanning the full raw dataset, dramatically reducing search time on large volumes of data. Option D (Filter searches using indexed fields) is correct because indexed fields (such as host, source, sourcetype, and any custom indexed fields) are stored in the index and can be used in the base search to prune the data before it is retrieved, minimizing the amount of data scanned and thus improving performance. Option B (Use the 'transaction' command) is not recommended for optimization because transaction is a memory- and CPU-intensive command that groups events and can severely degrade performance on large datasets. Option C (Increase the number of indexers) is not a search-performance optimization method per se; it is a scaling/architecture change that adds hardware and complexity rather than optimizing how searches are written or executed. Option E (Disable all authentication) is a security anti-pattern and has no bearing on search performance.

Answer

Use the 'transaction' command

Answer

Increase the number of indexers

Answer

Disable all authentication