Free SPLK-2002 Practice Test Questions 2026

Explanation:

Splunk Search Head Clustering (SHC) is a feature that provides high availability, scalability, and knowledge object replication across multiple search heads. To function correctly, SHC requires certain architectural components and hardware standards.

A. A deployer is required → Correct
The deployer is a Splunk instance that manages and pushes configuration bundles to all search head cluster members. It is mandatory in SHC setups. Without a deployer, configuration consistency across the cluster cannot be maintained.

B. At least three search heads are needed → Incorrect
While three search heads are recommended for production to ensure quorum and fault tolerance, technically SHC can be formed with as few as two members. The exam nuance here is that “at least three” is not a strict requirement, but a best practice.

C. Search heads must meet the high‑performance reference server requirements → Correct
Splunk requires that search heads in a cluster meet high‑performance reference server specifications. This ensures they can handle the workload of distributed searches, replication, and captain election. Underpowered servers can cause instability.

D. The deployer must have sufficient CPU and network resources to process service requests and push configurations → Incorrect
The deployer does not process search service requests. Its role is limited to pushing configurations. While it needs enough resources to perform bundle pushes, it does not require high CPU/network capacity like search heads.

references
Splunk Docs – Deployer in search head clustering
Splunk Docs – Reference hardware requirements

Explanation:

When installing Splunk Enterprise Security (ES) in a Search Head Cluster (SHC) environment, the process must follow Splunk’s documented best practices to ensure consistency across all cluster members.

A. Install Enterprise Security on the deployer → Correct
The deployer is the Splunk instance responsible for managing and pushing configuration bundles to all search head cluster members. ES must be installed on the deployer so its configurations can be distributed consistently.

B. Install Enterprise Security on a staging instance → Incorrect
A staging instance is not part of the supported installation workflow for ES in SHC. ES must be installed on the deployer, not on a separate staging server.

C. Copy the Enterprise Security configurations to the deployer → Incorrect
You do not manually copy ES configurations. Instead, you install ES directly on the deployer, which then manages the distribution of configurations. Manual copying is unsupported and error‑prone.

D. Use the deployer to deploy Enterprise Security to the cluster members → Correct
After ES is installed on the deployer, you use the deployer to push the ES configurations to all search head cluster members. This ensures uniformity and proper functioning of ES across the cluster.

References
Splunk Docs – Install Enterprise Security on a search head cluster
Splunk Docs – Search head cluster deployer

Explanation:

When decommissioning a site in a multi‑site indexer cluster, Splunk requires you to update the master node’s server.conf file to reflect the new site topology. The attribute that must be added or modified is site_mappings.
site_mappings defines the mapping between logical site names (e.g., site1, site2) and the physical sites in the cluster.
When a site is decommissioned, you update this attribute so the cluster master no longer recognizes the removed site.
This ensures that replication and search factors are applied only to the remaining active sites.

Why the other options are not correct

B. available_sites → Incorrect This attribute lists sites available for replication, but it is not the one used to decommission a site. The authoritative mapping is controlled by site_mappings.

C. site_search_factor → Incorrect This defines how many searchable copies of each bucket must exist across sites. It does not control site removal.

D. site_replication_factor → Incorrect This defines how many total copies of each bucket must exist across sites. Again, it does not handle site decommissioning.

References
Splunk Docs – Decommission a site in a multisite indexer cluster

Explanation:

In Splunk, a search job is the execution of a search query. Whenever a user runs a search—whether ad‑hoc, scheduled, or triggered by a report or alert—Splunk creates a search job. These jobs are tracked, managed, and subject to quotas to ensure fair resource allocation across users and processes.

B. Searches that are subjected to some usage quota → Correct
Splunk jobs are governed by quotas defined in configuration files such as limits.conf. These quotas restrict the number of concurrent searches per user, per role, or per CPU core. This prevents resource exhaustion and ensures stability in multi‑user environments. Jobs are therefore directly tied to quota enforcement, making this statement correct.

C. A search process kicked off via a report or an alert → Correct
Scheduled reports and alerts initiate searches automatically. Each of these executions creates a search job that Splunk tracks until completion. This is a fundamental part of Splunk’s job management system, as jobs can be monitored, paused, or terminated. Thus, jobs are indeed search processes triggered by reports or alerts.

Why the other options are not correct

A. A user‑defined Splunk capability → Incorrect
Capabilities in Splunk are permissions assigned to roles (e.g., schedule_search, edit_user). They define what a user can or cannot do. A job is not a capability—it is the execution of a search. This option confuses Splunk’s role‑based access control with search job management.

D. A child OS process manifested from the splunkd process → Incorrect
While searches are executed by processes under splunkd, a Splunk job is not defined as an operating system process. A job is a logical construct within Splunk’s search management framework, tracked by the job inspector and subject to quotas. The OS process is a technical implementation detail, not the definition of a job.

Why B and C are Correct
Jobs are always tied to quotas (B), ensuring controlled concurrency.
Jobs are created whenever a report or alert runs a search (C).
Together, these definitions capture the operational and functional essence of Splunk jobs.

References
Splunk Docs – Manage search jobs
Splunk Docs – limits.conf

Explanation:
Splunk’s metrics.log file is a critical diagnostic log that records operational statistics about the Splunk instance. Among the information it captures is license utilization, which helps administrators monitor how much license volume is being consumed over time. By default, Splunk writes these periodic reports at a fixed interval of 30 seconds.

This interval is chosen to balance timeliness with efficiency. A shorter interval would generate excessive log entries and increase overhead, while a longer interval would reduce visibility into license consumption trends. Thirty seconds provides administrators with near‑real‑time monitoring without overwhelming the logging system.

When Splunk generates these entries, they include details such as:
License usage statistics (volume indexed).
Search activity metrics.
Resource utilization data.
Administrators can use these logs to troubleshoot skipped searches, monitor ingestion rates, and ensure compliance with license limits.

Why the other options are not correct

A. 10 seconds → Incorrect Splunk does not log license utilization this frequently. Ten seconds would be too aggressive, leading to unnecessary overhead and excessive log volume.

C. 60 seconds → Incorrect While one minute might seem reasonable, Splunk’s documented default is 30 seconds. Setting it to 60 seconds would reduce the granularity of monitoring and delay visibility into license usage.

D. 300 seconds → Incorrect Five minutes is far too long for default reporting. This would significantly delay detection of license spikes or ingestion anomalies. Splunk provides more granular reporting by default to ensure administrators can act quickly.

Why B is Correct
Splunk documentation explicitly states that metrics.log generates license utilization reports every 30 seconds by default.
This interval ensures administrators have frequent updates without overwhelming the system.
It provides a balance between operational efficiency and monitoring accuracy.

References
Splunk Docs – metrics.log reference
Splunk Docs – License usage reporting

Explanation:
Splunk indexes, including internal ones like _internal, _audit, and _introspection, are where all the processed and compressed event data is stored on disk. This data is distinct from the executable program files, temporary runtime files, or static configuration files. The default path is designed to keep the often-large and growing index data within the main Splunk directory structure but separate from the core application binaries and configurations.

Correct Option:

B. SPLUNK_HOME/var/lib:
This is the correct default location. Under this directory, you will find the splunk subdirectory, which contains the individual index directories (e.g., _internal, _audit, main). Each index directory contains the "buckets" of hot, warm, and cold data that make up the indexed events.

Incorrect Options:

A. SPLUNK_HOME/bin:
This directory contains the Splunk binary executable files and other core program files required to run the software. It does not contain any user or internal indexed data.

C. SPLUNK_HOME/var/run:
This directory is used for temporary runtime files, such as process ID (PID) files. It is not used for the persistent storage of indexed data.

D. SPLUNK_HOME/etc/system/default:
This directory contains the default version of all configuration files. These are static files that are read to establish baseline settings and are never written to during normal operation. Index data is not stored here.

Reference:
Splunk Enterprise Admin Manual: "Indexes and indexers overview". The documentation states that by default, Splunk software stores indexed data in $SPLUNK_HOME/var/lib/splunk. The path for each index can be customized in indexes.conf.

Explanation:
The question asks for the minimum reference hardware specification for a Splunk indexer. Splunk provides reference architectures to guide sizing for expected data volumes and workloads. The minimum specification is designed for a single instance handling a moderate ingestion rate and is the baseline starting point for planning a deployment. It balances performance and cost for standard use cases, ensuring the core indexing and search functions operate effectively without over-provisioning resources.

Correct Option:

A. 12 CPU cores, 12GB RAM, 800 IOPS:
This is the correct minimum reference specification. It is sufficient for a standalone indexer or a small cluster handling up to an average of 100 GB of data ingestion per day. The 12 CPU cores manage indexing and searching, 12GB RAM supports in-memory operations, and 800 IOPS is the baseline for disk throughput to prevent I/O bottlenecks.

Incorrect Options:

B. 16 CPU cores, 16GB RAM, 800 IOPS:
While this is a valid specification, it is not the minimum. It represents a more powerful configuration, often recommended for heavier search loads or higher data volumes, exceeding the baseline requirement stated in the question.

C. 24 CPU cores, 16GB RAM, 1200 IOPS:
This configuration is significantly more powerful and aligns with reference specs for heavier workloads, such as those found in larger distributed environments or for indexers ingesting several hundred GB per day.

D. 28 CPU cores, 32GB RAM, 1200 IOPS:
This is an enterprise-grade specification, typically reserved for heavy search heads, cluster master nodes, or indexers in very high-volume environments. It far exceeds the "minimum" requirement.

Reference:
Splunk Enterprise Capacity Planning Manual: "Reference hardware". This document outlines the minimum (12 cores, 12GB RAM) and recommended hardware specifications based on expected data ingestion rates and user concurrency.

Explanation:
This question tests knowledge of the standard Splunk Search Head Cluster deployment process for adding new members. A new cluster member must first be a functioning, initialized Splunk instance before it can be introduced to the SHC. Deleting the existing instance after initialization is a common step only if the instance was previously used in an undesirable configuration, but the core steps focus on setting up the instance and then joining the cluster. The most critical step is joining the cluster after initialization.

Correct Option:

B. 1. Install and initialize the instance. 2. Delete Splunk Enterprise, if it exists. 3. Join the SHC.
1. Install and initialize the instance: The new server must first have Splunk Enterprise installed and the instance initialized (running on the specified ports) to be a functional member candidate.

2. Delete Splunk Enterprise, if it exists: This specific step (deleting the instance if it exists) is a redundant/cleanup step usually applied to ensure a completely clean installation before joining. The core process is (1) Install/Init and (3) Join. If it's a new machine, this step is skipped.

3. Join the SHC: The final and most important step is running the appropriate splunk init shcluster-member command followed by a restart to join the instance to the existing cluster via the deployer or a current member.

Incorrect Options:

A. 1. Delete Splunk Enterprise, if it exists. 2. Install and initialize the instance. 3. Join the SHC.
While these steps are similar to B, deleting Splunk first is only necessary if you are repurposing an existing machine. For a fresh install, this is an unnecessary first step. The standard, reliable sequence prioritizes setting up the necessary software (Install/Initialize) before any cluster operations.

C. 1. Initialize cluster rebalance operation. 2. Remove master node from cluster. 3. Trigger replication.
This sequence describes steps primarily used when decommissioning/removing a member or managing replication on the Index Cluster (Index Cluster Master Node), not the Search Head Cluster (SHC). The SHC uses a Deployer and a Captain, not a "master node" for daily operations like this.

Reference:
Splunk Documentation: Add a new member to the search head cluster Concept: Search Head Cluster Deployment Process

Explanation:
The SPLK-2002 exam emphasizes that a successful Splunk Enterprise deployment must begin with a clear understanding of business goals, technical needs, compliance requirements, and stakeholder expectations. Without first collecting and documenting requirements, any subsequent planning (sizing, app selection, or infrastructure inventory) risks being misaligned with actual needs, leading to costly rework later.

Correct Option:

D. Collect the initial requirements for the deployment from all stakeholders
Collecting requirements is universally recognized as the foundational first step in Splunk’s recommended deployment methodology (Splunk Validated Architectures and professional services approach). It defines success criteria, identifies data sources of interest, sets retention/compliance needs, and clarifies user access and security requirements before any technical decisions are made.

Incorrect Option:

A. Inventory the currently deployed logging infrastructure.
While inventorying existing logging is important, it is a later step (typically in the “Discovery” phase after requirements are known). Doing it first risks focusing on “what exists” rather than “what is needed,” potentially leading to an architecture that simply replicates current limitations instead of meeting business goals.

B. Determine what apps and use cases will be implemented.
Apps and use cases cannot be accurately chosen until requirements are gathered. Stakeholders may need specific outcomes (PCI compliance, IT operations, security use cases, etc.) that dictate which apps (ES, ITSI, etc.) are appropriate. Starting here puts the cart before the horse.

C. Gather statistics on the expected adoption of Splunk for sizing.
Sizing requires knowledge of data volume, retention policies, number of users, and search concurrency—all of which are derived from requirements. Without documented requirements, any sizing exercise is based on guesses and will likely be inaccurate.

Reference:
Splunk Validated Architectures (SVA) – Planning & Design phase

Explanation:
This question asks for the primary Splunk tool designed to give administrators a real-time, centralized view of their deployment's health. While other tools can provide diagnostic data, only one is built specifically for ongoing health monitoring and alerting. It provides a comprehensive dashboard covering resource usage, indexing performance, search activity, and alert status across the entire deployment, making it the go-to for proactive health checks.

Correct Option:

D. Monitoring Console:
This is the dedicated tool for performing a health check. It provides a unified, web-based interface with pre-built dashboards that visualize the health and performance of all Splunk components (indexers, search heads, forwarders, etc.). Administrators use it to monitor system metrics, track resource utilization, and receive alerts on potential issues in real-time.

Incorrect Options:

A. btool:
This is a command-line troubleshooting tool used to diagnose configuration file issues. It shows which settings are active by merging the contents of default and local configuration files, but it does not provide a holistic health overview of the deployment's performance.

B. DiagGen (Diagnostics Generator):
This tool collects log files and configuration data into a tarball for offline analysis, typically for Splunk Support. It is a data-gathering tool for specific troubleshooting cases, not a real-time health monitoring dashboard.

C. SPL Clinic:
This is a feature within Splunk that analyzes SPL (Search Processing Language) from dashboards and alerts to identify inefficiencies and suggest performance improvements. It focuses on search optimization, not overall system health.

Reference:
Splunk Documentation: "About the Monitoring Console". The official documentation describes the Monitoring Console as the tool that provides a system-wide view of your deployment's health, including key indicators for indexing, searching, and forwarding.

Explanation:
This scenario involves a field extraction that works for one user but not another on the same data. Field extractions in Splunk are knowledge objects, and their visibility can be restricted. Also, the Search Mode can impact which fields are automatically shown in the search results. Understanding the scope of knowledge objects (Private vs. Shared) and the difference between Fast and Verbose search modes is key to resolving this issue.

Correct Options:

A. The field was extracted as a private knowledge object.
A private knowledge object (extraction) is stored in the user's local directory ($SPLUNK_HOME/etc/users///local).

This means only the user who created it can see and use that specific field extraction in their searches.

The colleague would not have access to this private object, explaining why the src_ip field is missing from their search results, even though the events contain the data.

D. The colleague did not explicitly use the field in the search and the search was set to Fast Mode.
In Fast Mode, Splunk optimizes performance by focusing on time, basic fields (like host, source, sourcetype), and explicitly requested fields (e.g., fields used in a | table, | stats, or | fields command).

If the colleague is in Fast Mode and did not use the src_ip field, Splunk will not run the extraction automatically, making the field appear missing.

Switching to Verbose Mode or explicitly including the field in the search (e.g., | table src_ip) would resolve this.

Incorrect Options:

B. The events are tagged as communicate, but are missing the network tag.
Tags are used for data normalization (Splunk Common Information Model or CIM), not for the basic visibility of user-defined field extractions.

An event's tagging status does not affect whether a direct, user-created field extraction like src_ip is applied and displayed in the search results.

C. The Typing Queue, which does regular expression replacements, is blocked.
The Typing Queue is a low-level search component related to processing data prior to indexing, not runtime field extraction or display in the Search app.
While a blocked queue could potentially impact all searches, it would affect all users on that search head and would indicate a severe system issue, not a problem specific to one user's field visibility.

Reference:
Splunk Documentation: Manage knowledge object permissions and Search modes Concept: Knowledge Object Scope and Search Modes (Fast vs. Verbose)

Explanation:
When building a deployment plan, an architect focuses on the foundational infrastructure and strategic planning that will support the entire Splunk environment. This involves understanding the technical landscape to ensure performance, scalability, and security. The tasks are high-level and architectural, setting the stage for subsequent implementation steps like software installation, rather than being the implementation steps themselves.

Correct Options:

C. Inventory data sources:
This is a critical first step. The architect must identify all data sources (servers, network devices, applications), their data formats, volumes, and ingestion rates. This inventory directly influences the sizing of indexers, license requirements, and the overall topology of the deployment.

D. Review network topology:
This is essential for planning data flow, assessing potential bandwidth constraints, and ensuring secure communication between forwarders, indexers, and search heads. Understanding the network layout helps in placing Splunk components correctly to optimize performance and meet security policies.

Incorrect Options:

A. Use case checklist:
While defining use cases is a crucial part of the initial requirements gathering, creating a "checklist" is typically an output of that process, not a core architectural task for the deployment plan itself. The architect uses the use cases to inform the plan (e.g., "we need high-performance search for security, so we need a search head cluster"), but the task of listing them is more preparatory.

B. Install Splunk apps:
This is an implementation and configuration task that occurs after the deployment plan is built and the core Splunk platform is installed. The deployment plan outlines where and how apps will be deployed, but the physical installation is an operational step, not an architectural planning one.

Reference:
Splunk Enterprise Deployment Manual: "Plan your deployment". This documentation emphasizes that a successful deployment starts with planning, which includes identifying data sources and understanding the network environment to design a robust and scalable architecture.