Domain 1: Search and Transforming Commands
- Every SPL search runs left to right through the pipe (|), which streams the output of one command in as the input of the next; the pipeline always begins with an implicit search command even when you never type the word search.
- Filter early: tight index=, sourcetype=, and field=value terms placed before the first pipe shrink the working set while Splunk is still retrieving raw events, so every downstream command sorts, aggregates, or reformats far fewer rows.
- Adjacent search terms default to an implicit AND, Boolean operators AND, OR, and NOT must be uppercase to be recognized, and SPL evaluates them in the order NOT, then AND, then OR; use explicit OR or the IN operator to match either of two values.
- In search comparisons the operator symbol always precedes the equals sign, so greater-than-or-equal is status>=400, less-than-or-equal is <=, and not-equal is written !=, each testing a field against a literal value.
- The asterisk is the SPL wildcard, so host=web* matches any host starting with web; a leading wildcard blocks efficient narrowing and forces Splunk to scan far more data, so avoid patterns that begin with an asterisk.
- Double quotes bind multiple words into one exact phrase while unquoted words are separate keywords joined by AND; transforming commands such as stats (for example stats count by user | sort - count | head 5) aggregate events into tables that feed reports and visualizations.
Domain 2: Filtering, Formatting, and Correlating Events
- The where command evaluates a boolean eval expression, so it can compare two fields directly, such as where bytes_out > bytes_in, while search can only compare a field against a literal value or wildcard - field-to-field comparison is a where-only capability.
- where has no implicit-AND grammar, so operators must be explicit; use like() with SQL-style percent-sign wildcards, like(host,"web%"), for pattern matching, and match() when you need a full regex engine where anchors such as ^ behave as expected.
- search matches free-text keywords directly against raw event text, so a bare term like timeout finds it anywhere in _raw; where has no raw-text keyword syntax and needs searchmatch() to do the same thing.
- isnull() is the correct test for a field a lookup failed to populate, bounded numeric ranges require two comparisons joined with AND, and field-to-field arithmetic inside where must subtract in the correct direction.
- sort orders results ascending by default; a leading minus sign sorts a numeric field largest first, each key in a comma-separated list keeps its own direction sign, and a leading 0 (or the limit=0 argument) removes the default 10000-result cap.
- dedup removes duplicate values for the chosen fields, keeping the first occurrence in the current result order; a bare number placed before the field list sets how many occurrences of each value to keep.
Domain 3: Fields, Lookups, and Knowledge Objects
- Launch the Interactive Field Extractor from Extract Fields on an event's Actions menu, or from Settings, Fields, Field Extractions; the wizard highlights sample values, generates the rule, and previews matching events so you can validate the pattern before saving.
- The delimiter method tokenizes each event on one consistent single-character separator, such as a comma or a pipe, and names each resulting column, which suits fixed field order; the regular expression method uses position-based anchors and quantifiers for less regular text.
- The wizard's regex step is a live, editable field, so you can tighten the auto-generated pattern - for example when the extracted values still carry units like F or percent - and rerun the preview against the results list before saving.
- The Field Extractor produces only search-time extractions, saved as an EXTRACT or REPORT stanza and scoped to an app and sharing level; the rule reapplies to raw text each time the data is searched, needs no reindexing, and needs no admin file access.
- Search-time extraction is what Power Users do, applied when results are returned; index-time extraction bakes fields into storage, needs admin-level config access and typically a restart, and is out of Power User scope.
- The rex command extracts a field from raw text inside a search itself, as in rex field=message "pattern", capturing a value such as a username from each event without saving a permanent knowledge object.
Domain 4: Tags, Event Types, Macros, and Workflow Actions
- A tag is a plain text label attached to one field=value pair, such as host=web01, letting you search a friendly term with tag=webserver instead of the exact value; a single field=value pair can carry multiple independent tags, and tagging never changes the value's own logic.
- A plain tag=<name> search matches the label across every field it was applied to and combines all matching events, while tag::<field>=<tagname>, for example tag::sourcetype=vpn, restricts the match to one named field.
- Tag definitions live in tags.conf, where the stanza header names the field=value pair and the tag is the attribute; you can also add or edit a tag directly on a field value in Splunk Web, and disabling a tag pauses it without erasing the definition.
- An event type is a stored search used purely for classification, defined by search terms only with no piped commands; the eventtype field is computed at search time, is multivalue so one event can carry several classifications, and is filtered with eventtype=<name>.
- Create an event type from the Event types page under Settings or via Save As on a search; the defining search string lives in the search attribute in eventtypes.conf, and priority - running 1 (highest) through 10 (lowest), lowest number wins - resolves color conflicts when several event types match one event.
- Round out this domain with the other reusable knowledge objects: macros store a named, reusable piece of SPL you can insert into many searches, and workflow actions turn a field value in the results into an interactive link or secondary search.
Domain 5: Data Models, CIM, and Reporting
- A data model is a hierarchical set of knowledge objects that gives raw data a reusable, browsable structure; it powers the Pivot tool so non-SPL users can filter, split, and aggregate visually, and it is also the basis for data model acceleration.
- Data models are built from three dataset object types: event objects, whose constraint is a plain search term with no pipes; search objects, whose constraint is a fuller SPL pipeline minus transforming commands like stats, chart, and timechart; and transaction objects, which group related events by fields and a time window.
- A constraint is the filter that determines which events belong to a dataset, and it can be a basic search filter, an eval-derived condition, a regular expression matching a text pattern in a field, or a transaction grouping definition.
- A root object's constraint and fields flow down to every child beneath it; children inherit both and then narrow the parent's events with their own constraint, hierarchies can nest multiple levels, and inheritance is live so a new field on the root becomes usable in its children.
- Data model fields are called attributes: a field already present through an existing extraction becomes an auto-extracted attribute, while an eval-expression attribute computes a new field from logic applied to existing fields.
- The Common Information Model (CIM) gives data models a shared set of normalized field names to conform to, so Pivot-driven reports and dashboards can work consistently across different sources without writing SPL.
Splunk Core Certified Power User (SPLK-1002) exam tips
- Budget your prep evenly: the five domains each carry roughly equal weight (about 20%), so spread study across search and transforming commands, filtering and correlating, field extraction, tags and event types, and data models rather than over-investing in one.
- Nail SPL search syntax - uppercase Boolean operators, comparison symbols before the equals sign (>=, <=, !=), NOT-then-AND-then-OR precedence, quoted phrases for exact multi-word matches, and no leading wildcards.
- Know where versus search and transaction versus stats: where compares two fields and needs like() or match() for patterns, search matches raw keywords, and transaction groups related events by field and time where stats only aggregates.
- Practice the Interactive Field Extractor (IFX) wizard end to end - delimiter versus regular expression, editing the generated pattern, and previewing before saving.
- Remember that Power User field extractions are search-time only; index-time extraction needs admin access and a restart and is out of scope for this exam.
- Know which transforming commands feed reporting - stats, chart, and timechart produce the tabular results that Pivot, reports, and visualizations render, and event type definitions cannot contain piped commands.
- Learn the knowledge objects by purpose - tags label a field=value pair, event types classify events via a stored search, macros store reusable SPL, and workflow actions turn a field value into an interactive action - and trace how data model event, search, and transaction objects differ by their constraints and inherit down a hierarchy.
Study guide FAQ
Do I need Splunk Core Certified User first?
Yes. Splunk Core Certified User is the prerequisite for the Power User certification, so you must earn it before you can sit SPLK-1002. It validates foundational searching and reporting, and Power User builds on that with more advanced commands and knowledge objects.
What is the format of the SPLK-1002 exam?
The Power User exam has 65 questions to be answered in 60 minutes, delivered online through Pearson VUE.
What score do I need to pass?
Splunk does not publish an exact passing percentage for SPLK-1002, so there is no official number to target. Treat every domain as important and aim to answer confidently across all five rather than banking on a specific cut score.
How is Power User different from Splunk Core Certified User?
Splunk Core Certified User covers foundational searching, fields, and basic reporting and is the prerequisite. Power User goes further into transforming and correlating commands, field extractions, tags, event types, macros, workflow actions, and data models for Pivot and reporting.
Do I need to write SPL code to pass?
You need to read and reason about SPL rather than write large programs. Expect to know commands such as stats, where, sort, dedup, rex, and transaction, comparison and Boolean syntax, and how field extractions and data models are built.
How long should I study for SPLK-1002?
There is no official study-time requirement. Plan enough hands-on practice to be comfortable with SPL search and transforming commands, field extraction with the IFX wizard, tags, event types, macros, and workflow actions, and building and browsing data models in Pivot.