SPLK-1003 · Domain 16 of 17

SPLK-1003 Domain 16: Parsing Phase and Data

Parsing Phase and Data covers how Splunk turns a stream of raw text into events with correct timestamps: default parsing behaviour, line-breaking settings in props.conf, timestamp and time zone extraction, and validating results with Data Preview.

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

About 10 min read Reviewed October 2026

Overview

Domain 16 has four official objectives: understand the default processing that occurs during parsing, optimize and configure event line breaking, explain how timestamps and time zones are extracted or assigned to events, and use Data Preview to validate event creation during the parsing phase. In the parsing phase, which runs on indexers or heavy forwarders, Splunk breaks the data stream into lines, merges lines into events, finds each event's timestamp and applies index-time transforms.

The key props.conf attributes are LINE_BREAKER, SHOULD_LINEMERGE, TRUNCATE, TIME_PREFIX, TIME_FORMAT, MAX_TIMESTAMP_LOOKAHEAD and TZ. Data Preview, in the Add Data workflow, lets you test these settings against sample data before saving a sourcetype. At 5%, expect around three questions focused on configuration choices and default behaviour.

How it's tested

Items describe sample data, such as multi-line events or unusual timestamps, and ask which props.conf settings produce correct events. Others ask what Splunk does by default when settings are missing or when no timestamp can be found, and where Data Preview fits in the workflow.

  • Break the events

    A sample log is shown and you choose LINE_BREAKER, SHOULD_LINEMERGE or related settings to create correct events.

  • Fix the timestamp

    Events have wrong times and you choose TIME_PREFIX, TIME_FORMAT, MAX_TIMESTAMP_LOOKAHEAD or TZ to correct them.

  • Validate before saving

    You decide how Data Preview helps test a sourcetype and where the resulting settings must be deployed.

Reasoning it through

Java logs produce dozens of tiny events per stack trace. Each real event starts with a date like 2026-10-31 14:02:11. The candidate sets SHOULD_LINEMERGE = false and LINE_BREAKER = ([\r\n]+)\d{4}-\d{2}-\d{2}, so Splunk breaks only before a date. This is faster than line merging with BREAK_ONLY_BEFORE, and it belongs on the indexers or heavy forwarder, not the universal forwarder.

Objectives 4

Official objectives from the Splunk outline, in outline order.

16.1 Understand the default processing that occurs during parsingLine breaking, merging, timestamps and transforms by default.
What it means
By default Splunk splits the stream into lines on newline characters using LINE_BREAKER = ([\r\n]+), then merges lines into events because SHOULD_LINEMERGE is true, starting a new event when a line contains a date. It truncates lines longer than TRUNCATE, 10,000 bytes by default, extracts a timestamp from each event and applies any index-time transforms configured for the data.
What to understand
Defaults work for many single-line logs but are inefficient and error-prone for multi-line data. Parsing runs on the first heavy forwarder or indexer in the path. Data that a heavy forwarder has already parsed is not parsed again by the indexer. Changes apply only to newly indexed data.
How it shows up
A behaviour is described and you identify whether it results from default parsing settings.
Common confusion
Thinking SHOULD_LINEMERGE defaults to false in Splunk Enterprise.
16.2 Optimize and configure event line breakingLINE_BREAKER, SHOULD_LINEMERGE and related settings.
What it means
Line breaking is configured per sourcetype in props.conf. The efficient approach sets SHOULD_LINEMERGE = false and writes a LINE_BREAKER regex whose first capture group marks the boundary between events. If line merging is used, BREAK_ONLY_BEFORE, MUST_BREAK_AFTER and MAX_EVENTS control how lines combine. TRUNCATE limits the length of a line.
What to understand
The text matched by LINE_BREAKER's capture group is discarded, so capture only the delimiter, such as newlines. MAX_EVENTS limits merged events to 256 lines by default. Universal forwarders can use EVENT_BREAKER to help load balancing, but this does not replace line breaking on the parsing tier.
How it shows up
Sample data breaks incorrectly and you choose the props.conf settings that fix it efficiently.
Common confusion
Putting event content inside LINE_BREAKER's capture group, which deletes that text from events.
16.3 Explain how timestamps and time zones are extracted or assigned to eventsTIME_PREFIX, TIME_FORMAT, lookahead and TZ rules.
What it means
Splunk looks for a timestamp in each event. TIME_PREFIX is a regex for the text before the timestamp, TIME_FORMAT is a strptime pattern describing it, and MAX_TIMESTAMP_LOOKAHEAD limits how many characters after the prefix are scanned. If no timestamp is found, Splunk uses the previous event's time from the same source, then other fallbacks such as the file's modification time, and finally the current time.
What to understand
Time zone comes from TZ in props.conf if set, otherwise from a zone in the timestamp, otherwise the zone reported by the forwarder, and otherwise the parsing server's zone. MAX_DAYS_AGO and MAX_DAYS_HENCE reject implausible dates. DATETIME_CONFIG can disable timestamp extraction so the index time is used.
How it shows up
Events show the wrong time and you choose the timestamp or time zone setting that fixes them.
Common confusion
Assuming Splunk always uses the indexer's time zone when the data has no zone.
16.4 Use Data Preview to validate event creation during the parsing phaseTesting sourcetype settings in the Add Data workflow.
What it means
Data Preview appears in the Set Source Type step of the Add Data workflow in Splunk Web. It shows how a sample file will be broken into events and timestamped using a chosen or new sourcetype, and lets you adjust event breaks, timestamp and advanced settings before saving the sourcetype to props.conf.
What to understand
Preview does not index the sample until you continue, so it is safe for experimentation. Saved sourcetypes are written to props.conf in the selected app on that instance; for forwarded data you must deploy those settings to the indexers or heavy forwarders that parse it.
How it shows up
You decide how to test line breaking and timestamps for a new data source before indexing it.
Common confusion
Expecting a sourcetype saved in Data Preview on a search head to affect parsing on indexers.

High-yield concepts

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

  • Parsing tier

    Indexers or heavy forwarders.

    Remember
    Universal forwarders do not parse.
    Tested as
    Placement questions.
    Trap
    Configuring LINE_BREAKER on a UF.

  • LINE_BREAKER

    Regex that splits the stream into lines or events.

    Remember
    Capture group text is discarded.
    Tested as
    Line breaking questions.
    Trap
    Capturing event content.

  • SHOULD_LINEMERGE

    Whether lines are merged into multi-line events.

    Remember
    Default true; set false with a good LINE_BREAKER.
    Tested as
    Efficiency questions.
    Trap
    Assuming it defaults to false.

  • BREAK_ONLY_BEFORE

    Line-merge rule to start events before a pattern.

    Remember
    Only used with line merging.
    Tested as
    Multi-line questions.
    Trap
    Using it with SHOULD_LINEMERGE = false.

  • TRUNCATE

    Maximum line length, default 10,000 bytes.

    Remember
    Long events are cut.
    Tested as
    Truncated event scenarios.
    Trap
    Confusing it with MAX_EVENTS.

  • MAX_EVENTS

    Maximum lines in a merged event, default 256.

    Remember
    Applies to line merging.
    Tested as
    Split stack trace scenarios.
    Trap
    Confusing it with TRUNCATE.

  • TIME_PREFIX

    Regex for text before the timestamp.

    Remember
    Narrows where Splunk looks.
    Tested as
    Timestamp questions.
    Trap
    Including the timestamp itself.

  • TIME_FORMAT

    strptime pattern for the timestamp.

    Remember
    Example %Y-%m-%d %H:%M:%S.
    Tested as
    Timestamp questions.
    Trap
    Using regex instead of strptime.

  • MAX_TIMESTAMP_LOOKAHEAD

    Characters scanned for a timestamp after the prefix.

    Remember
    Keeps Splunk from matching later dates.
    Tested as
    Wrong date scenarios.
    Trap
    Setting it too short.

  • TZ

    Time zone applied when data lacks one.

    Remember
    Overrides forwarder and server zones.
    Tested as
    Time zone questions.
    Trap
    Assuming the indexer's zone always applies.

  • Data Preview

    Add Data step that previews event breaks and timestamps.

    Remember
    Saves a sourcetype to props.conf.
    Tested as
    Validation questions.
    Trap
    Expecting it to deploy settings.

Side by side

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

Line breaking approaches

ConceptMeaningKey differenceCommon trap
LINE_BREAKER with SHOULD_LINEMERGE = false Break directly on a regex Efficient and predictable Capturing event text
Line merging Merge lines using rules Default, slower Leaving defaults for multi-line logs
EVENT_BREAKER on UF Helps forwarder switch indexers cleanly Does not replace parsing Treating it as line breaking

Timestamp settings

ConceptMeaningKey differenceCommon trap
TIME_PREFIX Where the timestamp starts Regex before it Including the time
TIME_FORMAT How the timestamp looks strptime pattern Writing a regex
MAX_TIMESTAMP_LOOKAHEAD How far to scan Character count Too short a value
TZ Which zone to apply Used when data has none Ignoring forwarder zone

Exam traps

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

  1. Parse on the UF

    What candidates pick
    Add LINE_BREAKER to props.conf on the universal forwarder.
    Why it looks right
    The forwarder reads the file first.
    Why it's wrong
    Parsing happens on indexers or heavy forwarders; the universal forwarder ignores these settings.

    Clue to watch for Data comes from a universal forwarder.

  2. Capture the content

    What candidates pick
    Write LINE_BREAKER = (\d{4}-\d{2}-\d{2}) to break before dates.
    Why it looks right
    The date marks the event start.
    Why it's wrong
    Text in the capture group is discarded, so dates would be removed from events.

    Clue to watch for The regex captures part of the event.

  3. Line merge is efficient

    What candidates pick
    Keep SHOULD_LINEMERGE = true with BREAK_ONLY_BEFORE.
    Why it looks right
    It is the default behaviour.
    Why it's wrong
    Breaking directly with LINE_BREAKER and SHOULD_LINEMERGE = false is faster and more predictable.

    Clue to watch for The question asks for an optimised setup.

  4. Indexer zone always

    What candidates pick
    Assume events without a zone use the indexer's time zone.
    Why it looks right
    The indexer parses the data.
    Why it's wrong
    TZ in props.conf, or the zone reported by the forwarder, is applied before the server's own zone.

    Clue to watch for Forwarder and indexer are in different zones.

  5. Regex in TIME_FORMAT

    What candidates pick
    Write a regular expression in TIME_FORMAT.
    Why it looks right
    Other props settings use regex.
    Why it's wrong
    TIME_FORMAT uses strptime variables; TIME_PREFIX is the regex.

    Clue to watch for The answer shows backslash-d patterns in TIME_FORMAT.

  6. Preview deploys settings

    What candidates pick
    Assume Data Preview applies the new sourcetype everywhere.
    Why it looks right
    It saves the configuration.
    Why it's wrong
    It writes props.conf only on that instance; parsing tiers need the settings deployed.

    Clue to watch for Data Preview was used on a search head.

Answer framework

Follow these steps when a question involves event creation or timestamps.

  1. Locate the parsing tier for the data path, the first heavy forwarder or else the indexers, because parsing settings only take effect there.
  2. Examine the sample for a reliable event boundary and write LINE_BREAKER with only the delimiter captured, setting SHOULD_LINEMERGE = false.
  3. Check TRUNCATE and MAX_EVENTS if events are cut short or long multi-line events are split into several pieces.
  4. Set TIME_PREFIX, TIME_FORMAT and MAX_TIMESTAMP_LOOKAHEAD for the timestamp, and TZ when the data lacks a zone or the forwarder zone is wrong.
  5. Test with Data Preview on sample data, then deploy the saved props.conf to the parsing tier and check newly indexed events.

Practice question

A heavy forwarder parses application logs before sending them to indexers. Each event begins with [2026-10-31 08:15:02.123] and some events contain multi-line stack traces. Which props.conf approach is the most efficient way to create correct events?

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

Learn this topic with real sample files. Collect three examples: single-line logs with an unusual timestamp, multi-line Java stack traces and logs with no time zone. Upload each through Add Data and use Data Preview to experiment. Try the default settings first to see what goes wrong, then switch to SHOULD_LINEMERGE = false with a custom LINE_BREAKER and compare the result.

For timestamps, set TIME_PREFIX and TIME_FORMAT explicitly, then shorten MAX_TIMESTAMP_LOOKAHEAD to see Splunk miss the date. Change TZ and watch event times shift in search. Save each working configuration as a sourcetype and open the props.conf that Splunk writes, so you recognise the attributes in exam answer options.

Next, think about placement: write down which instance would need each configuration in a universal forwarder, heavy forwarder and indexer architecture. Finally, memorise a small set of defaults, including TRUNCATE, MAX_EVENTS and SHOULD_LINEMERGE, and practise questions that show sample data and ask for the right settings.

FAQ

How much of SPLK-1003 is Parsing Phase and Data?

Parsing Phase and Data is 5% of the exam, about three questions, covering default parsing, line breaking, timestamps and Data Preview.

Where does parsing happen?

On the first heavy forwarder in the data path, or on the indexers if there is none. Universal forwarders do not parse.

Why set SHOULD_LINEMERGE to false?

Breaking events directly with LINE_BREAKER is faster and more predictable than merging lines using rules.

What does the LINE_BREAKER capture group do?

It marks the boundary between events. Text matched by the capture group is discarded, so capture only delimiters such as newlines.

How does Splunk choose a time zone?

It uses TZ from props.conf if set, then a zone in the timestamp, then the zone the forwarder reports, then the parsing server's zone.

Does Data Preview change existing data?

No. It previews sample data and saves a sourcetype; only newly indexed data uses the new settings.

Other Cybersecurity certifications

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

Test your Domain 16 knowledge

You have covered default parsing, line breaking, timestamps and Data Preview. Test whether you can choose settings that produce clean events with correct times.

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

Keep going