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

Question 1

Which three conditions can cause a transaction to close prematurely? (Choose three.)

Accepted Answer

The maxevents value is reached.. Option A is correct because in Splunk transaction searches, the maxevents setting caps the number of events a transaction can contain; once that count is reached, the transaction closes prematurely even if no closing condition has occurred. Option C is correct because maxpause defines the maximum allowable time gap between consecutive events in a transaction, so if the interval between two events exceeds that value, the transaction is terminated. Option D is correct because maxspan sets the maximum total duration of a transaction from its first event; when that span is reached, the transaction closes. Option B is not correct because startswith defines the event that begins a transaction, not a condition that ends one, and re-encountering it would typically start a new transaction rather than close the current one. Option E is not correct because endswith is the normal, intended closing condition for a transaction, not a premature termination cause.

Answer

The startswith event is encountered again.

Answer

The endswith event is detected.

Question 2

Which two techniques should be used to optimize a transaction search that is slow due to a high volume of events? (Choose two.)

Accepted Answer

Use the 'fields' command to limit fields before transaction.. Option A is correct because placing the 'fields' command before 'transaction' reduces the amount of data carried into the transaction processing, lowering memory and CPU usage so the search runs faster. Option C is correct because replacing 'transaction' with 'stats' using values() and range() achieves similar grouping results without the high memory cost of transaction, which is the main cause of slowness with high event volume. Option B is wrong because 'keepevicted' retains evicted search results rather than freeing memory, which would not optimize a slow transaction search. Option D is wrong because the 'local' parameter is not a valid way to force processing onto a single indexer and does not address transaction performance. Option E is wrong because increasing maxspan would group more events into each transaction, increasing memory usage and making the search slower, not faster.

Answer

Use the 'keepevicted' option to free memory.

Answer

Use the 'local' parameter to process on a single indexer.

Answer

Increase the maxspan value to reduce the number of transactions.

Question 3

A Splunk admin wants to group events from the same user session in web logs. Which transaction option should be used to ensure the transaction ends after 30 minutes of inactivity?

Accepted Answer

maxpause=30m. The maxpause option defines the maximum time gap between events in a transaction; setting maxpause=30m ends the transaction when 30 minutes of inactivity occurs between events. This directly matches the requirement to group events from the same user session and close it after 30 minutes of inactivity.

Answer

keepevicted=true

Answer

maxspan=30m

Answer

maxevents=100

Question 4

An analyst runs the following search to correlate login and logout events: `index=auth | transaction user startswith="LOGIN" endswith="LOGOUT"`. However, some transactions span over 24 hours. Which option should be added to limit each transaction to a maximum of 8 hours?

Accepted Answer

maxspan=8h. maxspan limits the total duration of a transaction from its first event to its last event, so maxspan=8h caps each transaction at 8 hours. This directly addresses the requirement to prevent transactions from spanning more than 8 hours. It is the correct parameter for bounding total transaction duration.

Answer

maxevents=10

Answer

duration=8h

Answer

maxpause=8h

Question 5

A security team notices that using `transaction` on a large dataset of firewall logs causes memory issues. Which alternative approach would most efficiently correlate events while reducing resource consumption?

Accepted Answer

Use `stats` by session_id list(src_ip), list(dest_ip) with `bin` time. Using `stats` with `bin` on time and grouping by session_id, then listing src_ip and dest_ip, is the most efficient alternative. The `stats` command is a streaming, memory-efficient aggregation that does not hold all events in memory like `transaction` does, and `bin` buckets events into time windows to approximate session grouping. This correlates events while dramatically reducing resource consumption.

Answer

Use `concurrency` command to group events

Answer

Increase `maxtransize` and `maxopentxn` in limits.conf

Answer

Use `append` with subsearch to join events

Question 6

A company uses `transaction` to group events by `order_id`. Some orders have many events (1000+). Which option should be added to prevent a single transaction from consuming too many resources?

Accepted Answer

maxevents=500. Adding maxevents=500 to the transaction command limits each transaction to a maximum of 500 events, preventing any single transaction from consuming excessive resources. This directly addresses the concern of orders with 1000+ events by capping the transaction size while still grouping events by order_id. It is the most appropriate option for resource control.

Answer

keepevicted=true

Answer

maxspan=1h

Answer

maxpause=5m

Question 7

A search uses `transaction` with wildcard fields (e.g., `*id`), causing poor performance. What is the best practice to optimize this?

Accepted Answer

Specify exact field names instead of wildcards. Using wildcard field names in the transaction command (e.g., *id) forces Splunk to scan all fields to find matches, which is inefficient and can cause poor performance. Specifying exact field names allows Splunk to directly access the relevant fields, reducing processing overhead and improving search speed. This is the best practice for optimizing transaction performance.

Answer

Use `transaction *id, nullif=null`

Answer

Increase maxopentxn in limits.conf

Answer

Replace transaction with stats

Question 8

A team wants to correlate events from different sourcetypes (web, db) on a common `sessionid`. They use `transaction sessionid` across both sourcetypes. The results show that some transactions are missing events. What is the most likely cause?

Accepted Answer

Timestamps from different sourcetypes are misaligned. Transaction search correlates events based on timestamps and fields; if timestamps from different sourcetypes are misaligned (e.g., due to time zone differences or clock skew), events may fall outside the transaction window, causing missing events. This is the most likely cause when correlating across sourcetypes.

Answer

The search is running at 'info' level instead of 'verbose'

Answer

maxevents is set too low

Answer

sessionid field has different names in each sourcetype

Question 9

Which THREE statements about the `transaction` command are true?

Accepted Answer

It can correlate events from different sourcetypes. Option A is correct because the transaction command groups events into transactions based on fields or time constraints regardless of sourcetype, so events from different sourcetypes can be correlated into the same transaction. Option C is correct because transaction sorts the events within each transaction by the _time field, presenting them in chronological order. Option D is correct because transaction operates on search results that can span multiple indexes, allowing correlation of events across indexes as long as they share the grouping criteria. Option B is incorrect because maxevents limits the maximum number of events in a transaction, not the number of unique field values. Option E is incorrect because transaction does not automatically produce summary indexing output; summary indexing requires separate mechanisms such as the collect command or scheduled searches.

Answer

The maxevents option limits the number of unique field values per transaction

Answer

Transaction always produces summary indexing output

Question 10

Refer to the exhibit. An analyst runs the above search to test transaction behavior. What is the likely result?

Accepted Answer

Multiple transactions, each with fewer events, avg duration less than 10s. The search uses `transaction` with `maxspan=10s`. The random timestamps are spread over up to 100 seconds, so events that are more than 10 seconds apart cannot be in the same transaction. Thus, the events will be split into multiple transactions, each containing a subset of the events. The average duration of these transactions will be well under 10 seconds, making option C correct. Option A is incorrect because not all 5 events can fit into one 10-second window. Option B is incorrect for the same reason. Option D is incorrect because transactions are still created for events that do fall within a 10-second window.

Answer

One transaction with 5 events, avg duration ~50s

Answer

One transaction with 5 events, avg duration ~10s

Answer

No transactions created because events are out of order

Question 11

A large e-commerce company uses Splunk to analyze customer purchase funnels. Their environment includes 10 indexers and a search head cluster. They have a search that runs every 5 minutes to correlate events from web logs, order logs, and payment logs using the `transaction` command on a common `order_id` field. The search uses `transaction order_id maxevents=50 maxspan=30m`. Recently, users have reported that some orders are missing from the results, especially for high-volume periods. The team also notices that dashboard searches often timeout. They suspect the transaction command is the bottleneck. Upon examining the search, they see that the web logs alone generate hundreds of events per order. Which course of action would best address the missing orders and performance issues?

Accepted Answer

Replace transaction with stats by order_id, using list() for relevant fields and evaluating event order separately. The `transaction` command is resource-intensive and can cause timeouts and missing data when `maxevents` is exceeded. Increasing `maxevents` (A) would worsen performance. Removing `maxpause` and increasing `maxspan` (B) does not address the `maxevents` limit and may keep transactions open longer. Reducing `maxevents` (C) would exacerbate missing orders. Replacing `transaction` with `stats ... list() by order_id` groups fields without holding open transactions, avoiding the `maxevents` constraint and reducing resource usage, thus addressing both missing orders and performance issues.

Answer

Increase maxevents to 200 and increase search timeout

Answer

Remove maxpause and set maxspan to 60m

Answer

Reduce maxevents to 10 to limit resource usage

Question 12

A security team needs to group all login events from the same user session. Events include 'login' and 'logout' with a common session_id field. Which command should be used to combine these events into a single event per session?

Accepted Answer

transaction session_id. The transaction command is designed to group related events into a single transaction based on a common field such as session_id, using parameters like maxspan, maxpause, and startswith/endswith to define boundaries. It is the canonical Splunk command for sessionization of login/logout event pairs.

Answer

join session_id

Answer

stats by session_id

Answer

append session_id

Question 13

An analyst runs `transaction user_id` to correlate events from a web server. The resulting transaction events have a field 'duration' that shows the time between the first and last event. However, some transactions span over 30 minutes. What transaction option should be added to limit the maximum time between the first and last event?

Accepted Answer

maxspan=30m. The maxspan option sets the maximum time span from the first event to the last event in a transaction.

Answer

maxpause=30m

Answer

maxevents=30

Answer

contime=30m

Question 14

An analyst writes `transaction client_ip` to group events from a firewall. The resulting transactions show many events with duration=0. What is the most likely cause?

Accepted Answer

There is only one event per client_ip in the time range. The transaction command groups events that share the same client_ip value. If each client_ip appears only once in the searched time range, each transaction will contain a single event, resulting in a duration of 0 because there is no time difference between events. The duration is calculated as the time difference between the first and last event in the transaction. With only one event, the duration is zero.

Answer

The client_ip field contains duplicates

Answer

The transaction option maxspan is set too high

Answer

The events are not time-stamped properly

Question 15

Which TWO options can be used with the `transaction` command to define the beginning and end of a transaction?

Accepted Answer

endswith. The `transaction` command in Splunk groups events into transactions, and its `startswith` and `endswith` arguments explicitly define the beginning and end of each transaction: `startswith` specifies the search term or field value that marks the first event, while `endswith` specifies the term or value that marks the final event, so options D and C are correct. These two options work together to bound a transaction by matching events, which is exactly what the question asks for. The other options do not define transaction boundaries: `maxpause` (B) sets the maximum time between events for them to remain in the same transaction, `maxspan` (E) limits the total duration of a transaction, and `closed_txn` (A) is not a valid `transaction` command argument.

Answer

closed_txn

Answer

maxpause

Answer

maxspan