5.4 table, rename, fields, dedup, and sort

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

5.4 table, rename, fields, dedup, and sort

Key Takeaways Explain This Topic AI

fields keeps or removes fields in the pipeline; it does not replace base-search event filters like status=500.

table displays specified fields as columns in listed order for a tabular view.

rename old AS new changes field names in results; downstream commands must use the new names.

dedup removes duplicate events for specified field keys, optionally keeping N events per value.

sort orders results ascending/descending and can limit output with sort N -field.

Last updated: August 2026

5.4 table, rename, fields, dedup, and sort

Blueprint objective 4.4 explicitly lists five commands Users must be able to apply: table , rename , fields , dedup , and sort . These commands usually appear after a selective base search. They do not replace index= or field=value filters; they organize, reduce, and present the events you already retrieved.

Command Map at a Glance

Command Primary job Typical placement
fields Keep or remove fields from results Early after search to reduce clutter/payload
table Retain listed fields and show results as a table When you want a column-oriented view
rename Change field names (often for readability) Before final presentation or downstream references
dedup Remove duplicate events for specified field keys After filtering, often before table/sort
sort Order results by one or more fields Usually near the end
1) fields — Keep or Remove Fields
Purpose

fields controls which fields remain in the result set. It is about field selection , not about choosing which events match (that is what the base search/ search command does).

Syntax patterns
Keep only certain fields: ... | fields host, status, clientip
Remove fields: ... | fields - useragent, referer
Wildcard removals/keeps are commonly taught in Splunk training forms such as: ... | fields - _*
(Use internal-field removals carefully; some commands expect internal fields like _time .)
Examples index=web sourcetype=access_combined status=500
| fields _time, host, clientip, status, uri_path index=security action=failed
| fields - punct, date_*
Exam notes

fields helps readability and can improve efficiency by discarding unneeded field data before later stages.

fields is not a substitute for status=500 in the base search.

A brief contrast: where / eval can build conditional logic later, but User objective 4.4 is testing fields field inclusion/exclusion—not eval expressions.

2) table — Display Specific Columns
Purpose

table returns a table of the specified fields. Column order follows the order you list. Rows are the events/results flowing into the command.

Syntax ... | table <field1>, <field2>, <field3>, ...

Examples index=web sourcetype=access_combined status=5*
| table _time, host, clientip, status, uri_path index=security sourcetype=linux_secure action=failed
| table _time, user, src, host
| sort - _time
table vs fields

Topic fields table
Main intent Include/exclude fields in the pipeline Present a table of listed fields
Output tab tendency May still be event-oriented depending on context Statistics/table-oriented presentation
Column order Not primarily a display-ordering tool Explicitly uses argument order as columns
Event filter? No No

In many User workflows you may see either command used to narrow columns; for exam wording, if the question says display as a table with specific columns, prefer table .

3) rename — Rename Fields
Purpose

rename changes field names so headers are clearer in reports/tables or so names match a preferred label.

Syntax ... | rename <old_field> AS <new_field>
Multiple renames: ... | rename clientip AS src_ip, status AS http_status

Wildcards can rename groups of fields in more advanced patterns; for User focus, master the AS form first.

Examples index=web sourcetype=access_combined status=500
| stats count BY clientip
| rename clientip AS src_ip, count AS error_count
| table src_ip, error_count
| sort - error_count index=security action=failed
| table _time, user, host
| rename user AS username, host AS device
Exam notes

After renaming, downstream commands must use the new names.

Renaming does not change underlying stored index data; it changes names in the search result pipeline .

Quotes may be needed for new names with spaces: rename count AS "Error Count" .

4) dedup — Remove Duplicates
Purpose

dedup removes subsequent duplicate events based on one or more specified fields, keeping the first event(s) for each unique field-value combination in the incoming order.

Because Splunk event searches typically return newest-first, “first retained” often means the most recent event per key unless sorting changed order earlier.

Syntax ... | dedup <field>
... | dedup <field1>, <field2>
... | dedup <N> <field>
Examples
Keep the newest event per user (given default reverse-time order): index=vpn action=login
| dedup user
| table _time, user, src_ip
Dedup on a combination of fields: index=security action=failed
| dedup user, src
| table _time, user, src, host
Keep two events per client IP: index=web status=500
| dedup 2 clientip
| table _time, clientip, status, uri_path
Useful options (awareness level)

Option Meaning
consecutive=true Only remove duplicates that are adjacent
keepempty=true/false How to treat events missing the dedup field

For most User exam items, knowing that dedup removes duplicates for listed fields and that an optional count keeps N per value is enough.

5) sort — Order Results
Purpose

sort orders results by one or more fields ascending or descending.

Syntax ... | sort <field>
... | sort -<field>
... | sort <field1>, -<field2>
... | sort <limit> -<field>
Ascending: sort status or sort +status
Descending: sort -status
Limit while sorting: sort 10 -count
Examples index=web sourcetype=access_combined status=500
| stats count BY host
| sort - count index=web sourcetype=access_combined
| table _time, status, clientip, bytes
| sort status, - bytes index=security action=failed
| stats count BY user
| sort 5 - count
Exam notes

Default direction is ascending if not marked.

Sort after aggregation when you need top talkers by count.

Sorting huge raw event sets without limits can be expensive—filter/aggregate first when possible.

Putting All Five Together
Example A — Clean investigation table index=web sourcetype=access_combined status=5*
| fields _time, host, clientip, status, uri_path, useragent
| dedup clientip
| rename clientip AS src_ip
| table _time, host, src_ip, status, uri_path
| sort - _time

Stage reading:

Retrieve server-error web events.

Keep relevant fields.

One row per client IP.

Rename for clarity.

Display columns.

Newest first.

Example B — Ranked summary prep (with stats awareness)
stats is Domain 5, but Users often combine 4.4 commands around it: index=security action=failed
| stats count BY user
| rename count AS failures
| table user, failures
| sort 10 - failures

Here rename , table , and sort finalize a ranked failures list.

Example C — fields vs table choice

If the question is “remove unnecessary fields but continue processing events,” lean fields .

If the question is “show only these columns in a table,” lean table .

Decision Guide

Goal Prefer

Drop noisy fields early fields - ...

Keep only needed fields fields a, b, c or table a, b, c
Explicit tabular columns/order table
Friendlier header names rename old AS new
Unique entities (latest login per user) dedup user
Ranked / chronological order sort - field
Top N after counts sort N - count
Common Mistakes Across the Five Commands

Mistake Fix
Using fields / table to filter event values Use status=500 in the search stage
Sorting before narrowing millions of raw events Filter/aggregate first; consider sort N
Referencing old names after rename Use the new names downstream
Expecting dedup to pick “best” event by score It keeps first in current order for the key
Confusing dedup with sort Distinct jobs: uniqueness vs order
Forgetting commas/AS syntax Follow rename x AS y , table a, b , fields a, b
Objective 4.4 Study Drill

For each command, practice until you can write one correct pipeline from memory:

fields keep list
fields remove list
table three columns
rename with AS
dedup one field and two fields
sort descending with and without a numeric limit

If you can combine all five in one coherent search and explain each stage left to right, you have closed Domain 4.0’s command requirement for the Splunk Core Certified User exam.