ITSI is service-centric. Every function—KPI, threshold, event, Glass Table, Deep Dive—connects back to a service.
Method:
Create a concept map with “Service” at the center, and branches for:
KPIs → base search → thresholds
Notable Events → aggregation/correlation → incident response
Glass Tables → visual representation
Practice tracing:
“If a KPI turns red, what caused it, and how does it appear in the system?”
This builds structural understanding, not isolated memorization.
Since most SPLK-3002 questions are applied or scenario-based, you must practice real-world logic.
Method:
For each knowledge area, ask:
“If I were a Splunk admin and saw this in production, how would I respond?”
Write out short case scenarios, such as:
A service is healthy but child services are failing → investigate dependency logic
A KPI isn’t triggering any event → check thresholds, search schedule, base search output
Break complex systems into:
Definition
Location (where it’s configured)
Dependencies (what it needs)
Impact (what it influences)
Example: Aggregation Policy
Defined: Groups similar Notable Events
Configured: Event Management → Aggregation Policies
Depends on: Filtering rules, time window, grouping fields
Influences: Alert volume, operator workload
Repeat this for: KPI, Threshold, Time Policy, Deep Dive, Template, Correlation Search, Access Control.
Don’t just review notes—test yourself frequently and space out reviews over time.
Tools to use:
Flashcards (physical or apps like Anki)
One-pager summaries
End-of-week quizzes
Review at 1-day, 3-day, and 7-day intervals
Focus especially on:
KPI lifecycle
Threshold vs anomaly detection
Aggregation vs correlation
Troubleshooting patterns
Many exam questions involve system design or flow-based logic.
Method:
Draw service trees (parent-child with weights)
Map Glass Tables to KPIs
Visualize time policy blocks on a calendar
This aids retention and speeds up comprehension during the test.
Many questions have multiple plausible answers—especially multi-choice ones.
Tactic:
Instead of jumping to the correct one, start by eliminating obviously incorrect options.
Ask: “Does this option directly relate to the symptom or config being described?”
Based on exam patterns and official blueprints, focus on:
| Topic | Likely Question Types |
|---|---|
| KPI, Base Search, Threshold | Scenario config, logic order |
| Aggregation Policy | Rule setup, output effect |
| Correlation Search | Time logic, filtering |
| Service Template | Inheritance, reuse logic |
| Notable Events | Lifecycle, action mapping |
| Access Control | Role-based access cases |
| Troubleshooting | Logs, skipped searches |
Some tricky questions test:
What Splunk does by default
What needs manual configuration
Examples:
Are entities created automatically? (Yes, under certain KPI split-by conditions)
Are thresholds inherited from templates? (Yes, unless manually overridden)
Know which components inherit, which need manual setup, and which can be overridden.
Questions involving Time Policies and Correlation Searches often involve:
Time windows
Overlapping event conditions
Cron scheduling
Tactic:
Draw timelines or label values (e.g., “this occurs at 09:00, the next KPI fires at 09:10…”)
Match conditions using time-aware logic
When a question asks: "Select 2 or 3 correct answers", use:
Group validation: Do these answers work together logically?
Purpose check: Do these answers align with the intended function (e.g., reducing alert noise, improving service scoring)?
Avoid selecting 2 answers that belong to different layers (e.g., one deals with data, another with access).
If a question takes too long:
Flag it
Move on
Return with a fresh mind
Don’t spend more than 90 seconds on any single item initially. Preserve time for reviewing confident answers.
Some questions will present partial log entries or diagnostic conditions.
Tips:
Look for keywords: “skipped search”, “no results”, “permissions”
Match them to tools:
_internal logs → search scheduler
itsi_data_integrity → data health
KPI logs → SPL errors or timeout
Remember: You’re not debugging the system—you're reasoning about what’s wrong based on evidence.