SPLK-1002 Practice Test 28 — 15 Questions

Question 1

A user runs a search on web access logs: `index=web | eventstats sum(bytes) as total_bytes by host`. The search returns the correct total bytes per host, but now the user needs to calculate the average bytes per host for each event. Which command should be added to the base search to achieve this?

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

Accepted Answer

Add `| eventstats avg(bytes) as avg_bytes by host` after the first eventstats.. Adding `| eventstats avg(bytes) as avg_bytes by host` after the first eventstats computes the average bytes per host for each event, preserving all raw events. Option B is incorrect because streamstats would compute a running (cumulative) average, not the overall average per host. Option C is incorrect because it attempts `eval avg_bytes = total_bytes / count`, but `count` is not a field available in each event; moreover, it would require a per-host count, which is not directly available without another aggregation. Option D is inefficient and unnecessary, as `stats` would aggregate away the events, and `join` is slow and can cause issues with large datasets.

Answer

Replace eventstats with `| streamstats avg(bytes) as avg_bytes by host`.

Answer

Add `| eval avg_bytes = total_bytes / count` after the eventstats.

Answer

Use `| stats avg(bytes) by host` then `| join host [search index=web]`.

Question 2

A Splunk administrator notices that a scheduled saved search titled 'Nightly_Threat_Report' is not completing on time. The search runs at 2:00 AM daily and typically takes 15 minutes, but recently it has been timing out after 30 minutes. The search query is complex, joining data from multiple indexes. The administrator checks the 'savedsearch.log' and sees entries like 'Search job terminated due to dispatch time limit' and 'Search job exceeded max time'. The administrator wants to resolve the issue without changing the search logic or increasing system resource limits. Which action should the administrator take first?

Accepted Answer

Increase the 'dispatch.max_time' parameter for the saved search in savedsearches.conf.. The error messages 'Search job terminated due to dispatch time limit' and 'Search job exceeded max time' directly indicate that the search is hitting the 'dispatch.max_time' limit, which defaults to 600 seconds (10 minutes) for scheduled searches. Increasing this parameter in savedsearches.conf extends the maximum execution time allowed for the search job, allowing the complex query to complete without changing the search logic or system resource limits.

Answer

Change the scheduled time to 1:00 AM to avoid other concurrent heavy searches.

Answer

Increase the 'dispatch.earliest_time' and 'dispatch.latest_time' settings for the saved search to allow a longer execution window.

Answer

Reduce the search time range from 'last 24 hours' to 'last 1 hour' to speed up the query.

Question 3

Which TWO commands can be used to perform statistical aggregations on streaming events without creating a separate search results set?

Accepted Answer

streamstats. C is correct because streamstats performs statistical aggregations on streaming events in real-time as they arrive, without creating a separate search results set. It computes windowed statistics (e.g., running sum, moving average) on the event stream itself, appending the result to each event. D is correct because eventstats also operates on the current event set, computing aggregations and adding the results as new fields to each event without generating a separate output set.

Answer

timechart

Answer

stats

Answer

chart

Question 4

A user wants to create a timechart showing the number of distinct users per hour over the past week. Which search is correct?

Accepted Answer

index=web | timechart dc(user) span=1h. The `timechart` command automatically creates a time-based chart with a default or specified `span`, and `dc(user)` calculates the distinct count of users per time bucket. The `span=1h` argument sets the bucket size to one hour, and the `by` clause is not needed because `timechart` implicitly groups by `_time`. This produces the desired output of distinct users per hour over the past week.

Answer

index=web | bucket _time span=1h | stats dc(user) by _time

Answer

index=web | timechart dc(user) by _time span=1h

Answer

index=web | timechart count by user span=1h

Question 5

An analyst wants to create a timechart of the count of events per hour, but only for events where the field `status` contains the word "fail" (case-insensitive). Which search is correct?

Accepted Answer

index=main | timechart count by eval(case(match(status,"(?i)fail"),1)). It uses `eval` with `case` and `match` to create a field that is 1 when `status` contains 'fail' (case-insensitive via `(?i)`), then uses `timechart count by` that field to count only matching events per hour. This approach correctly filters within the timechart aggregation, ensuring only events where status matches the pattern are counted.

Answer

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

Answer

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

Answer

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

Question 6

A security analyst wants to find IP addresses that have attempted to access a specific URL more than 5 times in the last hour and also have a user agent string containing "curl". They need to use a subsearch to pre-filter IPs. Which search is correct?

Accepted Answer

index=web sourcetype=access [search useragent=*curl* | stats count by src_ip | where count>5 | fields src_ip] | stats count by src_ip | where count>5. It uses a subsearch to first find IPs that have accessed the URL more than 5 times with a user agent containing 'curl', then passes those IPs to the outer search to filter the original data. The subsearch returns a list of src_ip values, which the outer search uses as a filter, ensuring only IPs meeting both conditions are counted again. This matches the requirement to pre-filter IPs using a subsearch.

Answer

[search index=web sourcetype=access useragent=*curl* | stats count by src_ip | where count>5] | fields src_ip

Answer

index=web sourcetype=access | search useragent=*curl* | stats count by src_ip | where count>5

Answer

index=web sourcetype=access ( useragent=*curl* ) | stats count by src_ip | where count>5

Question 7

Refer to the exhibit. The search returns results quickly but shows zero events for some src values. What does `summariesonly=t` imply?

Accepted Answer

It restricts tstats to only use data from accelerated data model summaries.. `summariesonly=t` in a `tstats` command restricts the search to only use data from accelerated data model summaries, ignoring raw event data. This is why the search returns quickly but shows zero events for some `src` values—those values are not present in the accelerated summaries, so they are excluded from the results.

Answer

It causes tstats to search the index directly.

Answer

It makes the search run faster but less accurate.

Answer

It forces tstats to return all events, including those not in summaries.

Question 8

An automatic lookup is configured in props.conf and transforms.conf, but the expected fields are not appearing in search results. Which is the first thing to verify?

Accepted Answer

Verify the transforms.conf definition for the lookup. The first step to troubleshoot an automatic lookup is to verify the transforms.conf definition, ensuring that the lookup table name, file path, and field mappings are correctly specified. Option B is incorrect because manually running the lookup command is a diagnostic step that comes after verifying the configuration. Option C is incorrect because the source field extraction is not directly related to automatic lookup functionality; the lookup is based on field values, not extraction. Option D is incorrect because read permissions on the lookup table would typically cause an error message, not a silent failure of fields appearing.

Answer

Run a search using the lookup command manually to test

Answer

Verify that the source field is extracted at search time

Answer

Verify that the user has read permissions on the lookup table

Question 9

Which THREE of the following are required steps to properly schedule a saved search for summary indexing that runs a macro?

Accepted Answer

The summary index must be created before the search runs.. Correct answers: A, B, E. A is required because the summary index must exist before the search writes summary data. B is required because the saved search must have a schedule to run automatically. C is incorrect because the summary index is not automatically created; it must be created beforehand. D is incorrect because the macro does not have to be in the same app; it can be shared across apps. E is correct because the macro must be accessible from the context (app permissions) where the saved search runs.

Answer

The summary index is automatically created when the search runs.

Answer

The macro must be defined in the same app as the saved search.

Question 10

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. Sourcetypes may have different timestamp formats or time zones, causing events to be incorrectly sorted out of the transaction window. Option C (maxevents) would truncate but not miss events. Option D (field name) is unlikely. Option A (search time level) is not relevant.

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 11

A security analyst wants to calculate the average latency for each web server over the past hour, but only for requests where the status code is 200. The search result includes fields: server, latency, status. Which search correctly accomplishes this?

Accepted Answer

index=web sourcetype=access status=200 | stats avg(latency) by server. It filters events to only those with status=200 before the stats command, ensuring the average latency is calculated exclusively over successful requests. The stats command then computes the average latency grouped by server, which directly answers the requirement without needing conditional logic or post-filtering.

Answer

index=web sourcetype=access | eval good_latency=if(status=200, latency, null) | stats avg(good_latency) by server

Answer

index=web sourcetype=access | eventstats avg(latency) by server | where status=200

Answer

index=web sourcetype=access | stats avg(latency) by server | where status=200

Question 12

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 `list()` and `bin` time is more memory-efficient than `transaction` for correlating events by session_id. `transaction` creates a transaction object with all event details, consuming more memory, while `stats` aggregates fields without storing raw events. Options A (`concurrency`) is for analyzing concurrent events, not correlation; B (increasing limits) only postpones issues; C (`append`) is for combining results, not efficient correlation.

Answer

Use `concurrency` command to group events

Answer

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

Answer

Use `append` with subsearch to join events

Question 13

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.)

Accepted Answer

Use `transaction user` to group events by user.. Options A and C are correct. The `transaction user` command groups events by user, and `maxspan=10m` limits the grouping window. Option B is incorrect because `mvcount(src_ip)>=3` counts all occurrences of `src_ip`, not distinct IPs, so it does not guarantee that the user authenticated from at least 3 different source IPs. The correct approach would involve using a different method to ensure distinct IPs, such as removing duplicates within the transaction before counting.

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 14

A user wants to calculate the average response time per user, but only for users who have more than 10 events. Which search approach is efficient?

Accepted Answer

index=web | stats avg(response_time) as avg, count as cnt by user | where cnt>10. It first uses `stats` to compute both the average response time and the event count per user, then filters with `where cnt>10` to keep only users who have more than 10 events. This ensures the average is calculated only after grouping, and the count condition is applied on the aggregated result, which is efficient and accurate.

Answer

index=web | eventstats avg(response_time) as avg by user | where count>10

Answer

index=web | where count>10 | stats avg(response_time) by user

Answer

index=web | stats avg(response_time) as avg by user | where count>10

Question 15

A dashboard shows a single-value visualization of total sales. The underlying search uses `| stats sum(sales)`. The dashboard refreshes every 5 minutes, but the value only updates when the page is manually reloaded. Which setting is MOST likely missing?

Accepted Answer

The search is not scheduled or set to 'Auto' for the panel.. The single-value visualization's search must be scheduled or set to 'Auto' to automatically re-execute on dashboard refresh. Without this setting, the search runs once when the dashboard loads and caches the result, so even with a 5-minute auto-refresh interval, the displayed value remains stale until the page is manually reloaded.

Answer

The 'Token delay' is too high.

Answer

The time range picker is set to 'All time'.

Answer

The dashboard's 'Auto-refresh' interval is not set.