hardMultiple ChoiceObjective-mapped
Acceleration Summary Rebuild & Optimization
You are a Splunk administrator for a large e-commerce company. The company ingests approximately 500 GB of web server logs per day into a single index named 'web_logs'. A data model named 'Web_Transactions' has been created to analyze user browsing behavior. The data model has a root event with no constraints, and three child objects: 'Page_Views', 'Searches', and 'Purchases'. Each child object has a constraint based on a key-value pair in the logs: e.g., 'action=view', 'action=search', 'action=purchase'. The data model is accelerated with a 7-day summary, but reports that query specific child objects are taking over 10 minutes to return. The reports use |tstats and filter on common fields like 'user_id' and 'session_id'. The admin suspects the acceleration summary is too large. Which of the following actions will most effectively reduce report latency while maintaining the ability to analyze all three transaction types?
Quick Answer
The correct choice is to add a constraint to the root event that filters for only the action field values view, search, and purchase. This works because the acceleration summary rebuild optimization directly reduces the volume of data indexed into the summary; without a root constraint, the acceleration summary ingests all 500 GB of daily logs, but by limiting the root event to only the three relevant action types, the summary stores a fraction of the data, dramatically speeding up |tstats queries on child objects. On the Splunk SPLK-1002 exam, this tests your understanding of data model acceleration and how root event constraints control summary size—a common trap is assuming child object constraints alone are sufficient, but they only filter after the root has already been expanded. Remember: a root without constraints is like a firehose; a constrained root is a focused stream. Memory tip: “Root first, then branch—constrain the root to shrink the branch.”
⚠ Common exam trap
Candidates often think increasing the acceleration time range will help by caching more data, but it actually exacerbates the problem by making the summary larger and slower to query.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a constraint to the root event to include only events that match the action field values (view, search, purchase).
Adding a constraint to the root event to filter only events with action=view, action=search, or action=purchase reduces the size of the acceleration summary. The root event currently has no constraints, so the acceleration summary includes all 500 GB of daily web logs, even though only three action types are needed. By constraining the root event, the summary stores only relevant data, making |tstats queries on child objects much faster.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the |datamodel command with the 'search' parameter instead of |tstats.
Why it's wrong here
|datamodel does not leverage acceleration as efficiently.
- ✗
Remove the child objects and use only the root event for all reports.
Why it's wrong here
This loses the categorization and may still include irrelevant events.
- ✗
Increase the acceleration summary time range to 30 days to capture more data in one summary.
Why it's wrong here
This will increase size, not reduce latency.
- ✓
Add a constraint to the root event to include only events that match the action field values (view, search, purchase).
Why this is correct
Reduces the summary size by excluding non-relevant events.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SPLK-1001 question from scratch — 502 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
4 more ways this is tested on SPLK-1001
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Refer to the exhibit. An admin sees that the Web_Traffic data model is accelerated but shows 'Summaries require rebuild'. What does this status indicate?
hard- A.The disk space for acceleration is full.
- B.The summary range is too short and needs to be extended.
- C.The acceleration summaries are up to date and optimal.
- ✓ D.The data model definition has been modified and acceleration needs to be rebuilt.
Why D: When a data model is accelerated and shows 'Summaries require rebuild', it indicates that the data model definition has been modified (e.g., fields, constraints, or root events changed) since the last summary build. Splunk detects this change and marks the acceleration summaries as stale, requiring a rebuild to ensure query results reflect the updated definition. This is a built-in mechanism to maintain data integrity between the model and its accelerated summaries.
Variation 2. A new Splunk admin wants to reduce the time it takes to run reports on a large dataset. They have enabled acceleration on a data model. Which of the following is a best practice to maximize acceleration benefits?
easy- A.Add more indexers to the cluster to increase the speed of data model acceleration.
- B.Limit the data model to only the most recent 7 days of data to reduce summary size.
- C.Create a separate acceleration summary for each search using the |accelerate command.
- ✓ D.Enable acceleration on the data model and schedule a periodic summary rebuild.
Why D: Enabling acceleration on a data model and scheduling a periodic summary rebuild ensures that the acceleration summaries are kept up-to-date without manual intervention. This maximizes the benefit of acceleration by pre-computing aggregations for the data model's root search, allowing reports to run against the smaller, optimized summary rather than the raw dataset, which significantly reduces query time.
Variation 3. You are a Splunk administrator for a large e-commerce company. The security team frequently runs searches against the web access logs (sourcetype=access_combined) to investigate suspicious activity. These searches often take 5-10 minutes to complete, and the team is frustrated. You decide to implement a data model to accelerate these searches. After creating a data model based on the CIM Web model and enabling acceleration for the 'Web' dataset, you notice that the acceleration summary size grows to over 50 GB and the rebuild process takes more than an hour every night, causing some searches to time out during the rebuild window. What is the most effective way to address this issue?
easy- A.Increase the bucket size in the acceleration settings to reduce the number of buckets being rebuilt.
- B.Create a custom data model that includes only the fields needed for security investigations and enable acceleration.
- ✓ C.Reduce the acceleration time range from 'All time' to 'Last 7 days' to limit the summary size and rebuild duration.
- D.Disable acceleration and instead rely on the security team to use more focused time ranges.
Why C: Reducing the acceleration time range from 'All time' to a shorter window like 'Last 7 days' directly limits the amount of data the acceleration summary must cover. This shrinks the summary size (under 50 GB) and shortens the nightly rebuild time, preventing search timeouts during the rebuild window while still accelerating the most relevant recent data for security investigations.
Variation 4. You are a Splunk administrator at a financial services company. The company has a distributed Splunk environment with 10 indexers and 2 search heads. You have created a data model named 'transaction_analytics' to analyze financial transactions. The data model is accelerated with a summary range of 7 days. Recently, users have reported that dashboards using this data model are extremely slow, sometimes timing out. You check the acceleration status and see that the summary is 'Building' but never completes. The splunkd.log on the search head shows repeated messages: 'Data model acceleration: query timed out after 300 seconds.' The base search for the data model is: index=transactions sourcetype=fin_events | eval risk_score=if(amount>10000, 'high', 'low') | fields transaction_id, user, amount, risk_score, _time. The data model has one root event with two child datasets: one for high-risk transactions and one for low-risk transactions. The total data volume is about 500 GB per day. The indexer where the summary is built has 16 GB of RAM and the search head has 32 GB. What is the best course of action to resolve the acceleration build timeout?
hard- ✓ A.Modify the base search to remove the eval statement and instead use a lookup or index-time field for risk_score.
- B.Reduce the summary range to 1 day to limit the amount of data processed.
- C.Disable acceleration and rely on real-time searches for the dashboards.
- D.Increase the acceleration.max_time to 600 seconds to allow more time for the build.
Why A: The eval statement in the base search forces the acceleration to process every raw event during the summary build, which is computationally expensive and causes the 300-second timeout. By moving the risk_score calculation to index time (e.g., using a calculated field or lookup), the acceleration can use the pre-computed field directly from the indexed data, drastically reducing CPU load and allowing the summary to complete within the timeout window.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SPLK-1001 practice question is part of Courseiva's free Splunk certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SPLK-1001 exam.