Transactions and Event Correlation →hardMultiple ChoiceObjective-mapped

SPLK-1002 Transactions and Event Correlation Practice Question

Exhibit

Refer to the exhibit.
```
index=main sourcetype=linux_secure
| eval stage=case(
    like(_raw,"%Failed password%"),"failed",
    like(_raw,"%Accepted password%"),"success")
| transaction src maxspan=5m
| search stage="*"
| eval attack=if(mvcount(stage)>2 AND mvcount(stage)>=2 AND mvfind(stage,"failed")!=-1 AND mvfind(stage,"success")!=-1,"yes","no")
| where attack="yes"
```

Refer to the exhibit. The search aims to detect brute-force attacks where there are at least 2 failed logins followed by a successful login from the same source IP within 5 minutes. However, the search returns no results even though such attacks exist. What is the most likely error in the search logic?

⚠ Common exam trap

Splunk often tests the subtle difference between `field="*"` (literal asterisk) and `field=*` (wildcard) in the context of multivalue fields, tricking candidates into thinking a quoted wildcard works the same as an unquoted one.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The `search stage="*"` command is filtering out all transactions because stage is a multivalue field.

The `search stage="*"` command filters out all transactions because `stage` is a multivalue field created by the `transaction` command. In Splunk, a multivalue field cannot be matched with a simple wildcard search like `stage="*"`; this search only returns events where `stage` is a single literal asterisk. To search for any value in a multivalue field, you must use `mvcount(stage)>0` or `search stage=*` (without quotes).

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The transaction should group by user instead of src.
Why it's wrong here
Grouping by src (source IP) is appropriate for detecting brute-force from an IP.
✗
The case statement does not set stage for events that don't match either pattern.
Why it's wrong here
All events should match at least one condition; if not, stage is null, but that would be filtered by the search stage="*" anyway.
✗
The mvcount(stage) condition is incorrectly checking for >2 and >=2 simultaneously.
Why it's wrong here
The condition is redundant but not incorrect; it requires at least 3 events (2 fails + 1 success).
✓
The `search stage="*"` command is filtering out all transactions because stage is a multivalue field.
Why this is correct
Searching stage="*" does not match multivalue fields; it matches a literal asterisk. Should use `where isnotnull(stage)`.

Go deeper

SPLK-1002 Transactions and Event Correlation Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question