Advanced Searching and Statistics practice questions

status=200 OR status=404 | search status!=null

Why wrong: Incorrect because `search status!=null` uses invalid syntax; Splunk does not support `!=null` for field existence checks.

NOT ISNULL(status) (status=200 OR status=404)

Why wrong: Incorrect because the search is missing an AND operator between `NOT ISNULL(status)` and `(status=200 OR status=404)`. Without the AND, the search is syntactically invalid and will produce an error.

status=200 OR status=404

Why wrong: Incorrect because it does not exclude events where the `status` field is missing; it only selects events with status 200 or 404, but still includes events without a status field.

| eval bucket=if(response_time<100,"fast",response_time<500,"medium","slow")

Why wrong: if function syntax is incorrect; case should be used for multiple conditions.

| where response_time<100 | eval bucket="fast" | append [search where response_time>=100 AND response_time<=500 | eval bucket="medium"]

Why wrong: This is inefficient and uses subsearches unnecessarily.

(status=error OR status=critical) bytes>1000

Why wrong: Although this search works because parentheses group the OR conditions, it uses implicit AND (space) which is less readable. Option C is clearer and preferred.

status=error OR status=critical AND bytes>1000

Why wrong: This search is incorrect due to operator precedence: AND binds tighter than OR, so it is interpreted as status=error OR (status=critical AND bytes>1000), which does not match events where status=error without bytes>1000.

status="error" OR status="critical" bytes>1000

Why wrong: This search uses implicit AND and parentheses, but the quotes around values are unnecessary for simple strings. It works but is less concise than option C.

The transaction command uses a sliding time window to detect transaction boundaries.

Why wrong: This is false. The `transaction` command uses a fixed or pause-based window, not a sliding time window.

The transaction command removes all fields except those specified in the `fields` argument.

Why wrong: This is false. The `transaction` command does not remove all fields; it retains and adds fields.

`index=security | lookup malicious_ips.csv src_ip | search threat=*`

Why wrong: The lookup command without OUTPUT does not add any fields; 'threat' will not exist.

`index=security [| inputlookup malicious_ips.csv | fields ip | rename ip as src_ip]`

Why wrong: Subsearch returns only matching src_ip values, but does not add the threat field; also may be inefficient.

`index=security | lookup malicious_ips.csv src_ip AS ip | where isnotnull(threat)`

Why wrong: The lookup field mapping is wrong; it should map src_ip to ip, not the other way.

Use 'convert num(bytes)' before stats.

Why wrong: The convert command is deprecated and may not work as expected in all versions; also, it modifies the field in place which could cause issues.

Use 'where isnum(bytes)' to filter out non-numeric values before stats.

Why wrong: This may remove events where bytes is numeric but stored as string, but it does not convert; sum would still treat as string.

Use 'eval bytes = string(bytes)' before stats.

Why wrong: This would keep bytes as string, not numeric, and sum would not work correctly.

rex "ip=(?\d+\.\d+\.\d+\.\d+)"

Why wrong: Incorrect because the named capture group syntax is missing the opening angle bracket. The correct Splunk syntax is `(?<name>...)`, not `(?name...)`.

rex field=_raw "ip=(?P<ip>\d+\.\d+\.\d+\.\d+)"

Why wrong: Incorrect because it uses `?P` which is Python syntax, not Splunk syntax. Splunk uses `?<name>` for named groups.

rex field=_raw "ip=(?<ip>\d+\.\d+\.\d+\.\d+)"

Why wrong: Although the regex pattern is valid and matches an IPv4 address (four octets), the explicit `field=_raw` is redundant. The `rex` command defaults to operating on the `_raw` field, so specifying it is unnecessary and is not the expected syntax for this question.

To filter out results with count ≤ 100.

Why wrong: `eval` does not filter; `where` does filtering.

To modify the 'count' field.

Why wrong: `eval` does not modify 'count'; it creates a new field.

To rename the 'count' field to 'severity'.

Why wrong: `eval` creates a new field; `rename` is used for renaming.

user="admin" OR user="root"

Why wrong: Uses quoted values with OR, which is correct for exact match but less concise than option D.

user=*admin* OR user=*root*

Why wrong: Uses wildcards, matching any occurrence of 'admin' or 'root' within the field, not an exact match.

user IN ("admin", "root")

Why wrong: Uses the IN operator, which is also an exact match method, but it is not necessarily better than option D for simple values.

| stats max(bytes) as max_bytes by user | sort - max_bytes | head 5

Why wrong: This shows maximum bytes, not total bytes.

| sort - bytes | head 5 | table user, bytes

Why wrong: This shows the top 5 events by bytes, not aggregated by user.

| top limit=5 user

Why wrong: top command shows the most frequent values, not sum of bytes.

Add maxspan=5m to the transaction command

Why wrong: maxspan limits the time span of transactions, not the event count.

| transaction maxevents=2 ...

Why wrong: maxevents limits the number of events per transaction, but still includes single-event transactions.

| transaction ... | where eventcount=2

Why wrong: This would only keep transactions with exactly 2 events, not all with more than 1.

The count() function must always include a field argument.

Why wrong: count() can be used without a field to count events.

It creates one event per input event by default.

Why wrong: stats aggregates events, reducing them to one row per group (or overall).

It can be used to modify individual field values in raw events.

Why wrong: stats does not modify raw events; it produces statistical summaries.

| stats count(field)

Why wrong: count(field) counts non-null values, not distinct.

| stats distinct_count(field)

Why wrong: distinct_count is not a valid function; dc() is used.

The lookup file is not in CSV format.

Why wrong: If it were not CSV, inputlookup would error.

The stats command only counts events where role=admin, but the role field is already filtered.

Why wrong: The search command already filters role=admin, so stats count would show count of admin events.

The search command runs before the eval command.

Why wrong: The pipeline runs in order; eval happens before search.

The regex pattern is incorrect; it should use \b for word boundaries.

Why wrong: The pattern is correct for matching IPs; \b is optional.

The top command is modifying the extracted ip field.

Why wrong: top only counts occurrences; it doesn't modify the field.

The rex command must be placed before the index search.

Why wrong: index search runs first; rex is applied to results.

index=main earliest=-24h | timechart span=1h values(user)

Why wrong: values(user) produces a multivalue field but does not count them.

index=main earliest=-24h | stats dc(user) by _time | timechart span=1h dc(user)

Why wrong: stats by _time creates one row per second, not hourly bins. timechart would then use those tiny bins.

index=main earliest=-24h | timechart span=1h count by user

Why wrong: This creates separate series for each user, not a single count of unique users.

eventstats

Why wrong: eventstats adds aggregation to each event but does not produce a summary table.

sort

Why wrong: sort sorts events but does not count or summarize.

rare

Why wrong: rare shows the least common values, not the top.

Use `eventstats avg(response_time) as avg, stdev(response_time) as stdev` then `where response_time > avg+2*stdev`

Why wrong: This calculates overall stats, not per host.

Use `streamstats avg(response_time) as avg, stdev(response_time) as stdev by host` then `where response_time > avg+2*stdev`

Why wrong: streamstats calculates running stats per host, not overall per host.

Use `stats avg(response_time) as avg, stdev(response_time) as stdev by host` then `where response_time > avg+2*stdev`

Why wrong: stats removes original events, so you cannot compare response_time afterwards.

index=main | timechart count | search status=*fail*

Why wrong: After timechart, the status field is no longer present.

index=main | regex status="fail" | timechart count

Why wrong: regex does not use glob matching; it expects regex pattern, so "fail" would match literal "fail" but not case-insensitive.

index=main | where status="*fail*" | timechart count

Why wrong: where uses case-sensitive and does not support wildcards; use like instead.

... | join type=inner [search index=other]

Why wrong: join uses a subsearch but it's not a way to create a subsearch; it's a command that uses a subsearch.

[return index=main | stats count]

Why wrong: return is used inside a subsearch to output specific fields, not to create a subsearch.