Splunk Core Certified User common mistakes
Splunk Core Certified User · Understand the traps and how to avoid them.
Answers architecture questions as if a universal forwarder can parse events, apply index-time extractions, or route data to different indexes based on content.
The names 'universal forwarder' and 'heavy forwarder' sound interchangeable, so candidates assume both do the same job and that any forwarder can process data before sending it.
What to do instead
Memorize the division of labour: a universal forwarder only collects and forwards raw data (no parsing, no routing); a heavy forwarder can parse, filter, and route; an indexer indexes and stores the data; a search head handles the search-time knowledge objects and merges results from indexers.
When asked where saved searches, field extractions, and lookup definitions are stored and applied, selects the indexer because 'that is where the data is'.
Candidates reason that knowledge must live next to the data and do not separate index-time processing from search-time processing.
What to do instead
Treat knowledge objects as search-time artefacts managed by the search head (and replicated across a search head cluster); the indexers store and retrieve raw events and do not own user-created extractions, lookups, or alerts.
Types a search, presses Enter, reads the result counter, and concludes that data is missing or that a search is broken, without ever opening or changing the time range picker.
The interface defaults to a recent window (Last 24 hours), and the picker sits visually separate from the search bar, so the time constraint is easy to overlook entirely.
What to do instead
Before judging a result count, check the time range picker and the 'earliest/latest' indicator next to the search bar; widen to a larger window or All time when verifying whether events exist, and remember that the picker constraint applies to the base search, not to results after a transforming command.
Writes a pipeline such as `index=web | stats count by host | search status=500`, expecting the final clause to filter the original raw events.
Candidates treat the pipe as decoration rather than a data-flow boundary, and do not realize that after stats the result set is a table of statistics in which the original fields no longer exist.
What to do instead
Put all raw-event filters before the first pipe (index=web status=500 | stats count by host); after a transforming command, filter the aggregated fields with where or search on fields that actually survive, such as | stats count by host | where count > 10.
Omits `index=` from the base search (or uses `index=*`) when troubleshooting, then reports that no events exist or that the search is unusably slow.
The search bar accepts bare keywords without complaint, so candidates do not notice they are querying every index they can reach; role-based index permissions can silently hide the data they expected to see.
What to do instead
Start every search with an explicit index= and the narrowest sourcetype= you can justify; if results are unexpectedly empty, confirm both the index name and whether your role grants access to that index rather than assuming the data is absent.
Tries to use a lookup by passing a CSV filename to the lookup command, writing `| lookup myfile.csv user`.
The lookup table file and the lookup definition are created in different places in Settings and share a similar name, so candidates collapse the two concepts into one.
What to do instead
A lookup definition is the named object the lookup command references (| lookup my_lookup_definition user OUTPUT dept); the CSV is the underlying table file. Use | inputlookup myfile.csv to inspect or test the raw file contents, and | lookup only with the definition name.
Assumes that creating a field alias, or extracting a field with the Field Extractor, permanently rewrites the stored events, and warns that reindexing will be required.
Candidates conflate search-time knowledge objects with the raw event text they can see in the results pane, and assume any new field must already exist in the data.
What to do instead
Recall that most field extraction, field aliases, calculated fields, and tags are applied at search time and never alter the raw event or the on-disk data; only default/index-time fields are set during indexing, so adding an alias or a regex extraction takes effect immediately for future searches in that app.
Uses `count` and `count(field)` interchangeably, and reaches for `count()` when the question asks for the number of distinct values of a field.
The functions look nearly identical and their names suggest they measure the same thing.
What to do instead
count counts matching events; count(field) counts only events where that field has a non-null value; a distinct count of a field's values requires dc(field). Read the requirement first (events vs populated values vs unique values), then pick the function.
Configures an alert with the default trigger condition and assumes it fires once for every matching event, or assumes alerts are real-time by default and will react instantly to incoming data.
The trigger settings are on a separate step from the search and permissions, and the 'Number of Results', 'Number of Hosts', and 'Number of Sources' options all sound like they measure the same matching events.
What to do instead
Decide deliberately: 'Number of Results' compares the total result count to your threshold, while 'Number of Hosts'/'Number of Sources' compare distinct hosts or sources; choose 'Once' versus 'For each result' explicitly. Alerts are scheduled (cron) unless you deliberately select a real-time schedule, so expect alerting to occur when the schedule runs.
Assumes the time range picker at the top of a dashboard has no effect on its panels, or builds several panels each with a full independent search and then cannot explain why the dashboard is slow or why one panel ignores the selected window.
Panel searches are written in the same editor as ad-hoc searches, so candidates carry over the habit of hardcoding earliest/latest inside the search string and forget that panels inherit the dashboard-level time range.
What to do instead
Treat the dashboard time range as the default for every panel unless a panel's own search overrides it with fixed earliest/latest values; use a base search with post-processing to share one search across related panels, and verify each panel against the dashboard's selected time range when results look inconsistent.