SPLK-1002 Transactions and Event Correlation Practice Test 2 — 15 Questions

Question 1

A security analyst is writing a search to detect lateral movement across servers by correlating authentication events from multiple domain controllers. Each event has a `user`, `src_ip`, and `dest_ip`. The analyst wants to group events where the same user authenticates from at least 3 different source IPs within 10 minutes. Which TWO components must be part of the search to achieve this? (Choose TWO.)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use `transaction user` to group events by user.. Option A is correct because `transaction user` groups all authentication events sharing the same `user` value into a single transaction, which is exactly the grouping the analyst needs to correlate events per user across domain controllers. Option C is correct because `maxspan=10m` constrains each transaction to events occurring within a 10-minute window, matching the requirement that the 3 distinct source IPs appear within 10 minutes. Option B is not marked correct: `mvcount(src_ip)>=3` counts all values including duplicates, so it would not reliably enforce 3 *distinct* source IPs (and the required distinctness would need `dc(src_ip)>=3` or similar). Option D is wrong because `maxevents=3` caps the number of events per transaction rather than ensuring at least three distinct source IPs. Option E is wrong because `dedup user` would collapse events to one per user before the transaction, destroying the multiple source IP evidence needed for the correlation.

Answer

After the transaction, use `where mvcount(src_ip)>=3` to filter transactions with at least 3 distinct source IPs.

Answer

Use `maxevents=3` to ensure at least three events per transaction.

Answer

Use `dedup user` before the transaction to reduce events.

Question 2

A large e-commerce company uses Splunk to monitor its web application performance. The application logs every HTTP request with fields: `transaction_id`, `url`, `response_time_ms`, `status`. Currently, the team uses the following search to identify slow page loads:

`index=web sourcetype=access_combined | transaction transaction_id maxspan=60s | eval total_time = sum(response_time_ms) | where total_time > 5000`

However, the search returns no results even though there are known slow pages. The team verified that logs contain `transaction_id` values and that some pages take over 10 seconds. What is the most likely reason the search fails to identify slow pages?

Accepted Answer

The `eval total_time = sum(response_time_ms)` is incorrect because after `transaction`, `response_time_ms` is a multivalue field, and `sum()` does not automatically calculate the sum of multivalue fields.. After the `transaction` command, `response_time_ms` becomes a multivalue field containing all the individual response times from the events in the transaction. The `sum()` function in `eval` does not automatically aggregate multivalue fields; it requires explicit use of the `mvsum()` function or a `stats sum()` approach. Without this, `total_time` is not calculated correctly, so the `where` clause never matches, returning no results despite slow pages existing.

Answer

The `maxspan=60s` is too short; some page loads may take longer than 60 seconds, causing incomplete transactions.

Answer

The `transaction` command is grouping by `transaction_id`, but the events might have different transaction_id values for the same page load.

Answer

The field name is misspelled; it should be `response_time` not `response_time_ms`.

Question 3

A financial services company uses Splunk to detect fraudulent transactions. Each transaction event has fields: `user_id`, `amount`, `merchant`, `timestamp`. The fraud detection team wants to identify users who make multiple small transactions (under $50) totaling over $200 within a 1-hour window, which may indicate testing stolen credit cards. They write the following search:

`index=transactions sourcetype=payment amount<50 | transaction user_id maxspan=1h | where sum(amount) > 200`

This search runs but returns no results, even though manual inspection shows users with such patterns. What is the primary reason the search fails?

Accepted Answer

The `where sum(amount) > 200` does not work as expected because `sum()` is not an aggregation function in that context; you need to use `stats sum(amount)` or `eval total=mvsum(amount)` first.. The `transaction` command creates a single multivalue field `amount` containing all amounts from the grouped events. The `where` clause cannot directly aggregate multivalue fields with `sum()`; it requires an explicit `eval` to compute the sum (e.g., `eval total=mvsum(amount)`) or a `stats` command. Without this, the `where` clause evaluates `sum(amount)` as a string operation or fails silently, returning no results.

Answer

The `amount<50` filter is applied before the transaction, which excludes amounts exactly $50.

Answer

The search lacks a `fields` command to include `user_id`, so the transaction fails.

Answer

The `maxspan=1h` is too short; users might spread transactions over more than 1 hour.

Question 4

Which TWO statements correctly describe the behavior of the transaction command in Splunk?

Accepted Answer

It can concatenate the raw text of all events in the transaction into a single event.. Option C is correct because the transaction command groups related events and, by default, produces a single merged event whose raw text (_raw) concatenates the raw text of all events in the transaction (delimited by newlines), which is exactly what it describes. Option E is correct because transaction supports closing conditions via parameters such as maxspan, maxpause, and startswith/endswith, and it can also use the 'close' behavior triggered by a field value change or a specified timeout (e.g., maxpause/maxspan), so transactions can be bounded by field changes or time limits. Option A is not marked correct: while transaction is memory- and performance-intensive and generally discouraged for very large datasets, the statement as phrased is a recommendation rather than a precise description of command behavior, and the exam's correct answers here are C and E. Option B is incorrect because transaction does not simply merge all fields with the last event's value taking precedence; it groups events and can preserve multivalue fields, and field merging behavior is not defined as 'last value wins' for all fields. Option D is incorrect because transaction does not automatically calculate a duration field for each transaction; duration is computed only if you explicitly calculate it (e.g., using eval with the transaction's first and last timestamps), not as an automatic behavior.

Answer

It is not recommended for use with large datasets because it consumes too much memory.

Answer

It merges all fields from all events into a single event, with the last event's field value taking precedence.

Answer

It automatically calculates the duration of each transaction as the difference between the first and last event timestamps.

Question 5

A team is using the transaction command to group web server access logs into user sessions. They notice some sessions are missing because the transaction command defaults to combining events with identical field values if they occur within a default time window. What is the default maxspan value for the transaction command?

Accepted Answer

-1 (no default limit). The default maxspan is -1 (unlimited). Options A, C, and D are common misconceptions but incorrect.

Answer

1 minute

Answer

30 seconds

Answer

5 minutes

Question 6

An analyst wants to group events that start with a 'login' event and end with a 'logout' event, using the username field. Which transaction syntax is correct?

Accepted Answer

transaction username startswith="login" endswith="logout". The correct syntax places the field name immediately after 'transaction' (without 'by'), then uses startswith and endswith with quoted string values. This tells Splunk to group events by the username field while using 'login' and 'logout' as the boundary markers for each transaction. The quoted values are required because startswith/endswith expect string literals.

Answer

transaction username startswith=login endswith=logout

Answer

transaction username startswith="login" endswith="logout" maxspan=2h

Answer

transaction startswith="login" endswith="logout" by username

Question 7

A transaction that groups events by field 'session_id' sometimes produces transactions that contain events from multiple distinct sessions due to session_id reuse over time. What is the best way to ensure transactions are correctly separated?

Accepted Answer

Use 'transaction session_id maxspan=30m' to limit the time window.. The problem is that session_id values are reused over time, so events from different sessions with the same ID get merged into one transaction. Adding maxspan=30m constrains each transaction to a bounded time window, so events separated by more than 30 minutes are split into separate transactions even when session_id matches. This preserves the field-based grouping logic while preventing cross-session merging caused by ID reuse.

Answer

Use 'transaction session_id maxevents=1' to stop after one event.

Answer

Use 'transaction session_id mvlist=_raw' to include raw data.

Answer

Use 'transaction session_id startswith="new_session" endswith="end_session"'.

Question 8

A Splunk search uses 'transaction' to correlate events. The transaction times out before all expected events are added. Which TWO options can be adjusted to allow more time for transaction completion? (Choose two.)

Accepted Answer

Increase 'maxevents'.. Option E is correct because the transaction command's 'maxtime' argument (e.g., transaction maxtime=120s) sets the maximum total duration a transaction may span before it is closed, so increasing it directly allows more wall-clock time for all expected events to arrive and be grouped. Option C is correct because 'maxevents' defines the maximum number of events a single transaction can contain; raising it prevents the transaction from being prematurely closed once the event-count ceiling is hit, letting additional expected events be added. The other options do not apply: 'maxopentxn' (A) is a limits.conf setting controlling how many transactions can be open simultaneously, not how long one may stay open; 'connected=false' (B) only disables the requirement that events be connected by time or fields, which does not extend the timeout; and decreasing 'maxspan' (D) would shorten, not lengthen, the allowed time window for a transaction.

Answer

Increase 'maxopentxn'.

Answer

Set 'connected=false'.

Answer

Decrease 'maxspan'.

Question 9

A security team needs to group login events for the same user within a 5-minute window. Which transaction option should be used to limit the time between consecutive events?

Accepted Answer

maxpause. The maxpause option in the transaction command specifies the maximum time allowed between consecutive events in a transaction. If the gap between two events exceeds maxpause, the transaction is split. This is ideal for grouping login events within a 5-minute window.

Answer

maxspan

Answer

startswith

Answer

endswith

Question 10

A Splunk administrator is correlating events from two sourcetypes using transaction with startswith and endswith. The transaction rarely matches events even though they exist. What is the most likely cause?

Accepted Answer

Events from the two sourcetypes are not in chronological order.. The transaction command groups events into transactions based on startswith/endswith patterns, but it requires events to be processed in chronological order to correctly identify the boundaries. If events from the two sourcetypes are not in chronological order, the transaction command cannot properly match the start and end events, causing transactions to rarely match. Splunk's transaction command relies on the order of events as they appear in the search results, which is typically by timestamp.

Answer

The maxpause value is too high.

Answer

The fields option is missing.

Answer

The startswith and endswith patterns are too broad.

Question 11

A financial company wants to group all events related to a single trading session. The session ID appears in all events. Which is the most efficient way to correlate these events without using transaction?

Accepted Answer

Use stats with values() on the event fields.. Using stats with values() (or a similar aggregation like values(sessionId) grouped by a common field) is the most efficient way to correlate events sharing a session ID because it performs a single-pass aggregation without the memory and performance overhead of transaction or join. The stats command is Splunk's recommended approach for grouping related events when you don't need the raw event sequence preserved.

Answer

Use sort to order events by timestamp.

Answer

Use join to combine events on sessionId.

Answer

Use append with a subsearch.

Question 12

An administrator runs a transaction command that groups events by a customer ID but notices that some transactions are missing expected events. The log shows that the events are present and within the maxpause. What could be the reason?

Accepted Answer

Events are from different hosts or sources.. The transaction command groups events only when they share the same host, source, and sourcetype by default. If the events for a given customer ID arrive from different hosts or sources, they will not be correlated into a single transaction even though they are within maxpause and present in the index. Specifying the fields option (e.g., fields=customer_id) or using the appropriate grouping is required to correlate across hosts/sources.

Answer

The startswith and endswith are conflicting.

Answer

The fields option is missing.

Answer

The maxpause value is too short.

Question 13

Which TWO of the following are valid ways to correlate events without using the transaction command?

Accepted Answer

Using eventstats to compute counts per transactionID. Option D (eventstats to compute counts per transactionID) is correct because eventstats calculates aggregate statistics such as count over a field like transactionID and then adds those results back to each original event, allowing events sharing the same transactionID to be correlated by their computed values without using transaction. Option E (stats ... by transactionID) is correct because stats groups events by transactionID and produces one aggregated row per transaction, which is a standard way to correlate related events by a shared identifier without invoking the transaction command. Option A (append) merely concatenates result sets from separate searches and does not correlate events by any common field. Option B (join) can merge events on transactionID, but it is a different correlation mechanism and is not one of the two marked correct answers here. Option C (sort) only orders events by transactionID and does not aggregate or correlate them into grouped results.

Answer

Using append to combine events from two searches

Answer

Using join to merge events on transactionID

Answer

Using sort to order events by transactionID

Question 14

Which THREE of the following are correct about the transaction command's default behavior?

Accepted Answer

Transaction groups events by host, source, and sourcetype by default.. Option A is correct because the transaction command's default grouping is by host, source, and sourcetype, so events sharing those three fields are candidates for the same transaction unless you override them with the transaction's own fields or mvlist options. Option B is correct because startswith and endswith are optional constraints; without them, transaction simply groups events that are close in time (within maxspan/maxpause) and share the default host/source/sourcetype keys. Option C is correct because transaction enforces maxpause (default 5 seconds) and maxspan (default unlimited) limits, and when a pause exceeds maxpause the current partial transaction is closed/evicted rather than continuing to absorb later events. Option D is wrong because transaction does not require a single host; by default it groups on host, source, and sourcetype, but you can change the grouping fields and events from multiple hosts can be combined if those fields match or are overridden. Option E is wrong because evicted partial transactions are not automatically included in the final results; evicted events are dropped from the transaction output unless you use the keepevicted=true option to retain them.

Answer

Transaction requires all events to come from the same host.

Answer

Transaction always includes all evicted events in the results.

Question 15

Refer to the exhibit. The search returns no transactions even though there are login and logout events in the index. What is the most likely cause?

Accepted Answer

The transaction command may be timing out due to large data volume.. The most likely cause is that the transaction command is timing out due to large data volume. Splunk's transaction command has a default maxspan and maxpause, but it also has a memory limit (maxopentxn) and can time out if the search spans too many events or takes too long. When the transaction command times out, it may return no transactions.

Answer

The maxpause value is too short.

Answer

The startswith and endswith options are mispelled.

Answer

The sourcetype is incorrect.