How many Troubleshooting Scenario Questions questions are on this page?

This page has 12 Troubleshooting Scenario Questions scenario questions for the SPLK-1004 exam, each with detailed explanations and wrong-answer analysis.

How should I approach SPLK-1004 scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Splunk Core Certified Advanced Power User (SPLK-1004) (SPLK-1004) questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise Splunk Core Certified Advanced Power User (SPLK-1004) (SPLK-1004) practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

SPLK-1004

exam code

Splunk

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Practice scenarios

Question 1hardmultiple choice

Full question →

A Splunk power user is troubleshooting a search that uses a calculated field named 'response_time' defined as 'duration_ms / 1000'. The field 'duration_ms' is extracted from raw events, but the calculated field returns null values for some events. Upon investigation, the user finds that 'duration_ms' is sometimes missing or contains non-numeric characters. Which of the following is the most likely reason for the null values in 'response_time'?

A
The field 'duration_ms' is not indexed, so it is not available for calculated fields.
Why it fails: Calculated fields operate on search-time extracted fields, which do not need to be indexed. Indexed fields are a separate concept; search-time fields are extracted from raw data during search. The availability of 'duration_ms' for calculation depends on successful extraction, not indexing. Thus, this is not the reason for null values.
B
The eval expression fails to handle non-numeric or missing values, resulting in null for those events.
In Splunk, arithmetic operations on non-numeric or null values yield null. Since 'duration_ms' sometimes contains non-numeric characters or is missing, the division operation cannot produce a numeric result, leading to null for 'response_time'. To avoid this, the expression should include conditional logic, such as using the tonumber() function or a coalesce() to provide a default value.
C
The calculated field expression is evaluated before field extraction, so 'duration_ms' is not yet available.
Why it fails: Calculated fields are evaluated after field extraction during the search-time field resolution phase. The order of operations ensures that extracted fields are available before calculated fields are computed. Therefore, the timing of evaluation is not the cause of null values; the issue lies with the data itself or the expression's handling of non-numeric values.
D
The calculated field is defined with the wrong data type, causing Splunk to discard invalid results.
Why it fails: Calculated fields in Splunk do not have explicit data types; they are dynamically evaluated. Splunk does not discard results based on data type mismatches; instead, it returns null when operations cannot be performed. The problem is not a misconfigured data type but the presence of non-numeric data in the source field.

Full breakdown with real-world context →

Question 2mediummultiple choice

Full question →

A dashboard panel's search reads 12 GB from disk but returns only 4,000 events. In Search Inspector, which metric should you investigate first to reduce unnecessary disk reads?

A
The 'Result Count' metric showing the number of returned events
Why it fails: Result count only tells you how many events were returned, which is already given as 4,000. It does not reveal how much data was read to produce those results. The problem is the mismatch between data read and results returned, so the metric that measures disk reads is the correct starting point.
B
The 'Disk Usage' metric showing bytes read from disk
Search Inspector reports the amount of data read from disk for the search. When a search reads 12 GB but returns only 4,000 events, excessive disk usage is the direct symptom. Reviewing this metric first confirms that the search is scanning more raw data than needed, which then guides adding filters, reducing time range, or moving the base search to a summary index.
C
The 'Execution Cost' metric indicating CPU time spent
Why it fails: Execution cost measures processing effort, but the scenario specifically contrasts disk reads with returned results. High CPU cost could come from many transformations even after disk reads are reduced. The more targeted first metric is the one that quantifies bytes read from disk, because that directly explains why 12 GB was touched for only 4,000 events.
D
The search's 'bucket' count in the Search Inspector's 'Performance' section
Why it fails: Bucket count reflects how many index buckets the search touched, but a high bucket count alone does not prove unnecessary disk reads. It is a contributing signal, not the direct measure of bytes read. The scenario points to a large gap between data scanned and results returned, so the metric that directly quantifies bytes read is the better first focus.

Full breakdown with real-world context →

Question 3hardmultiple choice

Full question →

A Splunk administrator is troubleshooting a data model that has been accelerated for several months. Users report that recent data is missing from Pivot reports, but older data is present. The acceleration summary files exist and are not corrupt. What should the administrator check first?

A
The data model's acceleration time range setting, to ensure it covers the current time period.
The acceleration time range setting defines how far back the summary covers. If it is set to a fixed historical window (e.g., last 30 days) and not updated, recent data beyond that window will not be included. Checking this setting is the first step to resolve missing recent data.
B
The indexer's disk space, because if the disk is full, new events are not indexed and thus not accelerated.
Why it fails: If the disk were full, new events would not be indexed at all, affecting raw searches as well. The scenario specifies that only the accelerated data model is missing recent data, implying that raw events are present. Therefore, disk space is not the primary suspect.
C
The data model's acceleration schedule, to ensure it runs frequently enough to capture new data.
Why it fails: The acceleration schedule determines how often the summary is updated. If it runs infrequently, there might be a delay, but it would eventually catch up. The scenario describes a persistent lack of recent data, which points to a time range limit rather than a schedule issue.
D
The search head's clock synchronization, as time skew can cause recent events to be indexed with future timestamps.
Why it fails: While clock skew can cause indexing issues, it would affect all data, not just recent data in an accelerated data model. Moreover, the scenario states that older data is present, which suggests the acceleration is working for older periods. Clock skew is less likely than an acceleration time range misconfiguration.

Full breakdown with real-world context →

Question 4hardmultiple choice

Full question →

A Splunk administrator is troubleshooting why a data model acceleration summary for the 'Network_Traffic' data model is not returning results for a specific time range, even though the data model is accelerated and the search head is healthy. The administrator checks the acceleration settings and sees that the acceleration is enabled with a summary range of 7 days. The search is for the last 30 days. What is the most likely cause of the missing results?

A
The acceleration summary files are corrupted and need to be rebuilt.
Why it fails: Corrupted summary files would typically affect all searches using the accelerated data model, not just those beyond a certain time range. The administrator would see errors or inconsistent results across time ranges. The fact that results are missing only for data older than 7 days points to the summary range limit, not corruption.
B
The 'Network_Traffic' data model does not support acceleration for time ranges longer than 7 days due to licensing restrictions.
Why it fails: There are no licensing restrictions that limit data model acceleration to 7 days. The summary range is configurable and can be set to any value, subject to available storage and performance considerations. The limitation here is the configured summary range, not a license restriction.
C
The data model acceleration is not working because the search head is not connected to the indexers.
Why it fails: If the search head were not connected to the indexers, the administrator would likely see broader failures, not just missing data for a specific time range. The scenario states the search head is healthy, so connectivity is not the issue. The problem is specifically about the time range exceeding the acceleration summary range.
D
The acceleration summary only covers the last 7 days, so data older than that is not summarized and must be searched from raw data.
Data model acceleration creates summary files for a specified summary range. If the summary range is 7 days, only the last 7 days of data are accelerated. Searches that span beyond that range will not find accelerated data for the older period, and Splunk will fall back to raw data if the search mode allows, or return incomplete results if the search is restricted to accelerated data. This is the most likely cause.

Full breakdown with real-world context →

Question 5hardmulti select

Full question →

Which THREE of the following are valid ways to troubleshoot a slow dashboard?

A
Inspect the dashboard XML for inefficient post-processing.
Inspecting dashboard XML exposes inefficient post-processing searches, which run after the base search and cannot leverage index-time optimisation. This directly addresses the slow dashboard constraint by revealing whether post-process calculations, such as expensive eval or stats chains, are throttling rendering. Editing or removing those blocks restores performance without altering underlying data.
B
Review the Monitoring Console for search activity.
The Monitoring Console aggregates search activity across the deployment, exposing slow-running searches, high dispatch times and resource-heavy dashboards. Reviewing it pinpoints which searches or panels drive the dashboard's slowness, directly addressing the troubleshooting need in the stem.
C
Re-index all the data.
Why it fails: Re-indexing rewrites existing data without changing dashboard queries, panel counts or search efficiency, so it cannot resolve slowness and risks disruption. It is tempting as a perceived data-freshness fix. Re-indexing would be correct after index corruption or a sourcetype parsing change, not for performance tuning.
D
Restart the Splunk search head.
Why it fails: Restarting the search head clears caches and transient state but does not address the query design, data volume or concurrency causing slowness. It is tempting as a quick generic fix. Restarting would be correct when the search head itself is unresponsive or stuck, not merely slow.
E
Use the Search Inspector to analyze execution metrics.
The Search Inspector breaks a search into its components and reports execution cost, timing and resource usage per operator, exposing which stage causes the dashboard delay. This directly identifies the slow search artefact rather than guessing at panel or token issues.

Full breakdown with real-world context →

Question 6hardmultiple choice

Full question →

You are troubleshooting a dashboard that uses a base search and several post-process searches. The base search is `index=app | stats count by user, action`. One post-process search is `| search action=login | top user`. Users report that the top user panel sometimes shows incorrect counts compared to a direct search `index=app action=login | top user`. What is the most likely cause of the discrepancy?

A
The post-process search is missing a time range, so it uses a different time range than the base search.
Why it fails: In Splunk, post-process searches inherit the time range from the base search. They do not have their own time range unless explicitly overridden. Therefore, a missing time range is not the cause. The discrepancy arises from the aggregation in the base search, not from time range differences.
B
The base search is not using `| fields` to limit the fields passed to post-process searches.
Why it fails: Not using `| fields` can affect performance and may cause post-process searches to have access to more fields than needed, but it does not cause incorrect counts. The base search already aggregates by user and action, so the post-process search only sees those fields. The discrepancy is not due to field filtering but rather to how the base search aggregates data.
C
The base search uses `stats count by user, action`, which aggregates events, so the post-process search counts aggregated rows rather than raw events.
The base search aggregates events into counts per user and action. When the post-process search runs `| search action=login | top user`, it operates on the aggregated rows, not raw events. The `top` command then counts the number of aggregated rows per user, which may not equal the sum of counts. For example, if a user has multiple actions, the counts are separate rows. This leads to incorrect top user counts compared to a direct search on raw events.
D
The base search is not accelerated, so it returns incomplete results.
Why it fails: Acceleration is a feature for data models and does not apply to ad-hoc base searches. A non-accelerated base search still returns complete results for the time range. The issue is not about acceleration but about the level of aggregation. The base search returns aggregated counts, which changes the semantics for post-process searches.

Full breakdown with real-world context →

Question 7hardmulti select

Full question →

A Splunk power user is troubleshooting a data model acceleration that has stopped generating new summary data. The user checks the Data Model Acceleration settings and the model is enabled and set to accelerate. Which two actions should the user take to resolve the issue? (Choose two.)

A
Check the _internal index for messages from the DataModelAcceleration and search scheduler to identify errors or skipped runs.
The _internal index contains logs from the data model acceleration process, including errors, warnings, and scheduler messages. Searching _internal for DataModelAcceleration or the model name reveals why acceleration failed, such as missing permissions, full disk, or search head issues.
B
Restart the search head to clear any stuck acceleration jobs.
Why it fails: Restarting the search head is a heavy-handed action that may temporarily clear a stuck job but does not fix the underlying cause. It also disrupts other users and searches. Without checking logs and permissions first, the issue is likely to recur after restart.
C
Verify that the search head's role has the accelerate_datamodel capability and that the user has permission to manage acceleration.
Data model acceleration requires the accelerate_datamodel capability on the search head. If the role lacks this capability, the acceleration cannot run even if the model is enabled. Verifying role permissions ensures the scheduler can execute the acceleration searches and write summary files.
D
Increase the Max Time setting to 1 year to force a full rebuild of the summary.
Why it fails: Changing Max Time affects how far back the acceleration summarizes, not why it stopped. A full rebuild might occur, but if the underlying problem is permissions or disk space, it will fail again. This action does not diagnose the cause and can increase resource usage unnecessarily.
E
Delete the data model and recreate it from scratch to reset the acceleration state.
Why it fails: Deleting and recreating the data model is a destructive step that loses custom configurations and does not address the root cause. The issue could be permissions, disk space, or scheduler conflicts. Recreating the model without diagnosing the cause will likely result in the same failure and unnecessary downtime.

Full breakdown with real-world context →

Question 8hardmultiple choice

Full question →

A dashboard user reports that a drilldown is not passing the expected token to a target dashboard. The source panel uses a chart where the click event is defined. Which configuration detail should you verify first?

A
Check if the target dashboard has a Time Range Picker.
Why it fails: A time range picker on the target dashboard affects its search window, not whether a token arrives. It is tempting because time tokens are commonly passed in drilldowns, but the first check is that the drilldown's token name matches the target's token filter.
B
Verify the 'click.value' property is correctly set to the field name.
In Simple XML drilldowns, click.value carries the clicked field's value into the token; if it references the wrong field name, the target dashboard receives an empty or incorrect token. Verifying this property first isolates the most common token-passing misconfiguration.
C
Rebuild the summary index.
Why it fails: Summary indexes accelerate report searches; they do not carry drilldown tokens between dashboards. Rebuilding is tempting when a search returns stale results, but the fault lies in the drilldown's token name or the target's token filter, not the index.
D
Ensure the user has write permissions to the target dashboard.
Why it fails: Write permission governs editing the dashboard, not receiving a token. It is tempting because permission errors block dashboard access, but drilldown token passing depends on the source drilldown's token name matching the target panel's token filter, which is the first thing to verify.

Full breakdown with real-world context →

Question 9hardmulti select

Full question →

A Splunk administrator is troubleshooting a data model acceleration issue. The administrator notices that the acceleration summary for the 'Network_Traffic' data model is not up to date, and searches using tstats return stale results. Which two actions should the administrator take to resolve this issue? (Choose two.)

A
Restart the Splunk indexer to force a full re-acceleration of all data models.
Why it fails: Restarting the indexer is a disruptive action and does not guarantee a full re-acceleration. Acceleration is managed by the search head and runs as scheduled searches. Restarting the indexer might interrupt searches but will not fix misconfigurations or errors. It is not a targeted solution for stale acceleration summaries and could cause additional issues.
B
Verify that the data model is enabled for acceleration and that the acceleration schedule is properly configured.
If the data model is not enabled for acceleration or the schedule is misconfigured (e.g., set to run at infrequent intervals or disabled), the summary files will not be updated. Checking these settings is a fundamental troubleshooting step. Ensuring that acceleration is enabled and the schedule matches the desired freshness is essential for timely updates.
C
Disable and re-enable acceleration for the data model to trigger a rebuild.
Why it fails: Disabling and re-enabling acceleration will indeed trigger a rebuild, but it is a heavy-handed approach that can take a long time and consume significant resources. It does not address the underlying cause, such as a misconfiguration or error. It is better to first check the configuration and logs to identify and fix the root cause, rather than forcing a rebuild blindly.
D
Check the size of the acceleration summary and increase the disk space if necessary.
Why it fails: While disk space can affect acceleration if the summary index is full, it is less likely to be the primary cause of stale results. The summary index typically has a retention policy, and if it runs out of space, it may drop old data, but that would not cause the summary to be stale; it would cause missing data. Stale results usually indicate that acceleration is not running or is failing, not a disk space issue.
E
Review the acceleration logs for errors, such as search failures or permission issues.
Acceleration runs as a scheduled search, and if it fails due to errors (e.g., search timeouts, permission problems, or missing fields), the summary will not be updated. Checking the logs, such as the _internal index for messages related to the data model acceleration, can reveal the root cause. This is a critical step in diagnosing why acceleration is not completing successfully.

Full breakdown with real-world context →

Question 10hardmultiple choice

Full question →

A Splunk administrator is troubleshooting a calculated field that is not appearing in search results. The calculated field is defined in `props.conf` as `EVAL-total = price * quantity`. The administrator confirms that the `price` and `quantity` fields are present in the events and that the `props.conf` file is correctly placed in the app's `local` directory. However, when searching for `total`, no results are returned. Which of the following is the most likely cause?

A
The calculated field is not referenced in the search, so it is not evaluated; the administrator must explicitly include it in the search terms.
Why it fails: Calculated fields are evaluated at search time only when they are referenced. If the administrator searches for `total`, that is a reference, so it should be evaluated. However, if the search does not explicitly reference `total` (e.g., just `index=main`), then it won't appear. The scenario says the administrator searches for `total`, so this is not the cause. The issue is that even when referenced, it's not appearing.
B
The `price` or `quantity` field is extracted as a string, causing the multiplication to fail or return null.
If `price` or `quantity` are extracted as strings, Splunk may not automatically convert them to numbers for arithmetic. The multiplication could result in null or an error. Splunk typically auto-converts numeric strings, but if the fields contain non-numeric characters (e.g., "$10"), the conversion fails. This is a common cause for calculated fields not producing expected results. The administrator should check field types or use functions like `tonumber()`.
C
The calculated field is defined in the wrong app context; it must be in the `system` app to be globally available.
Why it fails: Calculated fields defined in an app's `local` directory are available to users of that app. If the search is performed within the same app, the field should be available. Placing it in the `system` app would make it global, but that is not required for it to work in the app. This is not the most likely cause unless the user is searching in a different app.
D
The `EVAL-` expression must be enclosed in double quotes to be valid.
Why it fails: In `props.conf`, `EVAL-` expressions are not enclosed in quotes unless the expression itself contains special characters that require quoting. For a simple arithmetic expression like `price * quantity`, quotes are not necessary. Adding quotes would actually become part of the expression and cause errors. So this is incorrect.

Full breakdown with real-world context →

Question 11mediummultiple choice

Full question →

A user complains that a calculated field is not showing up. Which of the following is the best first step to troubleshoot?

A
Restart the Splunk service.
Why it fails: Restarting the Splunk service interrupts all searches and indexing without addressing why one calculated field fails to evaluate, which is normally a field definition, permissions or syntax issue. Restarting is tempting as a blanket fix, and it would be correct for a hung process or unresponsive instance.
B
Check if the field is in the 'Selected Fields' or 'Interesting Fields' list.
Calculated fields only appear in the field sidebar once Splunk has indexed or extracted a value for them; checking the Selected Fields and Interesting Fields lists confirms whether the field exists in the current result set. This directly addresses the stem's constraint: verifying field visibility before investigating the calculation's syntax or permissions.
C
Change the indexer's cluster master.
Why it fails: The cluster master coordinates indexer replication and search peers; it has no bearing on whether a calculated field evaluates in a search. Changing it is tempting when users assume cluster-wide configuration governs field visibility, but it would be the right action only for replication or peer-node failures.
D
Delete the index and re-ingest the data.
Why it fails: Deleting the index destroys ingested data and cannot restore a calculated field, which is defined in configuration rather than stored in the index. Re-ingestion is tempting when users suspect corrupt data, and it would be correct only when indexed events themselves are malformed or missing.

Full breakdown with real-world context →

Question 12hardmulti select

Full question →

A dashboard uses a base search with post-process searches. Users report that some panels show incorrect results after the base search completes. You need to troubleshoot the issue. Which two actions should you take to identify the cause? (Choose two.)

A
Ensure that the base search is a transforming search and does not return raw events.
Why it fails: While transforming searches can be used, it is not required. Base searches can return raw events as long as post-process searches can handle them. Making it transforming might actually remove fields needed by post-process searches. This is not a standard troubleshooting step for incorrect results.
B
Increase the max result count for the base search to prevent truncation.
Why it fails: While truncation can cause missing data, it typically affects all panels equally if they share the base search. It is not a likely cause of some panels showing incorrect results while others are fine. Adjusting max result count is not a targeted troubleshooting step for this symptom.
C
Confirm that the base search time range is set to 'All time' to ensure all events are included.
Why it fails: Setting the time range to 'All time' is not a troubleshooting step for incorrect results; it could actually cause performance issues or include unwanted data. The time range should be appropriate for the dashboard's purpose. This does not address why some panels show incorrect results.
D
Verify that the base search includes all fields required by the post-process searches.
If the base search does not include a field that a post-process search needs, that post-process search will fail or produce incomplete results. Checking that all necessary fields are present in the base search output is a critical troubleshooting step. This ensures that post-process searches have the data they expect.
E
Check that post-process searches do not use commands that require raw events if the base search has removed _raw.
If the base search removes _raw (e.g., with `fields - _raw`), any post-process search that relies on _raw (such as `rex` without a field, or `spath`) will fail or return incorrect results. Verifying that post-process searches are compatible with the available fields is essential to troubleshooting.

Full breakdown with real-world context →

These SPLK-1004 practice questions are part of Courseiva's free Splunk certification practice question bank. Courseiva provides original exam-style SPLK-1004 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Troubleshooting Scenario Questions

How to approach troubleshooting scenario questions

Quick answer

Related SPLK-1004 topic practice pages

Lookups And Alerts practice questions

Data Models And CIM practice questions

Field Management And Calculated Fields practice questions

Transforming Commands And Formatting practice questions

Macros And Workflow Actions practice questions

Search Tuning Performance And Dashboards practice questions

SPLK-1004 fundamentals practice questions

SPLK-1004 scenario practice questions

SPLK-1004 troubleshooting practice questions

Practice scenarios

A dashboard panel's search reads 12 GB from disk but returns only 4,000 events. In Search Inspector, which metric should you investigate first to reduce unnecessary disk reads?

A Splunk administrator is troubleshooting a data model that has been accelerated for several months. Users report that recent data is missing from Pivot reports, but older data is present. The acceleration summary files exist and are not corrupt. What should the administrator check first?

Which THREE of the following are valid ways to troubleshoot a slow dashboard?

A Splunk power user is troubleshooting a data model acceleration that has stopped generating new summary data. The user checks the Data Model Acceleration settings and the model is enabled and set to accelerate. Which two actions should the user take to resolve the issue? (Choose two.)

A dashboard user reports that a drilldown is not passing the expected token to a target dashboard. The source panel uses a chart where the click event is defined. Which configuration detail should you verify first?

A user complains that a calculated field is not showing up. Which of the following is the best first step to troubleshoot?

A dashboard uses a base search with post-process searches. Users report that some panels show incorrect results after the base search completes. You need to troubleshoot the issue. Which two actions should you take to identify the cause? (Choose two.)