Transactions and Event Correlation practice questions

transaction by sourcetype transaction_id

Why wrong: Incorrect because it includes `sourcetype` in the `by` clause, which would group events by both `transaction_id` and `sourcetype`, failing to combine events across different sourcetypes.

transaction maxspan=1d by transaction_id

Why wrong: Incorrect because it adds a `maxspan=1d` time constraint, which is explicitly not wanted according to the requirement of 'no time constraints'.

transaction startswith=* endswith=* by transaction_id

Why wrong: Incorrect because it uses `startswith=*` and `endswith=*`, which define markers for transaction boundaries; this is unnecessary and can lead to unexpected results when no specific markers are needed.

It can only correlate events from the same sourcetype.

Why wrong: Incorrect. The `transaction` command can correlate events from different sourcetypes as long as they share common field values.

index=web sourcetype=access_combined status=401 | search clientip=* | head 3

Why wrong: Incorrect: `head 3` limits the results to the first 3 events overall, not grouped by IP or time, and does not perform any correlation.

index=web sourcetype=access_combined status=401 | transaction clientip maxspan=5m maxevents=3

Why wrong: Incorrect: `maxevents=3` limits the maximum number of events per transaction to 3, but the requirement is for transactions with at least 3 events. This option would exclude transactions with more than 3 events and still include those with fewer than 3.

index=web sourcetype=access_combined status=401 | stats count by clientip, _time

Why wrong: Incorrect: `stats count by clientip, _time` provides a count per IP and timestamp but does not group events into transactions or correlate them across time windows.

eventstats max(_time) by username

Why wrong: Incorrect: Adds a field but does not change event grouping.

timechart count by username

Why wrong: Incorrect: Creates a time series chart, not event grouping.

stats values(username) by sourceip

Why wrong: Incorrect: Produces a statistical table, not grouped events.

Use sort to order events by timestamp.

Why wrong: Sort only reorders events by timestamp; it does not group or correlate events.

Use join to combine events on sessionId.

Why wrong: Join combines results from two separate searches on a common field; it is not designed for correlating events within the same search and is less efficient than stats.

Use append with a subsearch.

Why wrong: Append simply adds results from a subsearch to the main results; it does not group or correlate events.

transaction sessionid

Why wrong: transaction sessionid groups events by session ID but imposes no time constraint, so it may include events far apart in time, failing the 5-second window requirement.

join type=inner sessionid [search index=db]

Why wrong: join type=inner sessionid [search index=db] is for joining results from two searches, not for correlating events from different data sources within a time window.

append [search index=db]

Why wrong: append [search index=db] simply appends results, with no correlation logic.

duration

Why wrong: Incorrect. The duration field is added to show the total time span of the transaction, not the start time.

None, the transaction command does not add such a field.

Why wrong: Incorrect. The transaction command does add a field (_time) to indicate the start time.

_starttime

Why wrong: Incorrect. The transaction command does not add a _starttime field. The start time is indicated by the _time field, which is set to the first event's timestamp.

startswith=login endswith=logout

Why wrong: This defines start and end events, but does not handle inactivity timeout.

mvlist=session_id

Why wrong: mvlist is not a valid transaction option; it is used elsewhere.

maxspan=30m

Why wrong: maxspan limits the total duration of the transaction, not the gap between events.

Use the 'kvform' command instead of transaction.

Why wrong: kvform extracts key-value pairs, not correlate events into groups.

Add more fields to the transaction to make it more specific.

Why wrong: Adding fields increases memory usage as more data is stored per transaction.

Increase the maxspan value to 2 hours to reduce the number of transactions.

Why wrong: Increasing maxspan actually may increase the number of events per transaction, worsening memory usage.

transaction startswith="GET" endswith="POST" maxevents=2

Why wrong: Incorrect because it adds `maxevents=2`, which limits the transaction to two events. A user visit may involve more than two events (e.g., multiple GETs and POSTs), so this constraint is unnecessary and may miss valid transactions.

transaction startswith="POST" endswith="GET"

Why wrong: Incorrect because it reverses the start and end events. A visit should start with GET and end with POST, not start with POST and end with GET.

transaction by src_ip startswith="GET" endswith="POST"

Why wrong: Incorrect because adding `by src_ip` groups transactions by source IP. While this could be useful for separating different users, the requirement did not specify grouping by IP, and the simplest correct answer without extra fields is C.

Increase maxspan to allow more events to complete.

Why wrong: Increasing maxspan may include more events but does not specifically address orphans and could worsen performance.

Use the 'mvlist' option to list all user_uuid values.

Why wrong: mvlist is not a valid transaction option.

Add 'closed_txn=1' to the transaction command to only output complete transactions.

Why wrong: closed_txn is not a valid transaction option.

It requires all events to be from the same source.

Why wrong: Transaction can correlate events from different sources as long as they share a common field.

It sums numeric field values across events in the transaction.

Why wrong: It does not sum values; it concatenates them in a multivalue field.

The 'maxevents' option limits the total number of transactions output.

Why wrong: maxevents limits events per transaction, not number of transactions.

Events must be from the same sourcetype.

Why wrong: Transaction can correlate across different sourcetypes.

Events must appear in chronological order with no missing timestamps.

Why wrong: Transaction handles events in order based on _time, but missing timestamps are not a requirement.

The sourcetype filter is excluding some events.

Why wrong: The sourcetype is specified correctly; no exclusion is implied.

The stats command is not correctly summing the counts.

Why wrong: stats count by clientip is correct; the issue is upstream.

The maxspan is too short to capture all events for each clientip.

Why wrong: maxspan=30m may be insufficient, but the issue is more likely maxevents.

The maxpause=5m is too short, causing the transaction to close before other events occur.

Why wrong: Even if maxpause were longer, other events lack the session_id to join.

The transaction command requires that all events have a non-null session_id to be grouped.

Why wrong: Transaction groups events with the same session_id; null values are treated as a group, but only events with null session_id would group together.

The sourcetype filter is too restrictive.

Why wrong: The sourcetype is correctly set to linux_secure.

Use `append` to combine the two sourcetypes and then `search` for the pattern

Why wrong: Append does not correlate events; it just adds rows.

Use `eventstats` to compute counts by sessionID and then filter

Why wrong: Eventstats adds aggregated values but does not enforce a time window for correlation.

Use `stats` with values() and a by clause on sessionID

Why wrong: Stats groups events but does not enforce time proximity between different sourcetypes.

`transaction user,ip,action maxspan=10m`

Why wrong: Using multiple fields for grouping would create separate transactions for each unique combination, which is not intended.

`transaction user maxpause=30s`

Why wrong: Maxpause would break the transaction if events are more than 30 seconds apart, which is too restrictive for a 10-minute pattern.

`transaction user mvcount=3`

Why wrong: mvcount is not a valid transaction parameter.

Increase the maxspan value

Why wrong: Increasing maxspan includes more events per transaction, increasing memory usage.

Remove the maxspan constraint

Why wrong: Removing maxspan could cause transactions to stay open longer, increasing memory.

Set keepevicted=false

Why wrong: While this helps, the primary issue is high cardinality; keepevicted=false may not be enough.

`append [search sourcetype=app_log]` then sort by session_id

Why wrong: Append does not correlate; it just adds events.

`sourcetype=web_access OR sourcetype=app_log | eval session=session_id` then `stats values(*) as * by session`

Why wrong: Stats with values does not preserve time proximity between events.

`join type=inner session_id [search sourcetype=app_log]` after a search on web_access

Why wrong: Join can be inefficient and does not handle time proximity.

Decrease maxspan to 30 seconds

Why wrong: Shorter maxspan would break transactions earlier, missing more scans.

Remove maxpause and use only maxspan

Why wrong: Without maxpause, transactions could remain open too long, increasing false positives and memory usage.

Group by destination IP instead of source IP

Why wrong: Changing the grouping field does not address the pause issue.