ExamFinch.com My Study

Study guide

4.1 Understanding Fields

Practice this exam

Splunk Core Certified User Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts & Logistics 1.2 Study Strategy & Learning Path

2 Splunk Basics

2.1 Splunk Components 2.2 Uses of Splunk 2.3 Splunk Apps 2.4 User Settings & Basic Navigation

3 Basic Searching

3.1 Running Basic Searches 3.2 Setting Time Ranges 3.3 Contents of Search Results 3.4 Refining Searches 3.5 Using the Timeline 3.6 Working with Events 3.7 Controlling Search Jobs 3.8 Saving Search Results

4 Using Fields in Searches

4.1 Understanding Fields 4.2 Using Fields in Searches 4.3 The Fields Sidebar

5 Search Language Fundamentals

5.1 Basic Search Commands & Practices 5.2 The Search Pipeline 5.3 Specifying Indexes in Searches 5.4 table, rename, fields, dedup, and sort

6 Using Basic Transforming Commands

6.1 The top Command 6.2 The rare Command 6.3 The stats Command

7 Creating Reports and Dashboards

7.1 Saving and Editing Reports 7.2 Statistical Table Reports 7.3 Chart Visualization Reports 7.4 Creating Dashboards and Adding Reports 7.5 Editing Dashboards

8 Creating and Using Lookups

8.1 Lookup Concepts and File Examples 8.2 Creating Lookup Files and Definitions 8.3 Configuring Automatic Lookups 8.4 Using Lookups in Searches

9 Creating Scheduled Reports and Alerts

9.1 Scheduled Reports 9.2 Describing and Creating Alerts 9.3 Viewing Fired Alerts

4.1 Understanding Fields

Key Takeaways Explain This Topic AI

A field is a searchable name/value pair that distinguishes one event from another; not all events share the same fields.

Default fields include host, source, sourcetype, _time, and _raw; they provide core metadata for every indexed event.

Discovered fields come from event content and vary by sourcetype—examples include status, user, clientip, and action.

Many application fields become available through search-time field extraction when a search retrieves events.

Field names identify attributes and are case-sensitive; field values identify matching instances used in filters like status=500.

Last updated: August 2026

4.1 Understanding Fields

Fields are the primary way Splunk turns raw machine data into searchable structure. On the Splunk Core Certified User exam, Domain 3.0 (Using Fields in Searches) is about 20% of the blueprint, and objective 3.1 starts with a simple idea: every event is a timestamped raw string, and fields are the name/value pairs Splunk attaches so you can filter, refine, and report without re-reading every character of _raw by hand.

If you only remember one framing, use this: indexes store events; fields let you ask precise questions about those events.

What a Field Is

A field is a searchable name and value pairing extracted from an event. Not every event has the same fields or the same values. One web access event might expose status , clientip , and bytes , while a nearby authentication event exposes user , action , and src . That variability is normal—and it is why the Fields sidebar and field-aware SPL matter so much in day-to-day search work.

  • Concept Meaning Exam-ready example
  • Field name The label Splunk uses for a piece of extracted data status , host , user
  • Field value The data stored under that name for one event 500 , web01 , jsmith
  • Field-value pair Name plus value used together in a search status=500
  • Missing field The event simply does not contain that extraction An auth event with no bytes field

Field names identify what you are talking about. Field values identify which instances match. Searches become powerful when you combine both: index=web status=500 is far more precise than searching the word 500 alone across every string in every index.

Default Fields vs Discovered Fields

Splunk gives you two broad categories of fields that User candidates must distinguish:

Default fields (always present)

During indexing, Splunk attaches a core set of default fields to every event. These are the metadata anchors of search:

  • Default field What it represents Typical values
  • host Device or system that produced the event web01.example.com , 10.1.2.3
  • source Origin path, stream, or input /var/log/nginx/access.log
  • sourcetype Format classification used for parsing behavior access_combined , linux_secure
  • _time Event timestamp (Unix epoch under the hood; shown readable in the UI) 2026-08-01 09:14:22
  • _raw Original unmodified event text Full log line

You will also frequently see index in results and the Fields sidebar. The index names the storage container that holds the event ( main , web , security , and so on). For exam purposes, treat host/source/sourcetype as the classic default selected fields in the UI, and remember _time and _raw as foundational event contents.

These default fields are why best-practice searches begin with constraints like index=web sourcetype=access_combined before any keyword hunting.

Discovered / extracted fields

Beyond defaults, Splunk discovers additional fields from event content. In User-level language, think of these as fields found in (or extracted from) the events returned by your search —for example status , method , clientip , user , action , or bytes .

Key points for the exam:

Discovered fields vary by data . Web logs expose HTTP fields; firewall logs expose network fields.

Many useful fields are available because Splunk extracts them when you search (see search-time extraction below).

The Fields sidebar surfaces the ones that show up often enough in this result set as Interesting Fields , while Selected Fields control what appears under each event in the Events view.

Field Extractions at Search Time (User-Level Concept)

Splunk extracts fields at different points in the data lifecycle. For the User exam, you need the conceptual difference—not Power User configuration details.

Timing What happens Why it matters to a User

Index time Events are parsed, timestamped, stored; default metadata fields are attached Data becomes searchable by host/source/sourcetype/ _time

Search time When a search runs, Splunk retrieves matching events and extracts additional fields from raw text based on configured extractions Most application fields become available for field=value filtering and reporting

Practical mental model for User candidates:

You run a search against an index and time range.

Splunk finds matching events on disk.

At search time , field extractions for those events are applied so names like status or user become usable.

The Fields sidebar lists selected and interesting fields from the current result set.

You click values or write field=value clauses to refine.

You do not need to author regex extractions, field aliases, calculated fields, or Field Extractor workflows for this certification track. Stay focused on using fields that already appear in results.

  • Field Names and Field Values in Practice
  • Names identify the attribute

Field names are identifiers. Common defaults and discovered names include:

  • Metadata: host , source , sourcetype , index
  • Web: status , method , uri_path , clientip , bytes
  • Auth: user , action , src , dest

Treat names carefully. Searching Status=500 is not the same as status=500 if the extracted field is lowercase status — field names are case-sensitive .

Values identify matching events

Values are what you compare against:

  • Exact match: status=404
  • Inequality: status!=200
  • Multiple values: status IN (500, 503, 504)
  • Wildcarded values: user=admin*
  • Phrase values: error_message="disk full"

Values are the part of the pair that usually benefits from wildcards and quoting rules (covered in the next section).

  • Same value, different meaning without the field name
  • This is a classic exam trap. Searching: index=web 500

can match the number 500 anywhere in _raw —status codes, byte counts, ports, or unrelated text. Searching: index=web status=500

targets only events where the status field equals 500. Field-aware searching is more precise and usually more efficient than bare keyword matches for structured attributes.

How Fields Appear in the Search UI

After a search returns events, Splunk presents:

  • Events list with _time and highlighted _raw text
  • Selected fields displayed under each event (defaults include host , source , sourcetype )
  • Interesting fields in the sidebar for frequently occurring extractions
  • Expandable event details showing many more field/value pairs for a single event

Clicking a field opens a detail panel with top values, counts, and percentages—tools you will use heavily in section 4.3.

  • Worked Scenario: From Raw Line to Usable Fields
  • Imagine this raw web event: 10.2.3.4 - - [01/Aug/2026:09:14:22 -0700] "GET /cart HTTP/1.1" 500 812

After indexing and search-time extraction for an access_combined -style sourcetype, a User might see pairs such as:

  • Field Value
  • host web01
  • source /var/log/nginx/access.log
  • sourcetype access_combined
  • clientip 10.2.3.4
  • method GET
  • uri_path /cart
  • status 500
  • bytes 812
  • Now you can write targeted SPL: index=web sourcetype=access_combined status=500

instead of hoping a free-text search for 500 finds only HTTP failures.

Exam Traps to Avoid

  • Trap Reality
  • Treating every field as always present on every event Fields vary by event and sourcetype
  • Confusing field names with field values Names are labels; values are the data
  • Assuming bare keywords equal field filters 500 ≠ status=500
  • Diving into aliases, calculated fields, or CIM for User prep Those topics are outside User scope
  • Ignoring defaults host / source / sourcetype / _time / _raw are foundational
  • Why This Objective Matters on the Exam

Objective 3.1 is the vocabulary section for Domain 3. Later questions about field syntax, the Fields sidebar, and refining searches assume you can:

  • Define a field as a name/value pair
  • Separate default fields from discovered fields in results
  • Explain that many useful fields become available when the search runs (search-time extraction concept)
  • Use field names and values deliberately, not interchangeably

Master those four points and the rest of Domain 3 becomes application practice rather than new theory.