Courseiva

CCNA Performance Tuning Questions

28 questions · Performance Tuning topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
Multi-Selectmedium

Which THREE configuration files are most important when tuning indexer performance?

Select 3 answers
A.server.conf
B.inputs.conf
C.web.conf
D.limits.conf
E.indexes.conf
AnswersA, D, E

In server.conf, the `[general]` stanza's `parallelIngestionPipelines` setting controls how many ingestion pipelines run per indexer, directly governing CPU parallelism during indexing. Raising it scales throughput across cores, satisfying the stem's indexer performance tuning requirement, while `[clustering]` options manage replication load.

Why this answer

server.conf is correct because it holds core indexer-level settings such as parallel ingestion pipelines (parallelIngestionPipelines) and general server tuning parameters that directly govern indexing throughput. limits.conf is correct because it controls resource limits like maxKBps (throttling), maxHotBuckets, and various queue sizes that determine how much data the indexer can process concurrently. indexes.conf is correct because it defines per-index properties such as maxDataSize, maxHotBuckets, maxWarmDBCount, and homePath/coldPath, which directly affect indexer storage and search performance. inputs.conf is not among the top three tuning files here since it mainly configures data inputs (stanzas, sourcetypes, host) rather than indexer performance limits. web.conf is not correct because it configures the Splunk Web UI and search head presentation settings, not indexer performance.

Exam trap

SPLK-2002 often tests which configuration files affect indexer performance — the trap is including inputs.conf or web.conf, which are relevant to data ingestion configuration or UI settings but not to indexer resource tuning.

Practice this question →
2
Multi-Selecthard

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

Select 2 answers
A.Use data models and acceleration
B.Use the 'transaction' command
C.Increase the number of indexers
D.Filter searches using indexed fields
E.Disable all authentication
AnswersA, D

Data model acceleration precomputes and stores summarised results in tsidx files, so searches against the model read compact prebuilt summaries instead of raw events. This avoids repeated full-dataset scans, directly addressing the large-dataset performance constraint.

Why this answer

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.

Exam trap

SPLK-2002 often tests the difference between search optimization techniques and scaling; candidates may choose increasing indexers or using transaction, but the recommended methods are data model acceleration and filtering on indexed fields.

Practice this question →
3
MCQhard

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

A.site_replication_factor
B.max_site_copies
C.site_data_count
D.cross_site_replication
AnswerA

site_replication_factor defines the per-site copy count in a multi-site indexer cluster, expressed as a comma-separated list matching each site's label. It satisfies the stem's constraint of controlling copies kept per site, unlike replication_factor, which governs total cluster-wide copies regardless of site boundaries.

Why this answer

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.

Exam trap

SPLK-2002 often tests the distinction between replication_factor (total copies across all sites) and site_replication_factor (copies per site), so candidates may confuse the two or pick a non-existent setting like max_site_copies.

How to eliminate wrong answers

Option B is wrong because max_site_copies is not a valid Splunk configuration setting; it is a fabricated term. Option C is wrong because site_data_count is not a real Splunk parameter; Splunk uses replication_factor and site_replication_factor, not a count of data per site. Option D is wrong because cross_site_replication is not a Splunk setting; cross-site replication is a behavior controlled by replication_factor and site_replication_factor, not a standalone option.

Practice this question →
4
Multi-Selecthard

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

Select 2 answers
A.Reviewing the Search Activity dashboard
B.Deleting all historical data
C.Restarting all indexers daily
D.Increasing license capacity daily
E.Monitoring index storage usage
AnswersA, E

Reviewing the Search Activity dashboard regularly reveals slow searches, concurrency peaks and resource contention. It satisfies the performance task requirement by surfacing the search-side constraint, enabling tuning of limits and knowledge objects before user experience degrades.

Why this answer

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.

Exam trap

SPLK-2002 often tests the distinction between proactive operational monitoring tasks (dashboards, storage) and reactive or destructive actions (deleting data, restarting services), so candidates who pick the 'drastic fix' options instead of the ongoing monitoring tasks get trapped.

Practice this question →
5
Multi-Selecteasy

Which TWO tools in the Splunk UI assist in performance troubleshooting?

Select 2 answers
A.Monitoring Console
B.Deployment Server
C.Search Inspector
D.License Master
E.Upload Data Wizard
AnswersA, C

The Monitoring Console aggregates indexer, search head and forwarder health metrics in one dashboard, letting you correlate resource saturation across the deployment. This directly satisfies the stem's requirement for a UI tool that assists performance troubleshooting.

Why this answer

The Monitoring Console (A) is correct because it is Splunk's dedicated UI for health and performance monitoring, providing dashboards for resource usage, indexing throughput, search performance, and component-level diagnostics across the deployment. The Search Inspector (C) is correct because it appears in the Search app's Job menu and exposes detailed per-search performance data such as run duration, execution costs, search phases, and resource usage, which is essential for troubleshooting slow or inefficient searches. The Deployment Server (B) is incorrect because it is used to distribute apps and configuration to forwarders and clients, not to diagnose performance.

The License Master (D) is incorrect because it manages license usage and violations, which is a licensing concern rather than a performance-troubleshooting tool. The Upload Data Wizard (E) is incorrect because it is used to ingest or onboard data, not to analyze or troubleshoot performance.

Exam trap

SPLK-2002 often tests the distinction between tools for configuration management (Deployment Server, License Master) and tools for performance troubleshooting (Monitoring Console, Search Inspector), causing candidates to pick management tools.

Practice this question →
6
MCQmedium

When a search is running, what does the 'Dispatch' directory store?

A.Indexed data
B.Temporary search results and metadata
C.License information
D.App configuration files
AnswerB

The Dispatch directory holds the artefacts a search head generates while running a search, including temporary results and metadata such as the search job's configuration and status. It is not the indexer's rawdata store, which persists indexed events.

Why this answer

The Dispatch directory ($SPLUNK_HOME/var/run/splunk/dispatch) is where the search head writes per-search artifacts while a search job is active: the search results (results.csv.gz), the job's metadata (info.csv), the search.log, and any intermediate map/reduce output. It is transient working storage tied to the search job lifecycle, not persistent indexed data. Once the job's TTL expires (default 10 minutes for completed jobs, configurable via dispatch.ttl in limits.conf), the directory is removed.

Exam trap

SPLK-2002 often tests confusion between the dispatch directory (transient per-search working data) and the index directories (persistent bucket storage), so candidates who see 'results' and think 'indexed data' pick option A.

How to eliminate wrong answers

Option A is wrong because indexed data lives in the index buckets under $SPLUNK_HOME/var/lib/splunk/<index>/db (hot/warm) and colddb (cold), not in dispatch. Option C is wrong because license information is stored in $SPLUNK_HOME/etc/licenses and enforced by the license manager, not written to dispatch. Option D is wrong because app configuration files reside in $SPLUNK_HOME/etc/apps and etc/system, which are read at startup and reload, not stored per-search in dispatch.

Practice this question →
7
MCQeasy

How can you verify the current health and performance of your indexers using the Monitoring Console?

A.License usage dashboard
B.Indexer: Instance dashboard
C.Deployment Health dashboard
D.Search Performance dashboard
AnswerB

The Indexer: Instance dashboard in the Monitoring Console reports per-indexer throughput, latency, queue size and skipped or failed events, directly verifying indexer health and performance. Other dashboards cover search heads, licence usage or cluster-wide resource consumption rather than individual indexer instances.

Why this answer

The Indexer: Instance dashboard in the Monitoring Console provides detailed health and performance metrics for individual indexers, including CPU, memory, disk usage, and search performance. This dashboard is specifically designed to verify the health and performance of indexers, making B the correct choice.

Exam trap

Candidates often confuse the Indexer: Instance dashboard with the Search Performance dashboard, but the former is specifically for indexer health, while the latter is for search performance.

How to eliminate wrong answers

Option A is wrong because the License usage dashboard shows license consumption, not indexer health or performance. Option C is wrong because the Deployment Health dashboard monitors deployment server and forwarder management, not indexer performance. Option D is wrong because the Search Performance dashboard focuses on search activity and performance, but not specifically on indexer health; it may include some indexer metrics but is not the primary dashboard for indexer health.

Practice this question →
8
MCQmedium

Which command helps you understand if your search is retrieving too much data from the disk by analyzing the 'index_time' and 'search_time'?

A.Monitoring Console Search Activity Dashboard
B.Search Inspector
C.btool
D.splunkd log analysis
AnswerB

Search Inspector breaks down a search's execution into phases, exposing index_time and search_time per operator. High search_time relative to index_time reveals excessive disk retrieval, directly satisfying the stem's requirement to diagnose whether too much data is being read from disk.

Why this answer

The Search Inspector in Splunk is a built-in tool that provides detailed performance metrics for a specific search job, including the time spent on index_time (disk I/O) and search_time (processing). By examining these timings, you can determine if the search is reading excessive data from disk, which often indicates inefficiencies like lack of filtering or improper use of indexes. It is specifically designed for this diagnostic purpose, making it the correct choice.

Exam trap

SPLK-2002 often tests the confusion between tools that provide aggregate search performance data (like Monitoring Console) and those that give per-search detailed timing breakdowns (Search Inspector), so candidates must know which tool offers the specific index_time and search_time metrics.

How to eliminate wrong answers

Option A is wrong because the Monitoring Console Search Activity Dashboard provides aggregate search performance metrics across users and time, but it does not break down individual search timings into index_time and search_time. Option C is wrong because btool is a command-line utility for troubleshooting configuration file precedence and merging, not for analyzing search performance metrics. Option D is wrong because splunkd log analysis involves examining internal logs for errors or warnings, but it does not provide the structured timing breakdown that Search Inspector offers.

Practice this question →
9
MCQhard

A user complains that a search is slow despite having a small time range. The Search Inspector reveals 'event_count' is high, but 'scanned_count' is also high. What is the likely cause?

A.The indexer has too much memory
B.Data model acceleration is failing
C.The search is not using an indexed field to filter data
D.The search head is underpowered
AnswerC

A high scanned_count alongside high event_count means Splunk read far more raw data than the time range alone implies, because the filter is not an indexed field. Without an indexed term narrowing the search at index time, Splunk must scan and filter events at search time, slowing results.

Why this answer

A high 'scanned_count' alongside a high 'event_count' means Splunk is reading many events from disk even though the time range is small — the search is not narrowing the dataset with an indexed field (like index, sourcetype, host, or source) before the base search runs. Without an indexed filter, Splunk must scan raw buckets and apply filtering at search time, which is far slower. Adding an indexed field to the base search dramatically reduces scanned_count.

Exam trap

SPLK-2002 often tests the misconception that slow searches are always a hardware or acceleration problem — the real diagnostic signal is the scanned_count-to-event_count ratio, which points to missing indexed-field filters.

How to eliminate wrong answers

Option A is wrong because excess indexer memory does not cause high scanned_count — memory pressure would show as search queueing or bucket replication issues, not as excessive events being read. Option B is wrong because data model acceleration failures affect tstats-based searches and would show acceleration-related errors, not a raw scanned_count problem in a base search. Option D is wrong because an underpowered search head affects dispatch and post-processing speed but does not inflate scanned_count — scanned_count is determined by how much data the indexers must read, which is a search-construction issue.

Practice this question →
10
MCQmedium

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

A.It consumes significant memory on the search head
B.It requires data to be fully ingested before searching
C.It causes high disk I/O on the indexer
D.It disables parallel processing
AnswerA

The join command builds the entire subsearch result set in memory on the search head before matching, so large datasets exhaust RAM and can trigger search failures. This memory-bound behaviour is its primary resource drawback compared with streaming alternatives such as stats or lookup.

Why this answer

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.

Exam trap

SPLK-2002 often tests the misconception that join's cost is on the indexers (disk I/O) rather than on the search head's memory, or that join is a streaming command when it is actually blocking.

How to eliminate wrong answers

Option B is wrong because join does not require full ingestion; it operates on already-indexed events at search time, and ingestion is independent of the join command. Option C is wrong because join's bottleneck is search head memory, not indexer disk I/O; the indexers simply return events as usual. Option D is wrong because join does not disable parallel processing — Splunk's map/reduce search pipeline still runs, though the join itself is a blocking operation that can serialize the merge phase.

Practice this question →
11
Multi-Selecthard

Which TWO factors must be considered when balancing resource allocation between search and indexing?

Select 2 answers
A.Number of forwarders
B.Web UI accessibility
C.App installation count
D.Disk I/O contention
E.Search and indexing CPU competition
AnswersD, E

Both search and indexing read and write to the same underlying storage, so heavy indexing can saturate disk throughput and degrade search latency. Disk I/O contention is therefore a factor that must be considered when balancing resource allocation between the two.

Why this answer

Disk I/O contention (D) is a correct factor because search queries read index buckets from disk while indexing writes and merges bucket data, so both workloads compete for the same storage throughput and IOPS, directly affecting performance balance. Search and indexing CPU competition (E) is also correct because search processes (such as search heads running the search pipeline) and indexing processes (such as indexers parsing, merging, and writing events) both consume CPU cycles, so allocating CPU between them determines how quickly searches return versus how fast data is indexed. The other options do not belong: the number of forwarders (A) affects ingest volume and licensing but is not itself a resource-balancing factor between search and indexing, web UI accessibility (B) is a client access concern unrelated to resource contention, and app installation count (C) is a configuration/management metric that does not directly govern the search-versus-indexing resource tradeoff.

Exam trap

SPLK-2002 often tests the confusion between factors that influence resource consumption (like number of forwarders) and the actual resources that compete (CPU, disk I/O), leading candidates to select forwarder count as a balancing factor.

Practice this question →
12
MCQmedium

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

A.Enables the indexer to bypass the parsing queue
B.Allows the indexer to optimize disk I/O by isolating active writing to a single bucket
C.Increases the size of the bucket for better compression
D.Reduces the requirement for indexes to be searchable
AnswerB

Bucket rolling closes the current hot bucket and opens a new one, so all incoming writes target a single active bucket. This isolates write I/O from the many older, read-only buckets, reducing disk contention and improving indexing throughput.

Why this answer

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.

Exam trap

SPLK-2002 often tests whether candidates confuse bucket rolling with parsing or compression, when the real purpose is write isolation and I/O optimization.

How to eliminate wrong answers

Option A is wrong because bucket rolling has nothing to do with the parsing queue; parsing happens in the parsing pipeline before events are written to buckets. Option C is wrong because bucket rolling does not increase bucket size for compression — bucket size is governed by maxDataSize in indexes.conf, and rolling actually closes buckets at that limit. Option D is wrong because bucket rolling does not reduce searchability requirements; all buckets remain searchable regardless of whether they are hot, warm, cold, or frozen.

Practice this question →
13
MCQeasy

What is the impact of placing a very high number of indexes on a single indexer?

A.Increased file handle usage and potential performance degradation
B.Reduced licensing costs
C.Improved search speed
D.Faster data ingestion
AnswerA

Each index on an indexer consumes file handles and search resources. A very high index count therefore increases file handle usage and can degrade search performance, as the indexer must manage and search across many separate index buckets.

Why this answer

Placing a very high number of indexes on a single indexer increases the number of open file handles because each index maintains multiple bucket files (rawdata, tsidx, etc.). This can lead to file handle exhaustion, increased memory usage for bucket metadata, and overall performance degradation, especially during search and indexing.

Exam trap

SPLK-2002 often tests the misconception that more indexes improve performance or reduce costs, when in reality they increase resource consumption and can degrade performance.

How to eliminate wrong answers

Option B is wrong because licensing costs are based on daily indexed volume, not the number of indexes; more indexes do not reduce license costs. Option C is wrong because more indexes typically slow down searches due to increased metadata overhead and bucket management, not improve speed. Option D is wrong because ingestion speed is not improved by having more indexes; in fact, excessive indexes can slow ingestion due to resource contention.

Practice this question →
14
MCQmedium

What is the effect of using the 'tstats' command in a search?

A.It increases the number of concurrent searches allowed
B.It bypasses the parsing queue
C.It queries the TSIDX files directly, improving speed
D.It forces the use of more CPU cores
AnswerC

The tstats command reads indexed fields directly from TSIDX files instead of raw events, bypassing the slower event-retrieval and field-extraction stages. This satisfies the speed requirement by querying pre-computed index structures, making aggregations over large datasets substantially faster.

Why this answer

The tstats command queries the TSIDX (time-series index) files directly, which store indexed field-value pairs and metadata. By bypassing the raw event data and using the TSIDX, tstats can return results much faster than regular search commands, especially for statistical queries on indexed fields. This makes it ideal for large-scale data analysis where speed is critical.

Exam trap

SPLK-2002 often tests the internal mechanism of tstats; candidates may think it bypasses the parsing queue or increases concurrency, but the key is that it queries TSIDX files directly for speed.

How to eliminate wrong answers

Option A is wrong because tstats does not increase the number of concurrent searches allowed; that is controlled by the search head's limits.conf and resource usage. Option B is wrong because tstats does not bypass the parsing queue; it still goes through the search pipeline, but it reads from TSIDX instead of raw data. Option D is wrong because tstats does not force the use of more CPU cores; it is optimized for efficiency, not for parallel CPU utilization.

Practice this question →
15
Multi-Selecteasy

Which TWO actions can improve the performance of a Splunk search head?

Select 2 answers
A.Adding more nodes to a search head cluster
B.Reducing the number of forwarders
C.Increasing the license volume
D.Disabling the indexer cluster
E.Increasing the system memory on the search head
AnswersA, E

Adding nodes distributes search workload across more peers, so concurrent searches and heavy jobs run in parallel rather than queuing on one search head. This directly addresses the stem's performance constraint by increasing aggregate search capacity.

Why this answer

Option A is correct because adding more nodes to a search head cluster distributes the search workload across multiple search heads, allowing concurrent searches to be parallelized and reducing the load on any single node, which directly improves search performance and scalability. Option E is correct because increasing system memory on the search head allows more search artifacts, result sets, and in-memory operations (such as those used by the search scheduler and knowledge objects) to be cached, reducing disk I/O and speeding up search execution. Option B is not correct because reducing the number of forwarders decreases data ingestion, not search performance, and may actually reduce the data available for searches.

Option C is not correct because increasing license volume only allows more data to be indexed per day; it does not improve search speed or search head performance. Option D is not correct because disabling the indexer cluster would remove data replication and distributed search capabilities, harming availability and performance rather than improving it.

Exam trap

SPLK-2002 often tests the distinction between scaling ingestion (forwarders, license) and scaling search execution (SHC nodes, search head RAM), so candidates mistakenly pick forwarder or license options that affect indexing, not search performance.

Practice this question →
16
Multi-Selecteasy

Which TWO areas should be checked when troubleshooting slow data ingestion?

Select 2 answers
A.License master usage
B.Parsing queue fill percentage
C.User authentication speed
D.Search head memory usage
E.Output queue fill percentage
AnswersB, E

A filling parsing queue shows that incoming raw data exceeds the parsing pipeline's throughput, typically from heavy props, transforms or regex. Monitoring this percentage pinpoints the ingestion stage causing the slowdown, satisfying the troubleshooting requirement to locate the constrained queue.

Why this answer

When troubleshooting slow data ingestion, the parsing queue fill percentage (B) must be checked because the parsing queue sits between the indexer's input pipeline and the aggregation stage; if it fills up, events back up and ingestion throughput drops, indicating parsing or indexer processing is the bottleneck. The output queue fill percentage (E) should also be checked because the output queue feeds events from the parsing/aggregation stage to the indexing pipeline; a high fill percentage signals that indexing (disk I/O, bucket creation) cannot keep up, throttling ingestion. License master usage (A) is not a per-ingestion performance metric — license violations block or warn on ingestion volume but do not directly explain slow throughput.

User authentication speed (C) affects search/login latency, not the data ingestion pipeline. Search head memory usage (D) is relevant to search performance and knowledge object execution, not to indexer-side ingestion speed.

Exam trap

SPLK-2002 often tests the confusion between search-related performance (search head memory, authentication) and ingestion-related performance (parsing and output queues), leading candidates to pick irrelevant options.

Practice this question →
17
MCQeasy

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

A.Search Head Activity
B.Data Ingestion Performance
C.Resource Usage: Forwarders
D.Indexer Activity
AnswerA

Search Head Activity reports per-search-head resource usage, including CPU, memory and disk consumption, letting you compare load across the search head tier. It directly satisfies the stem's requirement for a per-search-head view of resource consumption rather than cluster-wide or indexer-focused metrics.

Why this answer

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

Exam trap

SPLK-2002 often tests whether candidates know which Monitoring Console dashboard maps to which tier — Search Head Activity for search heads, Indexer Activity for indexers, and Resource Usage: Forwarders for forwarders — so candidates who pick a dashboard by name similarity rather than tier focus get it wrong.

How to eliminate wrong answers

Option B is wrong because Data Ingestion Performance focuses on indexing throughput and pipeline performance, not search head resource consumption. Option C is wrong because Resource Usage: Forwarders reports on universal forwarder resource usage, not search heads. Option D is wrong because Indexer Activity covers indexer-tier metrics such as indexing rate, bucket activity, and disk usage, not search head resources.

Practice this question →
18
MCQhard

If a search head is overloaded with concurrent searches, what is the best strategy to offload the processing?

A.Increase the number of indexers
B.Reduce the number of users
C.Increase indexer memory
D.Implement a Search Head Cluster
AnswerD

A search head cluster distributes search workload across multiple search head members, so concurrent searches are spread rather than queued on one overloaded node. This satisfies the stem's requirement to offload processing while preserving a single search experience.

Why this answer

A Search Head Cluster distributes search workload across multiple search head members, allowing concurrent searches to be load-balanced and providing horizontal scaling for search processing. This directly addresses an overloaded single search head by adding capacity and redundancy. Increasing indexers or indexer memory addresses indexing/search execution at the indexer layer, not the search head's concurrency bottleneck.

Exam trap

SPLK-2002 often tests the misconception that adding indexers fixes search head overload; the search head is the concurrency bottleneck, and SHC is the correct scaling solution.

How to eliminate wrong answers

Option A is wrong because adding indexers increases indexing and search execution capacity but does not relieve the search head's role as the search coordinator and result aggregator. Option B is wrong because reducing users is a business constraint, not a technical scaling strategy. Option C is wrong because indexer memory helps search execution on indexers but does not solve search head concurrency limits.

Practice this question →
19
MCQmedium

You are analyzing search performance using the Search Activity dashboard. You observe that 'Result Count' is extremely high for a specific saved search. Which optimization technique is most effective to reduce the load on the indexer?

A.Increase the memory allocation for the search head
B.Disable data model acceleration for the index
C.Use the | table command at the start
D.Use specific time ranges and selective filters at the beginning of the search
AnswerD

Applying specific time ranges and selective filters first reduces the volume of events retrieved from the indexers before the search pipeline runs. This directly addresses the high Result Count by shrinking the scanned dataset, cutting indexer load far more effectively than later-stage tuning.

Why this answer

To reduce the load on the indexer when a saved search returns an extremely high result count, the most effective optimization is to use specific time ranges and selective filters at the beginning of the search. This reduces the amount of data that the indexer must scan and process, directly lowering the load. Other options either do not address indexer load or are incorrect.

Exam trap

SPLK-2002 often tests search optimization techniques, and candidates may confuse search head memory with indexer load, or think that '| table' can be used early to reduce data.

How to eliminate wrong answers

Option A is wrong because increasing memory allocation for the search head does not reduce indexer load; it may improve search head performance but the indexer still processes the same amount of data. Option B is wrong because disabling data model acceleration would likely increase search load and slow down searches that rely on data models, not reduce it. Option C is wrong because using '| table' at the start of a search is not valid syntax; 'table' is a transforming command that should be used after the base search, and placing it early does not reduce indexer load.

Practice this question →
20
MCQmedium

What is the impact of having too many small buckets in an index?

A.Faster data rolling
B.Reduced disk space usage
C.Degraded search performance due to high overhead
D.Improved search performance
AnswerC

Excessive small buckets inflate the index's bucket count, forcing the search head to open and scan far more bucket metadata and TSIDX files per query. This overhead directly degrades search performance, satisfying the stem's constraint that bucket proliferation, not raw data volume, is the limiting factor.

Why this answer

Having too many small buckets in an index degrades search performance because each bucket must be opened and processed separately, leading to high overhead in terms of file handles, memory, and search initialization. Splunk searches across many small buckets require more resources and time compared to fewer, larger buckets. This is a common issue when buckets are rolled frequently due to small size limits.

Exam trap

SPLK-2002 often tests the relationship between bucket size and search performance; candidates may think smaller buckets are faster because they contain less data, but the overhead of many buckets outweighs the benefit.

How to eliminate wrong answers

Option A is wrong because faster data rolling is not an impact of having too many small buckets; in fact, too many small buckets may indicate that rolling is happening too frequently, which is a symptom, not a benefit. Option B is wrong because reduced disk space usage is not true; many small buckets can actually increase disk space usage due to per-bucket overhead (metadata, indexes). Option D is wrong because improved search performance is the opposite of what happens; search performance degrades.

Practice this question →
21
Multi-Selecthard

Which THREE factors commonly cause high CPU utilization on indexers?

Select 3 answers
A.Excessive data model acceleration jobs
B.Complex, inefficient search queries
C.Network latency between indexers
D.Low disk space
E.High ingestion volume
AnswersA, B, E

Background summary searches are CPU intensive.

Why this answer

Option A is correct because data model acceleration runs scheduled searches that build and periodically rebuild summary datasets on the indexer, and these background jobs consume significant CPU cycles, especially with many accelerated models. Option B is correct because complex or inefficient search queries (heavy use of wildcards, large time ranges, expensive commands like transaction, join, or stats) force the indexer to process large volumes of events and drive CPU utilization up. Option E is correct because high ingestion volume increases parsing, indexing, and pipeline processing work on the indexer, which is CPU-intensive and scales directly with the amount of incoming data.

Option C does not belong because network latency affects search dispatch and data transfer speeds, not indexer CPU consumption. Option D does not belong because low disk space causes indexing to pause or block and triggers disk-related warnings, but it does not itself raise CPU utilization.

Exam trap

SPLK-2002 often tests the confusion between resource bottlenecks — candidates pick network latency or disk space thinking any resource constraint causes CPU spikes, when the question specifically asks about CPU utilization drivers.

Practice this question →
22
MCQmedium

To optimize search performance, which feature should be enabled to allow Splunk to pre-calculate results for specific reports?

A.Summary indexing
B.Search acceleration
C.Parallel ingestion
D.Indexer clustering
AnswerB

Search acceleration pre-computes report results into summary indexes, so subsequent runs of the same report return cached data instead of re-scanning raw events. This directly satisfies the stem's requirement to pre-calculate results for specific reports, cutting search time and resource consumption.

Why this answer

Search acceleration (also called report acceleration) uses precomputed summaries stored in the index to speed up searches that match a saved report's base search. When enabled on a saved report, Splunk builds and maintains summary data so subsequent runs of that report or similar searches return results much faster. This is the feature specifically designed to pre-calculate results for reports.

Exam trap

SPLK-2002 often tests the distinction between summary indexing (manual, scheduled, writes to a summary index) and report acceleration (automatic, precomputed, tied to a saved report).

How to eliminate wrong answers

Option A is wrong because summary indexing is a manual method where you schedule a search to write results into a separate summary index using collect or si- commands; it is not an automatic pre-calculation feature tied to a report definition. Option C is wrong because parallel ingestion refers to ingesting data from multiple sources concurrently and has no bearing on pre-calculating report results. Option D is wrong because indexer clustering provides data replication and availability, not search result pre-calculation.

Practice this question →
23
Multi-Selectmedium

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

Select 3 answers
A.Memory usage
B.Number of active apps
C.Number of logged-in users
D.Disk I/O latency
E.CPU utilization
AnswersA, D, E

Memory usage exposes indexer resource pressure: sustained high heap consumption triggers search-time degradation and can cause queue backup. Monitoring Console tracks this per indexer instance, letting you scale or rebalance before ingestion latency breaches the pipeline's throughput requirement.

Why this answer

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.

Exam trap

SPLK-2002 often tests the difference between indexer health metrics and search head or general metrics, so candidates might incorrectly select user counts or app counts, which are not critical for indexer performance.

Practice this question →
24
Multi-Selecteasy

Which TWO items are stored in the index directory?

Select 2 answers
A.License master keys
B.TSIDX files
C.Raw data files (compressed)
D.Search logs
E.App configuration files
AnswersB, C

TSIDX files hold the time-series index that maps timestamped buckets to raw events, enabling Splunk to locate data within a specified time range. They reside in the index directory alongside bucket metadata, not in the search head or configuration directories.

Why this answer

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.

Exam trap

SPLK-2002 often tests the confusion between what lives in the index directory versus $SPLUNK_HOME/etc or var/log, so candidates incorrectly select configuration or log files as indexed data.

Practice this question →
25
MCQmedium

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

A.Allows for faster data ingestion without resource constraints
B.Improves search speed by reducing data density
C.Increases indexing latency due to synchronous replication requirements
D.Decreases indexer storage requirements
AnswerC

A higher replication_factor forces each bucket to be copied to more peer indexers synchronously before indexing is acknowledged, so latency rises. This satisfies the stem's constraint that replication is synchronous, directly increasing indexing latency rather than throughput.

Why this answer

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.

Exam trap

SPLK-2002 often tests the trade-off between replication_factor and performance; candidates incorrectly assume higher replication improves speed or reduces storage, when it actually increases latency and storage usage.

How to eliminate wrong answers

Option A is wrong because a high replication factor does not allow faster ingestion; it adds replication overhead and resource consumption, slowing ingestion. Option B is wrong because replication factor does not affect search speed by reducing data density; search speed is influenced by search factor and bucket distribution, not replication factor. Option D is wrong because a higher replication factor increases storage requirements (more copies), not decreases them.

Practice this question →
26
MCQeasy

Which Splunk process is responsible for managing the indexer's disk I/O and bucket lifecycle?

A.splunkd
B.mongod
C.python
D.kvstore
AnswerA

splunkd is the single daemon managing all indexer operations, including disk I/O scheduling and the hot-to-warm-to-cold bucket lifecycle transitions. It satisfies the stem's requirement by being the process that owns both responsibilities, rather than a separate helper binary.

Why this answer

splunkd is the main Splunk daemon process that runs on all Splunk instances, including indexers, and is responsible for managing indexing, search, and various background tasks such as disk I/O and bucket lifecycle management. It handles the rolling of buckets from hot to warm to cold to frozen, as well as disk space monitoring.

Exam trap

SPLK-2002 often tests process responsibilities, and candidates may confuse splunkd with mongod or kvstore, especially since KV Store is prominent in Splunk 8.x and later.

How to eliminate wrong answers

Option B is wrong because mongod is the MongoDB process used by Splunk for the KV Store, which stores app configurations and lookups, not indexer disk I/O or bucket lifecycle. Option C is wrong because python is used for running Python-based scripts and custom search commands, not for managing indexer disk I/O. Option D is wrong because kvstore is a feature (backed by mongod) for storing key-value data, not a process that manages disk I/O or bucket lifecycle.

Practice this question →
27
MCQeasy

Which configuration file is used to specify the disk path where index buckets are stored?

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

`indexes.conf` defines per-index storage settings, including `homePath` and `coldPath`, which set the disk paths where hot/warm and cold buckets reside. This directly satisfies the stem's requirement to specify the bucket storage location, since `server.conf` handles instance-level settings and `props.conf` governs parsing rather than index paths.

Why this answer

The indexes.conf file is the central configuration file for defining and managing indexes in Splunk. Within each index stanza, the 'homePath' setting specifies the directory where the index's hot and warm buckets are stored, and 'coldPath' specifies where cold buckets are stored. Therefore, indexes.conf is the correct file to specify the disk path for index buckets.

Exam trap

SPLK-2002 often tests the confusion between configuration files for data input, output, and indexing, leading candidates to mistakenly choose inputs.conf or outputs.conf when asked about index storage paths.

How to eliminate wrong answers

Option A is wrong because server.conf is used for general server settings such as server name, licensing, and clustering configuration, not for specifying index storage paths. Option B is wrong because outputs.conf configures forwarding destinations and data output settings, not index storage locations. Option C is wrong because inputs.conf defines data inputs and sources, not where index buckets are stored on disk.

Practice this question →
28
MCQeasy

Which tool is best for monitoring the health and performance of the entire Splunk environment?

A.Splunk CLI
B.Deployment Server
C.Monitoring Console
D.Splunk Web UI
AnswerC

Monitoring Console is Splunk's built-in tool for tracking health and performance across all components — indexers, search heads and forwarders — from one dashboard. It satisfies the stem's requirement to monitor the entire environment, unlike single-instance tools such as the search head's job inspector or the CLI.

Why this answer

The Monitoring Console (formerly known as the Distributed Management Console) is Splunk's built-in tool specifically designed to monitor the health, performance, and topology of an entire Splunk deployment. It provides dashboards for indexing, search, resource usage, and license usage across all components. It is the recommended tool for holistic environment monitoring.

Exam trap

The trap here is confusing the Monitoring Console with the general Splunk Web UI or the Deployment Server, as candidates may think any centralized interface can monitor health, but only the Monitoring Console is purpose-built for that.

How to eliminate wrong answers

Option A is wrong because the Splunk CLI is used for configuration, administration, and troubleshooting individual instances, not for holistic health monitoring of the entire environment. Option B is wrong because the Deployment Server is used to push configurations and apps to forwarders, not to monitor health. Option D is wrong because the Splunk Web UI is a general interface for searching and administration, but it does not provide the centralized health monitoring dashboards that the Monitoring Console offers.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Performance Tuning questions.

Start 20-question session