SPL Search Proficiency practice questions

eval status!=200

Why it fails: Eval is for creating or modifying fields, not filtering events.

where status=200

Why it fails: This includes only 200 status events.

drop status=200

Why it fails: There is no 'drop' command in SPL.

index=auth | delta _time as time_diff by user_id

Why it fails: The delta command calculates differences between successive rows, not event pairs.

index=auth | stats min(_time) as start, max(_time) as end by user_id | eval delta=end-start

Why it fails: This logic assumes only one pair of events per user, which is inaccurate.

index=auth | eval time_diff = logout_time - login_time

Why it fails: This requires pre-processing the log events to have both timestamps on the same line.

index=security sourcetype=auth failed_login | stats count as count by src_ip | sort -count | head 5

Why it fails: While this works, the top command is more efficient for this specific requirement.

index=security sourcetype=auth failed_login | table src_ip | count

Why it fails: This syntax is invalid.

index=security sourcetype=auth failed_login | cluster src_ip | head 5

Why it fails: Cluster is for pattern discovery, not frequency counts.

index=firewall | enrich src_ip threat_intel.csv

Why it fails: Enrich is not a valid Splunk command.

index=firewall | join src_ip [inputlookup threat_intel.csv]

Why it fails: Join is generally less performant than lookup for simple enrichment.

index=firewall | inputlookup threat_intel.csv src_ip

Why it fails: Inputlookup retrieves data from the file, it does not join it to the current search pipeline.

index=firewall | append threat_intel.csv

Why it fails: Append requires a search sub-command, not a file path.

index=network | inputlookup authorized_servers.csv | where dest_ip!=ip_address

Why it fails: This pipes the lookup's rows into the search, replacing the network events entirely, so the where clause compares lookup fields against themselves rather than filtering index=network results. It is tempting because inputlookup does read the CSV, but that command is for loading lookup contents as search results, not for enriching or excluding events.

index=network | lookup authorized_servers.csv dest_ip | where isnull(dest_ip)

Why it fails: The lookup writes the CSV's ip_address field over dest_ip, so isnull(dest_ip) tests the overwritten value, not whether dest_ip matched. It is tempting because lookup with a field argument is the standard enrichment pattern, and it would be correct if the lookup output field were named distinctly and tested for null.

index=network | filter dest_ip NOT IN authorized_servers.csv

Why it fails: filter is not a Splunk search command, and NOT IN against a CSV filename is not valid syntax, so the search fails to parse. It is tempting because SQL-style NOT IN reads naturally for exclusion, but Splunk achieves this with inputlookup plus a subsearch or lookup and isnull on a distinctly named output field.

table src_ip, dest_ip

Why it fails: Table is for formatting, but 'fields' is the specific command for controlling field visibility.

select src_ip, dest_ip

Why it fails: There is no 'select' command.

show src_ip, dest_ip

Why it fails: There is no 'show' command.

eval is_critical = if(severity=="high" || "critical", "yes", "no")

Why it fails: The if() function's first argument must evaluate to a boolean; "critical" is a non-empty string, always true, so every event returns "yes". It tempts because if() is the right function for two-branch conditions, but the test needs severity=="high" OR severity=="critical".

eval is_critical = case(severity="high" OR "critical", "yes", 1=1, "no")

Why it fails: case() takes boolean expressions, yet severity="high" assigns rather than compares, and OR "critical" is invalid syntax. It tempts because case() genuinely handles multi-condition branching, but each condition must be a full comparison such as severity=="high" OR severity=="critical".

eval is_critical = switch(severity, "high", "yes", "critical", "yes")

Why it fails: switch() matches one field against listed values, but here it returns "yes" for high and critical and no default, so non-matching events yield null instead of "no". It tempts because switch() is designed for mapping discrete values, which fits when every possible value is enumerated.

set_time -24h

Why it fails: set_time is not a Splunk command or subsearch option; no such syntax exists, so the search fails to parse. It is tempting because it reads like a time-setting clause, and would be correct only if Splunk actually exposed such an argument, which it does not.

subsearch_time=-24h

Why it fails: subsearch_time is not a valid Splunk argument; the subsearch time range is set with the subsearch's own earliest and latest modifiers. It is tempting because the name describes the intent precisely, and would be correct if Splunk supported that parameter, which it does not.

filter_outliers

Why it fails: There is no 'filter_outliers' command.

find_outliers

Why it fails: There is no 'find_outliers' command.

stats anomaly count

Why it fails: There is no 'stats anomaly' command.

eval count = number(count)

Why it fails: The number function converts a string to a numeric value, but the question asks how to ensure a field is treated as a number for calculation, which eval with tonumber achieves directly. It is tempting because number conversion sounds equivalent, and would be correct when converting a string field to a number.

cast(count as int)

Why it fails: The cast function converts a value to a specified type but does not itself guarantee numeric treatment for calculation in the way the question requires. It is tempting because casting is a common type-conversion approach, and would be correct when you need to explicitly change a field's data type for output.

eval count = int(count)

Why it fails: There is no 'int()' function in eval.

$

Why it fails: The dollar sign is used for field variables.

?

Why it fails: The question mark is not used as a wildcard in basic SPL searches.

%

Why it fails: The percent sign is used in SQL, not SPL.

chart count by _time | bucket 1h

Why it fails: This is incorrect syntax.

stats count by _time_hour

Why it fails: _time_hour is not a default field, so stats count by _time_hour returns nothing unless calculated first. It is tempting because it reads like a ready-made hourly field, and would be correct after eval _time_hour=strftime(_time,"%H") or similar extraction.

eval

Why it fails: eval computes or overwrites field values; it neither removes events nor caps result counts. It is tempting because eval can create a field used later for filtering, but the commands that actually limit returned results are head and dedup, which discard events outright.

stats

Why it fails: stats aggregates events into summary rows, so it transforms rather than removes or limits results. It is tempting because a stats output often has fewer rows, but that reduction is a by-product of grouping; head and dedup are the commands that directly limit or remove results.

rename

Why it fails: rename only changes field names on events passing through; it never discards events or caps the result count. It is tempting because renaming can precede filtering, but the commands that actually remove or limit returned results are head and dedup, which drop events from the pipeline.

collect count by host

Why it fails: There is no 'collect' command for this.

stats count by host

Why it fails: Stats discards the original raw events.

streamstats count by host

Why it fails: Streamstats calculates cumulative totals, not the total count for the group.

eval

Why it fails: eval computes per-event expressions and needs no grouping field; it operates row by row. It is tempting because eval is often used alongside stats-style aggregations, but in scenarios requiring calculated fields on individual events, eval alone is exactly the right command.

search

Why it fails: search filters events using boolean expressions and requires no grouping field. It is tempting because search terms often reference fields produced by prior aggregation, but where plain event filtering is needed, search is precisely the correct command.

rename

Why it fails: rename alters field names on a per-event basis and needs no grouping field. It is tempting because renaming frequently follows stats output, but in scenarios where fields must be relabelled without aggregation, rename is exactly the right command.

stats

Why it fails: The stats command aggregates and summarises results into a table, which is analysis rather than visualisation preparation; it does not restructure fields for charting. It is tempting because stats output frequently feeds charts, but the visualisation-prep commands are table and fields, which explicitly format data for rendering.

fields

Why it fails: The fields command includes or excludes fields from results but does not compute or transform values for charting. It is tempting because trimming fields feels like preparation, yet visualisation prep requires table to arrange columns and eval to create calculated fields the chart consumes.

eval

Why it fails: The eval command calculates and assigns new field values, which is data enrichment rather than visualisation preparation. It is tempting because calculated fields often appear in charts, but the commands that prepare results for visualisation are table, which orders columns, and fields, which selects them.

lookup

Why it fails: lookup enriches events by matching fields against an external table; it does not report which fields exist in the events. It is tempting because it operates on field names, but field discovery is provided by fieldsummary and the metadata command.

eval

Why it fails: eval calculates new or modified field values using expressions; it does not report which fields are present in the events. It is tempting because it references field names, but field discovery is performed by fieldsummary and the metadata command.

sort

Why it fails: sort orders results by specified fields; it does not report which fields exist in the events. It is tempting because it requires naming fields, but field discovery is provided by fieldsummary and the metadata command, which list fields and their attributes.

index=security sourcetype=linux_secure action=failure | top limit=0 src_ip

Why it fails: The top command does return the most common values of src_ip, but with limit=0 it can return an unbounded number of results rather than a clean ranked report. It also adds extra fields like percent and count but does not guarantee the same simple tabular output the analyst wants. For a straightforward count per source, stats with sort is more precise.

index=security sourcetype=linux_secure action=failure | table src_ip | dedup src_ip

Why it fails: The table command only extracts the src_ip field into a results table, and dedup removes duplicate source IP values. This produces a list of unique IPs with no count of attempts, so it cannot show which source is most active. It fails to aggregate or rank the failed login attempts in any way.

index=security sourcetype=linux_secure action=failure | transaction src_ip

Why it fails: The transaction command groups related events into a single transaction per src_ip, which can be heavy and is intended for event correlation, not simple counting. It does not produce a count of failed attempts per source IP, and using transaction for high-volume brute-force data is inefficient. It does not meet the requirement to rank sources by attempt count.

timechart span=5m sum(bytes) by src_ip, dest_ip | where sum > 10000000

Why it fails: The timechart command creates a time-series chart with a separate column for each src_ip-dest_ip pair, but the where clause comparing 'sum' is invalid because timechart produces columns named after the by-clause values, not a field called 'sum'. Additionally, timechart is designed for visualization and may not handle high-cardinality by-clauses efficiently. This approach would not correctly filter for pairs exceeding the threshold.

stats sum(bytes) as total_bytes by src_ip, dest_ip | where total_bytes > 10000000

Why it fails: The stats command sums bytes for each source-destination pair across the entire search time range, not within a 5-minute window. Without a time-based grouping, it aggregates all traffic over the entire period, which could mask short bursts of large transfers. This fails to detect exfiltration that occurs within a specific 5-minute window, as it only provides a total over the whole search period.

bucket _time span=5m | stats sum(bytes) as total_bytes by src_ip, dest_ip | where total_bytes > 10000000

Why it fails: The bucket command is an alias for bin and works similarly, but the stats command here does not include _time in the by-clause. Therefore, it sums bytes for each source-destination pair across all 5-minute buckets combined, not per bucket. This aggregates over the entire time range, losing the per-window granularity needed to detect transfers exceeding 10 MB within any single 5-minute window.

where bytes_out > 1073741824

Why it fails: This where command filters individual events where bytes_out exceeds 1 GB, but the requirement is to sum bytes_out per user and then check the total. Filtering individual events would miss cases where multiple smaller transfers accumulate to over 1 GB, so it is not the correct approach.

transaction user maxspan=1h

Why it fails: The transaction command groups events by user within a time span, but it does not aggregate bytes_out or classify external IPs. It is not essential for this detection and would not help in summing total bytes per user or flagging external destinations.

lookup external_ips dest_ip

Why it fails: A lookup could be used to identify external IPs if a lookup table exists, but the scenario does not mention such a table. The eval with cidrmatch is a self-contained method. The lookup is not essential and would require additional configuration not specified.