8.1 Lookup Concepts and File Examples

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

8.1 Lookup Concepts and File Examples

Key Takeaways Explain This Topic AI

A lookup matches a field value in your events to a key column in an external table and adds enrichment columns at search time.

CSV file lookups are the primary lookup type on the Splunk Core Certified User exam; each column becomes a potential field.

Lookups enrich results without changing indexed raw data — enrichment happens when the search runs.

A typical CSV has one or more key columns (for matching) plus one or more enrichment columns (for output).

Last updated: August 2026

Why lookups matter on the User exam

Domain 7.0 Creating and Using Lookups is about 6% of the Splunk Core Certified User blueprint. That weight is small, but the ideas are concrete and easy to test: what a lookup is, what a lookup file looks like, how you create definitions, how automatic lookups apply, and how the | lookup command works in a search.

A lookup connects a value already present in your search results to a row in an external table, then adds related values from that table onto the event. In plain language: Splunk already knows something (for example status=404 ), and the lookup table knows more about that something ( status_description=Not Found , status_type=Client Error ). After the lookup runs, each matching event carries both the original field and the new enrichment fields.

Lookups are a search-time enrichment. They do not rewrite the raw events stored in an index. When you run a search, Splunk can match fields and attach extra columns for that search job. The next search without the lookup (or without an automatic lookup) will not magically keep those enrichment fields unless the lookup is applied again.

What problem lookups solve

Machine data often stores compact codes, IDs, and keys that are efficient to log but hard for humans to read:

• Event field (key) What analysts usually want
• status=503 "Service Unavailable" and error class
• user_id=u48291 Display name and department
• vendor_code=ACME-17 Product name and owner team
• src_ip=10.2.8.44 Asset name and criticality (from an asset list)

You could hard-code every mapping into long eval / case expressions. Lookups are cleaner when the mapping is tabular, shared across many searches, and maintained outside SPL.

Lookup types (awareness only)

Splunk supports more than one lookup backend. For the User exam, treat this as awareness:

Type Idea User exam focus

CSV file lookup (static lookup) Match against columns in a CSV (or .csv.gz ) file Primary focus — blueprint examples use CSV

KV Store lookup Match against a KV Store collection that can be updated more dynamically Mentions only — not the main User workflow

External / scripted lookups Call out to other systems Out of User scope for this guide

When a question shows a spreadsheet-style table with a header row and enrichment columns, think CSV lookup .

Anatomy of a CSV lookup file

A CSV lookup is a static table. The first row is usually the header (field names). Each later row is a record. Splunk treats each column as a potential field.

• Example: http_status.csv status,status_description,status_type
• 200,OK,Success
• 301,Moved Permanently,Redirect
• 404,Not Found,Client Error
• 500,Internal Server Error,Server Error
• 503,Service Unavailable,Server Error

Break this into two roles:

Key column(s) — used to match event values. Here status is the key. An event with status=404 matches the row where status is 404 .

Enrichment column(s) — returned into the event after a match. Here status_description and status_type are enrichment fields.

A lookup file can have more than one key column when you need a composite match (for example vendor + product_code ). User exam questions usually keep the key simple: one matching field.

Search-time enrichment idea

Imagine your web access events already extract status . Before a lookup, a sample event might look like: status=404 method=GET uri_path=/login

After applying a lookup that matches status and outputs the description fields, the same event conceptually becomes: status=404 method=GET uri_path=/login status_description="Not Found" status_type="Client Error"

Nothing about the original raw _raw string in the index had to change. The enrichment is attached when the search (or automatic lookup) runs. That is why lookups are powerful for reporting: you can | stats count by status_type after enrichment even though the sourcetype never logged status_type .

How this ties to later sections

To use a CSV lookup in Splunk Web you typically need three related pieces (covered next):

• Lookup table file — the uploaded CSV itself
• Lookup definition — a named knowledge object that points at the file and defines how matching works

Optional automatic lookup — applies the definition for matching sourcetype/source/host without typing | lookup every time

Even without an automatic lookup, you can always invoke the definition (or sometimes the file) with the | lookup command in a search.

Exam traps for concepts

Trap: Thinking a lookup permanently alters indexed data. It enriches at search time .

Trap: Confusing the key column with enrichment columns. Keys match; enrichment fields are what you usually OUTPUT.

Trap: Assuming User exam depth equals Admin topics (large KV Store design, .conf file authoring). Stay with CSV examples, Settings UI paths, and | lookup behavior.

Trap: Mixing lookups with Power User topics such as data models, CIM, macros, or tags. Those are not Domain 7.0 User content.

Quick mental model

Match a field → find the row → add the related columns. If you can explain that sentence with a CSV example like status → status_description , you are ready for topics 7.1 and 7.2.

CSV vs "changing the data"

A useful mental contrast for exam questions:

• Approach What changes When it happens
• Fix the logging format Future raw events include richer fields At the source / ingest path
• Use a lookup Search results gain enrichment fields At search time for matching keys

Lookups are ideal when you cannot (or should not) change every producer, but analysts still need friendly labels, categories, or ownership metadata while searching.