Courseiva

CCNA Troubleshooting And Operations Questions

25 questions · Troubleshooting And Operations · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

A user reports that they cannot see data from an indexer peer in the Monitoring Console. Which service should you check first to ensure the MC is able to communicate with the remote instance?

A.splunkweb
B.mongod
C.Deployment Client
D.splunkd
AnswerD

The Monitoring Console communicates with indexer peers through splunkd, which handles inter-instance data and management traffic on the relevant ports. If splunkd is not running or reachable on the remote instance, the MC cannot retrieve that peer's data, so it is checked first.

Why this answer

The Monitoring Console (MC) communicates with distributed instances via the splunkd management port (default 8089) to collect health and performance data. If the MC cannot see data from an indexer peer, the first service to verify is splunkd on the remote instance, because splunkd must be running and reachable for the MC to poll it. This makes splunkd the correct first check.

Exam trap

SPLK-2002 often tests which Splunk process handles MC communication, and candidates mistakenly choose splunkweb or the Deployment Client instead of splunkd, which serves the REST API.

How to eliminate wrong answers

Option A is wrong because splunkweb (the web UI process) is not used by the Monitoring Console for data collection; MC uses the REST API served by splunkd. Option B is wrong because mongod is the KV Store process and is unrelated to MC-to-peer communication for monitoring data. Option C is wrong because the Deployment Client is responsible for receiving configurations from a deployment server, not for MC communication.

Practice this question →
2
MCQhard

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?

A.Check the replication_port
B.splunk validate cluster-bundle
C.Restart the Master
D.Check /etc/apps for errors
AnswerB

Running splunk validate cluster-bundle on the Cluster Master checks the current bundle for configuration errors before it is pushed to peers. Since a rejected or invalid bundle halts replication, this satisfies the stem's requirement to identify why peers are not receiving the latest configuration.

Why this answer

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.

Exam trap

SPLK-2002 often tests the tendency to jump to network or restart actions first, when the documented first step for bundle issues is the non-disruptive 'splunk validate cluster-bundle' command.

How to eliminate wrong answers

Option A is wrong because replication_port governs bucket replication between peers, not configuration bundle distribution, which uses the management port. Option C is wrong because restarting the Master is a disruptive action that should only follow diagnosis, not precede it. Option D is wrong because checking /etc/apps for errors is a manual, non-authoritative check — the validate command performs the same inspection systematically and is the documented first step.

Practice this question →
3
Multi-Selecthard

You have determined that a specific app deployed via the Deployment Server is causing indexer errors. Which THREE of the following actions can you take to rectify this?

Select 3 answers
A.Disable the server class associated with that app
B.Restart the master node
C.Remove the app folder from the deployment-apps directory on the Deployment Server
D.Manually delete the app folder on all indexer peers
E.Update the app to a known stable version in the deployment-apps directory
AnswersA, C, E

Disabling the server class stops the Deployment Server from pushing the faulty app to indexers, halting further errors without deleting the app definition. This directly satisfies the stem's requirement to rectify ongoing indexer errors caused by that specific app.

Why this answer

Option A is correct because disabling the server class in the Deployment Server stops the deployment of the problematic app to the indexers, preventing further errors while you investigate. Option C is correct because removing the app folder from $SPLUNK_HOME/etc/deployment-apps on the Deployment Server removes it from the deployment payload, so it will no longer be pushed to clients. Option E is correct because replacing the app in the deployment-apps directory with a known stable version lets the Deployment Server distribute a corrected app, resolving the errors.

Option B is not correct because restarting the master node (cluster manager) does not address the app causing indexer errors and is unrelated to deployment remediation. Option D is not correct because manually deleting the app folder on indexer peers is not a supported or persistent fix; the Deployment Server will simply redeploy the app on the next phone-home unless the server class or app is changed.

Exam trap

The trap is choosing manual deletion on peers (Option D) — candidates think direct removal is faster, but the Deployment Server will redeploy the app, making the action ineffective and unsupported.

Practice this question →
4
MCQmedium

You are using the Monitoring Console to monitor a distributed Splunk Enterprise environment. A dashboard that previously showed data for all indexers now displays 'No results found' for several panels. You have confirmed that the indexers are up and forwarding data. Which action should you take first to restore the Monitoring Console's visibility into those indexers?

A.Restart the Monitoring Console instance to force it to re-discover all Splunk instances.
B.Verify that the Monitoring Console's distributed search configuration includes the affected indexers as search peers.
C.Increase the search time range on each affected dashboard to 'All time' to force data to appear.
D.Reinstall the Monitoring Console app on the search head to reset its dashboards and saved searches.
AnswerB

The Monitoring Console gathers data by running searches against distributed search peers. If indexers are missing from the Monitoring Console's search peer list, its dashboards cannot retrieve their data. Confirming and adding the missing indexers as search peers directly restores visibility into those indexers.

Why this answer

The Monitoring Console relies on distributed search to collect data from indexers. If several indexers no longer appear in its dashboards, the most likely cause is that they are missing from the Monitoring Console's search peer configuration. Verifying and updating that configuration restores the data flow without unnecessary restarts or reinstalls.

Exam trap

The trap here is assuming a restart or time-range change will fix missing data, when the underlying issue is often that the Monitoring Console is not searching the affected indexers as peers.

Practice this question →
5
MCQhard

You notice that your indexers are using different versions of a lookup file. Where should you look to find the authoritative version of the lookup file if it is being managed by the Cluster Master?

A.$SPLUNK_HOME/etc/slave-apps
B.$SPLUNK_HOME/etc/master-apps
C.$SPLUNK_HOME/etc/system/local
D.$SPLUNK_HOME/etc/apps
AnswerB

The cluster master distributes configuration bundles to peer indexers from $SPLUNK_HOME/etc/master-apps, making it the authoritative source. Any lookup managed centrally is replicated from here, so version discrepancies across indexers are resolved by comparing against this directory.

Why this answer

When the Cluster Master manages indexer configuration via a cluster bundle, the authoritative source is $SPLUNK_HOME/etc/master-apps on the Cluster Master. Apps and lookups placed here are packaged into the cluster bundle and pushed to all peers. The master-apps directory is the staging area for the master's bundle.

Exam trap

The trap is confusing master-apps (authoritative source on the master) with slave-apps (unpacked destination on peers) — candidates often pick slave-apps thinking it is where the master stores files.

How to eliminate wrong answers

Option A is wrong because $SPLUNK_HOME/etc/slave-apps is the legacy/deprecated location on peers where the master's bundle is unpacked; it is not authoritative and should not be edited. Option C is wrong because $SPLUNK_HOME/etc/system/local contains local overrides on a single instance, not cluster-managed content. Option D is wrong because $SPLUNK_HOME/etc/apps is the local app directory on an individual Splunk instance, not the master's authoritative bundle source.

Practice this question →
6
MCQhard

An Indexer Cluster is experiencing 'Search Factor' violations. Which component is responsible for orchestrating the fix-up process to restore the search factor?

A.The Cluster Master
B.The Indexer Peer containing the missing copies
C.The Search Head
D.The Deployment Server
AnswerA

The Cluster Master (manager node) coordinates peer replication and orchestrates fix-up when a bucket's searchable copies fall below the Search Factor. It identifies which peer should receive the missing searchable copy and triggers the copy, restoring the Search Factor. Indexers hold the data but do not orchestrate this remediation themselves.

Why this answer

In an Indexer Cluster, the Cluster Master (now called Cluster Manager in newer versions) is the component responsible for orchestrating fix-up. When a Search Factor violation occurs (fewer searchable copies than the configured search factor), the Cluster Master identifies which buckets need additional searchable copies and directs peers to replicate them, restoring the search factor.

Exam trap

SPLK-2002 often tests whether candidates confuse the Cluster Master's orchestration role with the peers' data-holding role — the trap is assuming the peer with the missing copy initiates fix-up, when in fact the Cluster Master directs all replication and fix-up operations.

How to eliminate wrong answers

Option B is wrong because the Indexer Peer holding the missing copies is a data holder, not the orchestrator — peers receive and execute replication/fix-up instructions from the Cluster Master but do not initiate or coordinate the process. Option C is wrong because the Search Head queries indexers and manages knowledge objects; it plays no role in bucket replication or search factor restoration. Option D is wrong because the Deployment Server distributes configuration (apps, configs) to forwarders and other components — it has no involvement in indexer cluster replication or fix-up.

Practice this question →
7
MCQmedium

A Search Head Cluster is experiencing frequent 'Search Head Captain Election' messages in the logs. What is the most likely cause?

A.The indexer cluster is offline
B.The KV store is running
C.Network latency or instability between SHC members
D.The license is expired
AnswerC

Captain elections trigger when members cannot exchange heartbeats reliably. Network latency or instability between search head cluster members causes missed heartbeats, forcing repeated elections. Stable, low-latency connectivity is required for the captain to maintain leadership.

Why this answer

Frequent Search Head Captain Election messages indicate that the captain is changing often, which is typically caused by network latency or instability between SHC members. The captain election process relies on consensus and heartbeats; if members cannot communicate reliably, elections are triggered. The other options would cause different symptoms, such as search failures or licensing warnings, but not frequent elections.

Exam trap

SPLK-2002 often tests the assumption that captain elections are caused by indexer issues, but the root cause is usually network instability among search heads.

How to eliminate wrong answers

Option A is wrong because an offline indexer cluster would affect search results but not directly cause SHC captain elections. Option B is wrong because a running KV store is normal and does not cause elections. Option D is wrong because an expired license would disable search and indexing, not cause captain elections.

Practice this question →
8
MCQmedium

An indexer cluster has a replication factor of 3 and a search factor of 2. The Monitoring Console shows several buckets in the cluster with a search factor of 1. You need to confirm whether the cluster manager is actively fixing these buckets. Which command should you run on the cluster manager to view the status of bucket fixup tasks?

A.`splunk list cluster-fixup`
B.`splunk show cluster-status`
C.`splunk show cluster-bundle-status`
D.`splunk show cluster-peers`
AnswerA

On the cluster manager, `splunk list cluster-fixup` displays the current fixup tasks, including which buckets are being replicated or searched to meet the replication and search factors. This directly answers whether the manager is actively fixing the buckets that show a search factor of 1.

Why this answer

Bucket fixup is orchestrated by the cluster manager, and the `splunk list cluster-fixup` command on the manager reports active fixup tasks. When buckets fall below the search factor, the manager schedules searchable copies on other peers; this command shows those tasks so you can confirm that repair is in progress and not stalled.

Exam trap

The trap here is confusing cluster-wide status commands with the specific fixup task listing, and looking for bucket repair details in commands that only summarize peer or bundle status.

Practice this question →
9
MCQhard

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

A.indexes.conf
B.inputs.conf
C.server.conf
D.cluster.conf
AnswerC

The replication port is configured in server.conf, under the `[replication_port://<port>]` stanza, which defines the listening port used for indexer-to-indexer replication traffic. Setting this stanza correctly on each peer node satisfies the stem's requirement to locate where the replication port is defined.

Why this answer

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.

Exam trap

SPLK-2002 often tests whether candidates confuse cluster.conf (which holds replication_factor and master_uri) with server.conf (which holds the replication_port listener) — the port is a server-level setting, not a cluster membership setting.

How to eliminate wrong answers

Option A is wrong because indexes.conf defines index properties (path, retention, size) — it has no replication port setting. Option B is wrong because inputs.conf configures data inputs (monitor, TCP/UDP, scripted) — it does not control cluster replication. Option D is wrong because cluster.conf defines cluster membership and replication factor settings (e.g., replication_factor, search_factor, master_uri) but not the replication port itself; the port is a server-level listener defined in server.conf.

Practice this question →
10
MCQmedium

A Splunk architect notices that an indexer cluster's search head is returning incomplete results for a search spanning the last 7 days. The Monitoring Console shows that several buckets are missing their searchable copies, and the cluster master reports a search factor (SF) of 2 but replication factor (RF) of 3. Which of the following best explains why the search results are incomplete and what should be done to remediate the issue?

A.The indexer cluster's replication factor is set higher than the number of indexers; reduce RF to match the number of indexers and restart the cluster.
B.The indexer cluster is under-replicated; wait for automatic fix-up or manually trigger fix-up to create additional searchable copies to meet the search factor.
C.The search head is not configured to use the cluster master for search; configure the search head to point to the cluster master and restart Splunk.
D.The search head is experiencing a network partition; verify connectivity between the search head and all indexers, and restart the search head.
AnswerB

With SF=2 and RF=3, the cluster should maintain two searchable copies of each bucket. The Monitoring Console indicates missing searchable copies, meaning some buckets have fewer than two searchable copies. This can cause incomplete search results if the search head cannot access all bucket copies. The cluster master automatically initiates fix-up, but manual intervention may be needed if fix-up is stalled.

Why this answer

In an indexer cluster, the search factor determines how many searchable copies of each bucket are maintained. When searchable copies are missing, searches may not see all data because the search head can only search buckets that are searchable on the indexers. The cluster master orchestrates fix-up to create additional copies, but if fix-up is not progressing, manual intervention may be required.

Addressing the searchable copy deficit directly resolves the incomplete search results.

Exam trap

The trap here is confusing replication factor with search factor and assuming that increasing RF will automatically fix searchability, when the issue is specifically about searchable copies.

Practice this question →
11
Multi-Selectmedium

When planning a Splunk upgrade, which THREE of the following actions are considered best practices for maintaining system health?

Select 3 answers
A.Upgrade the license master last
B.Perform a mock upgrade in a staging environment
C.Verify compatibility with all installed apps and add-ons
D.Run the upgrade on the search heads before the indexers
E.Perform a full backup of the indexer buckets and configuration files
AnswersB, C, E

A mock upgrade in staging exercises the full upgrade path, including app compatibility and configuration migrations, without risking production. It satisfies the stem's system-health constraint by exposing failures, rollback gaps and performance regressions before the change window opens on live indexers.

Why this answer

Option B is correct because performing a mock upgrade in a staging environment lets you validate the upgrade path, catch configuration or app issues, and rehearse rollback procedures before touching production. Option C is correct because verifying compatibility with all installed apps and add-ons ensures that third-party and custom components support the target Splunk version, preventing broken searches, dashboards, or data ingestion after the upgrade. Option E is correct because a full backup of indexer buckets and configuration files (such as $SPLUNK_HOME/etc and the index directories) provides a recovery point if the upgrade fails or corrupts data, which is essential for maintaining system health.

Option A is not a best practice because the license master should generally be upgraded first (or in the correct order relative to other components) so it can properly serve licenses to upgraded peers. Option D is not a best practice because indexers should typically be upgraded before search heads, since search heads depend on indexers being available and compatible for search functionality.

Exam trap

SPLK-2002 often tests upgrade sequencing misconceptions — candidates assume the license master should be upgraded last or that search heads should be upgraded before indexers, when the correct order is the opposite.

Practice this question →
12
MCQeasy

You notice that the Monitoring Console (MC) reports a 'Disk usage' warning for an indexer. Which dashboard should you navigate to in order to identify which specific index is consuming the most disk space?

A.Indexes and Volumes: Instance
B.Indexing Performance: Instance
C.Resource Usage: Indexer Instance
D.Cluster Status
AnswerA

The Indexes and Volumes: Instance dashboard breaks down disk consumption per index on a specific indexer, letting you pinpoint the largest consumer. This directly satisfies the need to identify which index is driving the disk usage warning.

Why this answer

The Monitoring Console's 'Indexes and Volumes: Instance' dashboard shows per-index disk usage on a specific indexer instance, including the size of each index and its volumes. This is the correct dashboard to identify which index is consuming the most disk space when a Disk usage warning fires. It breaks down usage by index, making the culprit immediately visible.

Exam trap

SPLK-2002 often tests whether candidates pick a performance or resource dashboard (Indexing Performance, Resource Usage) when the question is specifically about per-index disk consumption — the 'Indexes and Volumes: Instance' dashboard is the only one that breaks down disk usage by index.

How to eliminate wrong answers

Option B is wrong because 'Indexing Performance: Instance' shows indexing throughput, queue sizes, and pipeline metrics — it does not report disk usage per index. Option C is wrong because 'Resource Usage: Indexer Instance' shows CPU, memory, and disk I/O metrics at the host level, not per-index disk consumption. Option D is wrong because 'Cluster Status' shows cluster health, replication/search factor status, and peer availability — not per-index disk usage on a single indexer.

Practice this question →
13
MCQeasy

You are using the Monitoring Console to view the 'Search Head Clustering: Status' dashboard. You see that one of the nodes is showing as 'Missing'. What does this status imply?

A.The node is overloaded
B.The captain has not received a heartbeat from the node
C.The node is in maintenance mode
D.The node has an invalid license
AnswerB

A 'Missing' node in Search Head Clustering means the captain has stopped receiving that peer's heartbeat, so the node is presumed down or unreachable. This directly satisfies the dashboard's status check, which relies on periodic heartbeats rather than replication or search artefact checks.

Why this answer

In the Search Head Clustering: Status dashboard, a node showing 'Missing' means the cluster captain has not received a heartbeat from that node within the expected interval. The captain tracks member health via heartbeats, and a missing heartbeat indicates the node is unreachable, down, or partitioned from the cluster. This is a connectivity/health signal, not a performance or licensing state.

Exam trap

SPLK-2002 often tests the meaning of cluster status labels; candidates assume 'Missing' means the node is down or overloaded, but it specifically means the captain has not received a heartbeat, which can happen even when the node is running.

How to eliminate wrong answers

Option A is wrong because an overloaded node would typically show as up but with high resource usage or lagging replication, not as 'Missing' — overload does not stop heartbeats unless it causes a crash. Option C is wrong because maintenance mode is an explicit administrative state that a node reports; it would show as 'Maintenance' or similar, not 'Missing'. Option D is wrong because an invalid license would affect indexing or search functionality and would surface as a licensing error, not as a missing heartbeat in the clustering status dashboard.

Practice this question →
14
MCQmedium

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?

A.The peers must be upgraded before the Master
B.Half the cluster, then the other half
C.One by one, ensuring the cluster returns to a healthy state before moving to the next
D.All peers at once
AnswerC

Upgrading indexer peers sequentially, one at a time, allows each peer to rejoin and the cluster to regain full searchability and replication health before the next is taken offline. This preserves data availability and avoids multiple simultaneous outages.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that peers can be upgraded in parallel batches or before the Master — candidates confuse the order (Master first) or assume speed over safety.

How to eliminate wrong answers

Option A is wrong because the Master must always be upgraded before the peers — the Master coordinates the cluster and must be running the target version to manage upgraded peers. Option B is wrong because upgrading half the cluster at once risks losing quorum and can leave the cluster in a degraded state if replication/search factors cannot be satisfied. Option D is wrong because upgrading all peers simultaneously causes a full cluster outage and risks data loss if the upgrade fails.

Practice this question →
15
MCQhard

A deployment server manages a large number of universal forwarders. Several forwarders in a server class named `linux_web` have stopped receiving configuration updates after you modified a `props.conf` file in the deployment app. You need to determine why the deployment server is not pushing the updated configuration to those forwarders. Which log file on the deployment server should you examine first?

A.`$SPLUNK_HOME/var/log/splunk/license_usage.log`
B.`$SPLUNK_HOME/var/log/splunk/splunkd_access.log`
C.`$SPLUNK_HOME/var/log/splunk/splunkd.log`
D.`$SPLUNK_HOME/var/log/splunk/metrics.log`
AnswerC

The deployment server logs deployment-related activity in splunkd.log, including client connections, phone-home requests, and errors when serving configuration bundles. Messages about failed bundle downloads or server class mapping issues appear here, making it the first place to check why forwarders in the `linux_web` server class are not receiving updates.

Why this answer

The deployment server records client phone-home activity, server class matching, and bundle delivery errors in splunkd.log. When forwarders stop receiving updates, this log reveals whether they are connecting, whether they are being mapped to the correct server class, and whether bundle downloads are failing due to permissions or content issues.

Exam trap

The trap here is looking at access or metrics logs for deployment activity, when deployment client connections and bundle errors are recorded in splunkd.log.

Practice this question →
16
MCQmedium

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?

A.The indexer is missing the license file
B.The cluster master is in maintenance mode
C.The security key on the indexer does not match the Cluster Master
D.The indexer has not indexed any data yet
AnswerC

Cluster Master readiness requires every peer to share the identical cluster security key; a mismatched key prevents the indexer from authenticating and joining the cluster, so it never transitions to Ready despite the service running.

Why this answer

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.

Exam trap

SPLK-2002 often tests the distinction between 'Up' and 'Ready' — candidates assume any running indexer should be Ready, missing that cluster handshake (security key, master URI) is a separate gate from process health.

How to eliminate wrong answers

Option A is wrong because a missing license file would prevent Splunk from starting or would trigger license violations, but it does not specifically block cluster readiness — licensing is handled separately from cluster membership. Option B is wrong because maintenance mode on the master pauses certain cluster operations but does not prevent a new peer from being recognized; the peer would still show as pending/ready once maintenance ends. Option D is wrong because an indexer does not need to have indexed data to become Ready — readiness is about successful cluster handshake and bucket replication capability, not data volume.

Practice this question →
17
MCQmedium

You are investigating a scenario where search performance has degraded. You observe that many searches are hitting the 'warm' buckets but not the 'cold' buckets. Where should you look to verify bucket rotation policies?

A.outputs.conf
B.inputs.conf
C.server.conf
D.indexes.conf
AnswerD

Bucket rotation between warm and cold tiers is governed by the frozenTimePeriodInSecs and related retention settings defined per index in indexes.conf. Checking this file on the indexers verifies the policies controlling when warm buckets roll to cold.

Why this answer

Bucket rotation policies — including the thresholds that move buckets from hot to warm to cold to frozen, and the retention periods for each — are defined per index in indexes.conf. Parameters like maxHotBuckets, maxWarmDBCount, frozenTimePeriodInSecs, and homePath/coldPath control when and where buckets roll. To verify or change rotation behavior, you inspect indexes.conf on the indexers (or via the cluster manager for clustered environments).

Exam trap

SPLK-2002 often tests which .conf file owns which setting; candidates confuse server.conf (server-wide) with indexes.conf (per-index) and pick server.conf for bucket rotation, missing that rotation is an index-level property.

How to eliminate wrong answers

Option A is wrong because outputs.conf configures data forwarding destinations (indexers, heavy forwarders) and does not contain any bucket or index retention settings. Option B is wrong because inputs.conf defines data inputs (monitor, TCP/UDP, scripted inputs) and their sourcetypes/index routing; it has no bucket rotation parameters. Option C is wrong because server.conf controls general server behavior such as licensing, clustering, KV store, and search head settings, but not per-index bucket rotation policies.

Practice this question →
18
MCQeasy

You are tasked with verifying the health of the indexer cluster. Which dashboard in the Monitoring Console provides a high-level overview of the health of all indexer nodes, including their replication status?

A.Indexer Cluster: Status
B.Indexing Performance: Cluster
C.Resource Usage: Indexer Cluster
D.Distributed Search: Status
AnswerA

The Indexer Cluster: Status dashboard in the Monitoring Console aggregates peer node health, replication and search factor status, and bucket replication across all indexers. It provides the high-level cluster-wide overview the task requires, unlike per-node or per-index dashboards.

Why this answer

The Monitoring Console's 'Indexer Cluster: Status' dashboard is purpose-built to show a high-level health view of all indexer cluster nodes, including peer status, replication and search factor compliance, and bucket replication status. It aggregates cluster health so you can quickly see whether the cluster is fully replicated and whether any peers are down or lagging. The other dashboards focus on performance, resource usage, or distributed search rather than cluster replication health.

Exam trap

SPLK-2002 often tests the difference between cluster health (replication/peer status) and cluster performance (throughput/resource usage); candidates pick 'Indexing Performance: Cluster' because it also says 'Cluster' but it does not show replication status.

How to eliminate wrong answers

Option B is wrong because 'Indexing Performance: Cluster' focuses on indexing throughput, queue sizes, and pipeline metrics across the cluster, not on replication status or peer health. Option C is wrong because 'Resource Usage: Indexer Cluster' reports CPU, memory, disk, and I/O consumption across indexers, which is about capacity and resource pressure, not replication state. Option D is wrong because 'Distributed Search: Status' covers search head to indexer connectivity and search peer availability for distributed search, not indexer cluster replication or bucket health.

Practice this question →
19
MCQeasy

You are monitoring indexer performance. Which metric in the Monitoring Console's 'Indexing Performance' dashboard best indicates a bottleneck in the ingestion pipeline?

A.Disk Read IOPS
B.Memory Usage
C.CPU Usage
D.Average Queue Fill Percentage
AnswerD

Average Queue Fill Percentage shows how full the ingestion queues are over time. A persistently high value indicates the indexers cannot consume data as fast as it arrives, pinpointing a bottleneck in the ingestion pipeline rather than in search or disk performance.

Why this answer

The Average Queue Fill Percentage metric in the Indexing Performance dashboard directly measures how full the indexing pipeline queues are. A persistently high or rising queue fill percentage indicates that events are arriving faster than the indexers can process them, which is the clearest signal of an ingestion bottleneck. Disk, memory, and CPU metrics can be symptoms, but queue fill is the direct indicator of pipeline backpressure.

Exam trap

SPLK-2002 often tests whether candidates can distinguish direct pipeline indicators from generic resource metrics, so CPU and memory options look plausible to anyone who equates 'bottleneck' with 'high resource usage'.

How to eliminate wrong answers

Option A is wrong because Disk Read IOPS reflects storage read activity and is more relevant to search performance or bucket replication than to ingestion pipeline saturation. Option B is wrong because Memory Usage is a resource metric that may be high for many reasons and does not directly indicate ingestion backpressure. Option C is wrong because CPU Usage is a general resource metric; high CPU can slow indexing but does not by itself prove a pipeline bottleneck, whereas queue fill does.

Practice this question →
20
Multi-Selecthard

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

Select 3 answers
A.The indexer has too many warm buckets
B.The security key ('pass4SymmKey') is mismatched
C.The management port is blocked by a firewall
D.The replication port is blocked by a firewall
E.The indexer instance is not running the 'cluster-member' role
AnswersB, C, E

Cluster peers authenticate with the shared pass4SymmKey; if the indexer's key differs from the master's, the peer handshake fails and the node never appears as a cluster member. A mismatch therefore directly prevents reporting, satisfying the stem's requirement for a likely cause.

Why this answer

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.

Exam trap

SPLK-2002 often tests the distinction between the management port (8089, for Master-peer communication) and the replication port (9887, for peer-to-peer bucket replication), causing candidates to select the wrong port as the cause of reporting failures.

Practice this question →
21
Multi-Selecthard

You are troubleshooting slow search performance across the indexer cluster. Which THREE of the following could be potential causes?

Select 3 answers
A.The indexers have high CPU usage
B.The KV store on the search head is disabled
C.Search concurrency limits are being reached on the search head
D.The indexer cluster is currently re-balancing buckets
E.The Splunk license is close to the daily limit
AnswersA, C, D

Splunk search performance depends on indexer CPU headroom for search processing and result aggregation. Sustained high CPU usage starves search processes, queuing and slowing queries across the cluster, directly explaining the slow search performance described in the stem.

Why this answer

Option A is correct because high CPU usage on the indexers directly degrades search performance, as indexers must parse, search, and return results from buckets, and CPU saturation slows query processing and result aggregation. Option C is correct because when search concurrency limits are reached on the search head, additional searches are queued or throttled, which manifests as slow search performance for users. Option D is correct because bucket re-balancing in an indexer cluster involves copying and moving buckets between peers, consuming disk I/O, network bandwidth, and CPU, which competes with search workloads and slows them down.

Option B is not correct because the KV store on the search head supports features like saved searches, lookups, and knowledge objects, but disabling it does not directly cause slow search performance across the indexer cluster. Option E is not correct because approaching the daily license limit triggers license violations and search warnings or blocking, but it is not a direct cause of slow search performance.

Exam trap

SPLK-2002 often tests the distinction between direct performance bottlenecks (CPU, concurrency, rebalancing) and indirect or non-performance issues (KV store, license limits), so candidates must identify which factors directly impact search speed.

Practice this question →
22
Multi-Selecthard

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

Select 3 answers
A.The peers will continue to index incoming data normally
B.The Master will not alert on any missing buckets
C.The Master will force a bucket re-balance immediately
D.All searches will be automatically disabled
E.The Cluster Master will not perform bucket fix-up activities
AnswersA, B, E

During maintenance mode, peers keep indexing incoming data normally, so ingestion continues uninterrupted. The cluster simply suspends replication and searchability of new buckets until the maintenance window ends, meaning the constraint satisfied is continuous data ingestion while replication and search factors are temporarily relaxed.

Why this answer

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.

Exam trap

SPLK-2002 often tests the specific behaviors suspended during Maintenance Mode — candidates incorrectly assume that searches are disabled or that the master forces rebalancing, when in fact the master simply pauses bucket management while indexing and searching continue.

Practice this question →
23
MCQhard

You are troubleshooting a KV store issue in an Indexer Cluster. Which command allows you to verify the status of the KV store and its replication on a node?

A.mongostat
B.splunk show kvstore-status
C.check_kvstore.py
D.splunk status kvstore
AnswerB

splunk show kvstore-status reports KV store status, replication, and node role on the queried node. This directly verifies both store health and replication across the indexer cluster, satisfying the troubleshooting requirement without inspecting configuration files.

Why this answer

The command 'splunk show kvstore-status' is the supported CLI command to display the KV Store status on a Splunk instance, including replication status, port, and storage engine details. It works on indexers, search heads, and cluster members, making it the correct tool for verifying KV Store health and replication in an Indexer Cluster.

Exam trap

SPLK-2002 often tests the exact CLI syntax for KV Store diagnostics, and candidates confuse it with MongoDB tools like mongostat or invent invalid commands like 'splunk status kvstore'.

How to eliminate wrong answers

Option A is wrong because mongostat is a MongoDB utility that shows live database operation counters, but it is not the Splunk-supported command for KV Store status and may not be available or properly configured in Splunk's bundled MongoDB. Option C is wrong because check_kvstore.py is not a standard Splunk command; while there are diagnostic scripts, the official CLI command is 'splunk show kvstore-status'. Option D is wrong because 'splunk status kvstore' is not valid syntax; the correct order is 'splunk show kvstore-status'.

Practice this question →
24
MCQhard

An architect is troubleshooting a Splunk deployment where search head cluster members are unable to replicate the search head captain's knowledge bundle. The captain's log shows repeated errors about failing to push the bundle to a member. Which of the following is the most likely cause and the appropriate resolution?

A.The search head cluster members are using a different Splunk version than the captain; upgrade all members to match the captain's version.
B.The captain's management port (default 8089) is blocked by a firewall between the captain and the members; open the port to allow bundle replication.
C.The search head cluster members have insufficient disk space to store the knowledge bundle; free up disk space on the members.
D.The captain's replication factor for the knowledge bundle is set to 0; increase the replication factor to at least 1.
AnswerB

Search head cluster bundle replication uses the management port (8089) to transfer the knowledge bundle from the captain to the members. If a firewall blocks this port, the captain cannot push the bundle, resulting in the observed errors. Opening the port on the firewall ensures successful replication. This is a common issue in distributed environments with network segmentation.

Why this answer

In a search head cluster, the captain is responsible for replicating the knowledge bundle to all members. This replication occurs over the management port (8089 by default). If a firewall blocks this port between the captain and a member, the captain cannot push the bundle, leading to replication errors.

Ensuring the management port is open and accessible on all members resolves the issue. This is a common configuration oversight in environments with strict network policies.

Exam trap

The trap here is assuming that bundle replication uses the same port as data forwarding (9997) or the web port (8000), when it actually uses the management port (8089).

Practice this question →
25
MCQmedium

A user claims that a search is not returning data from a specific time range. You suspect the data has been rolled to cold storage and the cold storage is not being searched. Which configuration file controls which cold paths are included in the search?

A.indexes.conf
B.distsearch.conf
C.server.conf
D.limits.conf
AnswerA

This file defines the pathing and retention policies for the index.

Why this answer

The indexes.conf file defines index properties, including the paths for hot, warm, cold, and frozen buckets. The 'coldPath' setting specifies where cold buckets are stored, and Splunk searches these paths by default unless configured otherwise. Therefore, indexes.conf controls which cold paths are included in searches.

Exam trap

SPLK-2002 often tests which configuration file governs index storage paths, and candidates incorrectly choose limits.conf or server.conf, which control search limits and server settings respectively.

How to eliminate wrong answers

Option B is wrong because distsearch.conf configures distributed search settings such as search peers and replication, not index storage paths. Option C is wrong because server.conf controls general server settings like ports, SSL, and clustering, not index bucket paths. Option D is wrong because limits.conf sets search and indexing limits (e.g., max results, memory), not cold storage locations.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Troubleshooting And Operations questions.

Start 20-question session