SPLK-2002 Practice Exam 3 — 20 Questions

Question 1

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

Accepted Answer

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

Answer

Run a rebalance command on the CM

Answer

Delete the indexer and re-add it

Answer

Modify the indexer's hostname

Question 2

Which TWO performance-related tasks should be performed on a regular basis?

Accepted Answer

Reviewing the Search Activity dashboard. Option A is correct because reviewing the Search Activity dashboard on a regular basis reveals search performance metrics such as search concurrency, runtimes, and skipped or queued searches, allowing administrators to identify and address performance degradation proactively. Option E is correct because monitoring index storage usage regularly helps prevent indexes from reaching disk capacity limits, which would cause indexing to pause or searches to fail, and it supports capacity planning and retention policy tuning. Option B is not appropriate because deleting all historical data is destructive and unnecessary; retention should be managed through configured policies, not wholesale deletion. Option C is wrong because restarting indexers daily is disruptive and does not improve performance; indexers should only be restarted for maintenance or troubleshooting. Option D is incorrect because license capacity is a purchased entitlement that cannot and should not be increased daily as a performance task.

Answer

Deleting all historical data

Answer

Restarting all indexers daily

Answer

Increasing license capacity daily

Question 3

Which dashboard in the Monitoring Console provides the best overview of resource consumption per search head?

Accepted Answer

Search Head Activity. The Search Head Activity dashboard in the Monitoring Console provides the best overview of resource consumption per search head, showing metrics such as CPU usage, memory, disk I/O, and search load broken down by search head. It is designed specifically to help admins identify which search heads are under heavy load and to balance search distribution. Other dashboards focus on different tiers (indexers, forwarders) or different concerns (ingestion performance).

Answer

Data Ingestion Performance

Answer

Resource Usage: Forwarders

Answer

Indexer Activity

Question 4

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

Accepted Answer

Data loss if an indexer fails.. 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.

Answer

Slower indexing speed.

Answer

Higher CPU usage on the CM.

Question 5

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

Accepted Answer

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

Answer

Upgrade the search heads first

Answer

Upgrade all components simultaneously

Answer

Upgrade the indexer peers first, then the Cluster Master

Question 6

What is the primary architectural trade-off when using very short 'maxHotSpanSecs' values?

Accepted Answer

Increased metadata overhead on the indexer. 'maxHotSpanSecs' defines the maximum time span a bucket can remain in the hot state before rolling to warm. Very short values cause buckets to roll frequently, creating many small buckets. Each bucket carries metadata (bloom filters, tsidx files, bucket manifest), so frequent rolling increases metadata overhead on the indexer and can degrade performance.

Answer

Improved data ingestion speed

Answer

Reduced search performance

Answer

Increased compression efficiency

Question 7

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

Accepted Answer

Forwarders can failover to indexers in another site.. 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.

Answer

It mandates the use of SSL.

Answer

It increases the replication factor.

Answer

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

Answer

The indexer discovery service is disabled.

Question 8

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

Accepted Answer

Cluster Master. 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.

Answer

Deployment Server

Answer

License Master

Answer

Indexer Peer

Answer

Search Head

Question 9

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

Accepted Answer

To maintain session persistence and search job state.. 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.

Answer

To increase the replication speed.

Answer

To prevent unauthorized access.

Answer

To improve indexing performance.

Answer

To reduce the number of license tokens.

Question 10

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

Accepted Answer

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

Answer

The Search Head

Answer

The indexer peer itself

Answer

The Deployment Server

Question 11

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

Accepted Answer

To secure the communication between cluster nodes.. 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.

Answer

To define the replication factor.

Answer

To authorize search head access.

Answer

To manage indexer licensing.

Answer

To encrypt data in flight.

Question 12

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

Accepted Answer

To coordinate search scheduling and replicate configuration bundles.. 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.

Answer

To act as the Cluster Master for indexers.

Answer

To store all bucket data for the indexers.

Answer

To receive data from forwarders.

Answer

To distribute search results to the end user.

Question 13

What is the primary benefit of 'bucket rolling' in an indexer?

Accepted Answer

Allows the indexer to optimize disk I/O by isolating active writing to a single bucket. Bucket rolling closes the currently active (hot) bucket once it reaches a size or age threshold and opens a new hot bucket for incoming data. This isolates all active writes to a single bucket, so the indexer avoids random writes across many files and can optimize disk I/O and caching. Older buckets become warm/cold and are read-only, which further improves write efficiency.

Answer

Enables the indexer to bypass the parsing queue

Answer

Increases the size of the bucket for better compression

Answer

Reduces the requirement for indexes to be searchable

Question 14

Which THREE metrics are critical for monitoring indexer health in the Monitoring Console?

Accepted Answer

Memory usage. Memory usage (A) is critical because indexers rely heavily on RAM for the index cache and search-time processing, and excessive memory pressure can cause swapping, slow searches, or crashes. Disk I/O latency (D) is critical because indexers continuously write buckets to disk and read them during searches, so high latency directly degrades indexing throughput and search performance. CPU utilization (E) is critical because indexing pipelines, search processing, and bucket merging are CPU-intensive, and sustained high utilization indicates the indexer is saturated. The number of active apps (B) and number of logged-in users (C) are not indexer health metrics; they relate to user activity or app deployment rather than the performance and stability of the indexing tier.

Answer

Number of active apps

Answer

Number of logged-in users

Question 15

A user wants to restore data from frozen buckets. What is the process for making this data searchable again?

Accepted Answer

Copy to the thawedPath and use the 'rebuild' command. To restore frozen buckets, you copy the bucket files to the thawedPath directory defined in indexes.conf, then run the splunk rebuild command on that bucket directory to regenerate the necessary metadata (such as the .tsidx and bucket manifest files) so Splunk can search the data again. Simply placing files in the thawed path without rebuilding leaves the bucket unrecognized and unsearchable.

Answer

Directly copy files to the warm path

Answer

Change the frozenTimePeriodInSecs

Answer

Run 'splunk restore --bucket'

Question 16

You are troubleshooting a slow indexer cluster. You identify that the 'replication_port' is experiencing high latency. Where is the replication port defined?

Accepted Answer

server.conf. The replication_port setting is defined in server.conf under the [replication_port://<port>] stanza. It specifies the port on which an indexer listens for replication data from peer indexers in an indexer cluster. Since server.conf holds cluster-wide and node-level server settings, this is the correct file for replication port configuration.

Answer

indexes.conf

Answer

inputs.conf

Answer

cluster.conf

Question 17

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

Accepted Answer

Use the 'splunk offline' command on the peer.. 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.

Answer

Ignore the peer and wait for timeout.

Answer

Delete the indexer's data directory manually.

Answer

Update the master node configuration.

Answer

Shutdown the service without notice.

Question 18

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

Accepted Answer

splunk show cluster-status. 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.

Answer

splunk cluster-check

Answer

splunk inspect-cluster

Answer

splunk search-peers

Answer

splunk list indexers

Question 19

You are investigating why an indexer node is not reporting to the Cluster Master. Which THREE of the following are the most likely causes?

Accepted Answer

The security key ('pass4SymmKey') is mismatched. Option B is correct because the pass4SymmKey in the [clustering] stanza of server.conf must match across all cluster members and the master; a mismatch prevents the indexer from authenticating and registering with the Cluster Master. Option C is correct because indexers communicate with the master over the management port (default 8089), so a firewall blocking that port stops the indexer from reporting its status. Option E is correct because an indexer must be configured with the cluster-member role (mode = slave in [clustering]) to join and report to the master; without it, the instance never registers. Option A is not a cause because warm bucket count affects disk usage and search performance, not cluster registration. Option D is not a cause because the replication port (default 9887) is used for peer-to-peer bucket replication between indexers, not for reporting to the Cluster Master.

Answer

The indexer has too many warm buckets

Answer

The replication port is blocked by a firewall

Question 20

In a multi-site indexer cluster, which setting controls the number of copies of data kept per site?

Accepted Answer

site_replication_factor. In a multi-site indexer cluster, site_replication_factor is the setting in server.conf (under the [clustering] stanza) that defines how many copies of each bucket must exist within each site. It works alongside replication_factor, which sets the total number of copies across all sites. This ensures site-level redundancy so that a site failure does not cause data loss.

Answer

max_site_copies

Answer

site_data_count

Answer

cross_site_replication