SPLK-1003 · Domain 8 of 17

SPLK-1003 Domain 8: Distributed Search

Distributed Search, one of the three 10% topics, explains how a search head sends work to indexers acting as search peers, how peers and peer groups are configured, and which options scale the search tier as users and load grow.

Exam weight
10%
Official objectives
4
Estimated questions estimate
~6
Suggested study time estimate
6–9 hrs

About 10 min read Reviewed October 2026

Overview

Domain 8 has four official objectives: describe how distributed search works, explain the roles of the search head and search peers, configure a distributed search group and list search head scaling options. Distributed search splits a search into a map phase that runs on every peer against its local data and a reduce phase on the search head that merges the partial results. The search head also replicates a knowledge bundle to peers so they can apply the right field extractions and lookups.

At 10%, expect about six questions. You need to know how to add peers through Splunk Web, the CLI or distsearch.conf, how named groups target subsets of peers with splunk_server_group, and how independent search heads differ from search head clusters with a deployer and captain.

How it's tested

Questions describe a deployment with search heads and indexers and ask how a search runs, how to add or group peers, or how to scale the search tier for more users. Watch for distractors that mix indexer clustering with search head clustering or mention pooling.

  • Map and reduce

    You decide which part of a search runs on the peers and which runs on the search head.

  • Add or group peers

    You choose the Splunk Web step, CLI command or distsearch.conf stanza that adds peers or defines a group.

  • Scale the search tier

    A need such as high availability or more concurrent users is given and you pick the scaling option.

Reasoning it through

A team wants to search only the European indexers from one search head. The candidate defines a distributed search group in distsearch.conf, [distributedSearch:emea], listing those peers, then runs searches with splunk_server_group=emea. Building a separate search head cluster would be excessive, and indexer clustering does not limit which peers a search uses.

Objectives 4

Official objectives from the Splunk outline, in outline order.

8.1 Describe how distributed search worksMap-reduce search across peers and the knowledge bundle.
What it means
In distributed search, a search head parses a user's search and sends it to every configured peer. Each peer searches its own indexes and runs streaming commands locally, which is the map phase. Peers return partial results, and the search head runs transforming and other non-streaming commands to merge them, which is the reduce phase.
What to understand
The search head replicates a knowledge bundle, containing knowledge objects such as props, transforms and lookups, to peers so they can apply field extractions consistently. Large lookups can slow bundle replication. Search performance scales with the number of peers because each searches its own share of the data in parallel.
How it shows up
You identify where a part of a search runs or why a configuration on the search head affects peers.
Common confusion
Thinking indexed data is copied to the search head before it is searched.
8.2 Explain the roles of the search head and search peersCoordination versus data searching.
What it means
The search head manages user sessions, search scheduling, dashboards and knowledge objects, distributes searches and merges results. Search peers are indexers that store data and execute the search against it. A search head typically does not index data itself and should forward its own internal logs to the indexers.
What to understand
Peers do not need Splunk Web users or knowledge objects of their own because they receive the bundle. Search heads communicate with peers over the management port 8089. A peer can serve several search heads, and a search head can search many peers.
How it shows up
A task is described and you decide whether the search head or the peer performs it.
Common confusion
Expecting dashboards and saved searches to be created on the indexers.
8.3 Configure a distributed search groupAdding peers and defining named groups.
What it means
Peers are added on the search head in Settings, Distributed search, Search peers, with splunk add search-server and peer credentials, or in distsearch.conf. Adding a peer exchanges authentication keys. Named groups are defined in distsearch.conf with a [distributedSearch:<group>] stanza listing servers, and searches target them with splunk_server_group.
What to understand
Remote credentials used when adding a peer must belong to an admin on that peer. Groups do not change where data is stored; they only limit which peers a search queries. For indexer clusters, the search head connects to the cluster manager rather than adding peers individually.
How it shows up
You choose the configuration that limits searches to a subset of peers or adds a new peer.
Common confusion
Trying to add indexer cluster peers one by one instead of pointing the search head at the cluster manager.
8.4 List search head scaling optionsIndependent search heads and search head clusters.
What it means
To support more users and searches, you can add independent search heads that each search the same peers, or build a search head cluster. A cluster has three or more members, an elected captain that schedules jobs and replicates artifacts, and a deployer that distributes apps and configuration to members.
What to understand
Search head clustering gives high availability and shared knowledge objects; independent search heads are simpler but do not share content. Search head pooling is removed and should not be chosen. Indexer clustering protects data, not search head capacity, although search heads can search clustered indexers.
How it shows up
A requirement for capacity or availability is described and you choose the scaling option.
Common confusion
Selecting search head pooling or indexer clustering to scale the search tier.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Map phase

    Peers search local data and run streaming commands.

    Remember
    Work scales with the number of peers.
    Tested as
    Search execution questions.
    Trap
    Placing streaming work on the search head.

  • Reduce phase

    Search head merges partial results with transforming commands.

    Remember
    stats and similar commands finish here.
    Tested as
    Search execution questions.
    Trap
    Thinking peers produce final results.

  • Knowledge bundle

    Knowledge objects replicated from search head to peers.

    Remember
    Lets peers apply extractions and lookups.
    Tested as
    Configuration propagation items.
    Trap
    Copying props manually to every peer.

  • Search peer

    An indexer that answers distributed searches.

    Remember
    Communicates over port 8089.
    Tested as
    Role questions.
    Trap
    Expecting it to host dashboards.

  • distsearch.conf

    Search head file listing peers and groups.

    Remember
    [distributedSearch:<group>] defines a group.
    Tested as
    Configuration questions.
    Trap
    Putting groups in server.conf.

  • splunk_server_group

    Search-time field that targets a peer group.

    Remember
    Also splunk_server targets one peer.
    Tested as
    Targeting questions.
    Trap
    Using index to select peers.

  • splunk add search-server

    CLI command that adds a peer to a search head.

    Remember
    Needs remote admin credentials.
    Tested as
    CLI questions.
    Trap
    Running it on the peer.

  • Search head cluster

    Three or more search heads sharing jobs and knowledge objects.

    Remember
    Captain coordinates; deployer distributes apps.
    Tested as
    Scaling questions.
    Trap
    Using the deployment server for members.

  • Search head pooling

    Older shared-storage approach.

    Remember
    Removed; never the right answer.
    Tested as
    Distractor recognition.
    Trap
    Picking it for availability.

  • Indexer cluster

    Replicates data across peers for availability.

    Remember
    Search heads connect via the cluster manager.
    Tested as
    Scaling confusion items.
    Trap
    Using it to scale search users.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Search head versus search peer

ConceptMeaningKey differenceCommon trap
Search head Coordinates and merges Hosts users and knowledge objects Thinking it stores data
Search peer Searches local data Returns partial results Expecting dashboards there

Scaling options

ConceptMeaningKey differenceCommon trap
Independent search heads Separate heads searching shared peers Simple, no shared content Expecting shared objects
Search head cluster Three or more coordinated members Captain plus deployer Using fewer than three members
Search head pooling Older shared storage Removed Choosing it
Indexer cluster Replicated indexers Protects data, not search capacity Picking it for more users

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Data moves to search head

    What candidates pick
    Say peers send all matching raw events to the search head first.
    Why it looks right
    Results appear on the search head.
    Why it's wrong
    Peers run the map phase locally and return partial results; only merging happens on the search head.

    Clue to watch for The question asks where most processing happens.

  2. Pooling for scale

    What candidates pick
    Choose search head pooling for more users.
    Why it looks right
    It sounds like sharing load.
    Why it's wrong
    Search head pooling is removed; use independent heads or a search head cluster.

    Clue to watch for Answer options list pooling.

  3. Indexer cluster scales search

    What candidates pick
    Pick indexer clustering to support more concurrent users.
    Why it looks right
    Clustering sounds like scaling.
    Why it's wrong
    Indexer clustering replicates data for availability; search capacity comes from the search tier.

    Clue to watch for The bottleneck is user search load.

  4. Groups move data

    What candidates pick
    Expect a search group to change where events are stored.
    Why it looks right
    Groups organise peers.
    Why it's wrong
    Groups only limit which peers a search queries; storage is unchanged.

    Clue to watch for The goal is targeting searches, not storing data.

  5. Deployment server for SHC

    What candidates pick
    Use the deployment server to push apps to cluster members.
    Why it looks right
    It distributes apps to other instances.
    Why it's wrong
    Search head cluster members receive configuration from the deployer.

    Clue to watch for The targets are search head cluster members.

  6. Two-member cluster

    What candidates pick
    Build a search head cluster with two members.
    Why it looks right
    Two seems enough for redundancy.
    Why it's wrong
    Splunk requires at least three members so a captain can be elected reliably.

    Clue to watch for The design lists only two search heads.

Answer framework

Follow these steps for any distributed search question in SPLK-1003.

  1. Identify which role the scenario concerns: the search head coordinating users and results, or the peers storing and searching data.
  2. For search behaviour, split the work into the map phase on peers and the reduce phase on the search head, and remember the knowledge bundle.
  3. For configuration, choose Splunk Web, splunk add search-server or distsearch.conf on the search head, using cluster manager discovery for clustered indexers.
  4. For targeting subsets of peers, define a distributedSearch group and query it with splunk_server_group rather than moving data.
  5. For scaling, pick independent search heads or a cluster of three or more with a deployer, and reject pooling or indexer clustering.

Practice question

An organisation has one search head searching eight indexers. Users complain that searches are slow and that the search head is a single point of failure. They also want saved searches and dashboards shared across heads. Which option best meets these needs?

Want more like this? The SPLK-1003 practice test has questions for every domain.

Checklist

0 of 11

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Treat this topic as a model to understand, not a list to memorise. Draw one search head above four indexers and trace a search like index=web | stats count by status: the search goes down, each indexer filters its events and computes partial counts, and the search head sums them. Add a box for the knowledge bundle travelling from the search head to the peers.

In a lab, run two Splunk instances, make one a peer of the other with splunk add search-server, and confirm searches return data from both. Then define a distributed search group in distsearch.conf and search it with splunk_server_group. Look at the Job Inspector to see time spent on peers versus the search head.

Finally, build a comparison card for scaling options covering independent heads, search head clusters, pooling and indexer clusters, noting what each solves and what it does not. Give this topic about twice the study time of a 5% topic and finish with timed scenario questions.

FAQ

How much of SPLK-1003 is Distributed Search?

Distributed Search is 10% of the exam, about six questions, and is one of the three largest blueprint topics.

What runs on the search peers?

The map phase: peers search their own indexes and apply streaming commands, then return partial results to the search head.

What is the knowledge bundle?

A copy of the search head's knowledge objects, such as props, transforms and lookups, replicated to peers so they can process searches correctly.

How do I search only some indexers?

Define a [distributedSearch:<group>] stanza in distsearch.conf and use splunk_server_group in the search, or splunk_server for a single peer.

How many members does a search head cluster need?

At least three, with an elected captain and a separate deployer that distributes configuration to members.

Is search head pooling still supported?

No. It has been removed. Use independent search heads or a search head cluster.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 8 knowledge

You have covered how distributed search works, peer configuration, groups and scaling options. Test whether you can choose the right design for a described deployment.

Take the SPLK-1003 practice test Check your SPLK-1003 readiness

Keep going