8.1 Lookup Concepts and File Examples

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:

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:

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:

1. 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.
2. 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):

1. Lookup table file — the uploaded CSV itself
2. Lookup definition — a named knowledge object that points at the file and defines how matching works
3. 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:

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