SPLK-3002: Splunk IT Service Intelligence Certified Admin — Legacy Service-Health Skills

SPLK-3002 is associated with Splunk IT Service Intelligence Certified Admin. Splunk moved this credential into the Legacy category on January 1, 2026, meaning the exam can still be relevant for existing ITSI environments but the content is no longer actively refreshed to reflect future product releases. Splunk currently lists a 60-minute exam with 53 multiple-choice questions and no formal prerequisite certification.

ITSI turns infrastructure and application telemetry into service-oriented views. Instead of asking only whether a host is up, teams define services, entities, key performance indicators, dependencies, health scores, notable events, and visualizations that reflect how technology supports business outcomes. Administration therefore combines data quality, service modeling, threshold design, event analytics, and operational workflow.

Candidates should keep legacy status in mind while studying. The published exam objectives describe enduring ITSI concepts, while current documentation should guide product-specific implementation. The broader Splunk certifications landscape now emphasizes newer observability paths, but service-health reasoning remains useful across monitoring platforms.

Service models translate technical components into operational meaning

An ITSI service can represent an application, business process, technical tier, or other capability that teams need to monitor. Services can depend on other services, creating a model that shows how degraded components affect higher-level outcomes. The model is only useful when relationships reflect reality rather than organizational charts or arbitrary grouping.

Candidates should think about ownership and boundaries. A checkout service might depend on API, database, identity, and payment components, while each of those depends on shared infrastructure. Overly broad services hide useful detail; overly granular services create maintenance overhead. The goal is a model that supports investigation and decision-making.

Service models should be reviewed with application and business owners, not created solely by monitoring teams. Operators may know which hosts emit metrics, while service owners understand which dependency actually blocks customers. Combining those perspectives helps prevent models that are technically neat but operationally misleading.

Entities provide the concrete systems behind service behavior

Entities represent hosts, devices, applications, cloud resources, or other monitored objects. Discovery and rules can associate entities with services, and aliases help reconcile identifiers from different data sources. Reliable entity resolution matters because a single server may appear under hostname, IP address, instance ID, or cloud resource name.

Duplicate or ambiguous entities fragment health information. Administrators should define stable identifiers and review discovery rules as environments change. This resembles the broader observability problem discussed in observability by design: telemetry is useful only when teams can connect signals to the same underlying component or service.

Entity alias design should avoid unstable attributes such as short-lived IP addresses when more durable identifiers exist. In cloud and virtualized environments, instances can be replaced frequently, so names, tags, or platform identifiers may provide better continuity. The right alias strategy depends on how resources are created and monitored.

KPIs turn searches into service-level signals

Key performance indicators are searches that produce measurements such as latency, error rate, throughput, queue depth, or availability. Administrators define how often a KPI runs, what entity or service it represents, and how values map to severity. A KPI should measure something operationally meaningful rather than any metric that happens to be available.

Search design affects KPI reliability. Expensive searches may miss schedules, while weak field constraints can mix unrelated data. Candidates should understand threshold approaches, time policies, aggregate behavior, and the impact of missing data. A health score is only as trustworthy as the KPIs beneath it.

KPI searches should have test cases that show expected normal, warning, and critical values. This protects against unnoticed changes when a source field, unit, or aggregation changes. A latency field switching from seconds to milliseconds can make a perfectly valid threshold meaningless if the data contract is not monitored.

Thresholds need history and operational context

Static thresholds are simple but can create false positives when normal behavior varies by hour, weekday, or workload. Adaptive or policy-based approaches can use historical behavior, but they still require governance. Teams should know when a threshold was changed, what evidence justified it, and how the new value affects alert volume.

A useful threshold connects to action. If nobody responds differently when latency moves from 200 to 220 milliseconds, that boundary may not deserve a severity change. ITSI administration should reduce ambiguity for operators rather than turn every statistical deviation into an incident.

Threshold review should consider seasonal behavior and business events. Month-end processing, product launches, and planned batch windows may legitimately change normal ranges. Administrators can use policies and time rules to reflect predictable behavior rather than widening thresholds permanently and reducing sensitivity at ordinary times.

Event Analytics consolidates signals into manageable episodes

Monitoring systems can produce many related events during one outage. ITSI event analytics can aggregate, deduplicate, and organize events so operators see a smaller number of actionable episodes. Rules need to preserve important distinctions while reducing obvious repetition. Over-aggressive grouping can hide separate failures that happen to share a field.

This is conceptually similar to reducing noisy SIEM alerts: fewer events are valuable only when the remaining representation preserves the evidence needed to act. Administrators should test aggregation rules against both normal storms and simultaneous independent incidents.

Episode rules should be evaluated for both under-grouping and over-grouping. If one outage creates hundreds of episodes, the rule is not reducing noise. If unrelated failures collapse into one episode, responders lose isolation. Testing with synthetic event storms can reveal both extremes before real incidents occur.

Glass tables and deep dives should support investigation

ITSI visualizations can show service topology, health, KPIs, and trends. A glass table should help users understand relationships and identify where degradation begins, while a deep dive supports detailed time-based analysis across related signals. Visual design should follow the investigation workflow rather than display every available metric.

The same warning applies as with any operations dashboard: a polished dashboard can still be a poor data product. Labels, time ranges, thresholds, and drilldowns should make the meaning of each view clear. Operators need to know what changed and where to look next, not admire the layout.

Visualization ownership matters because service models and thresholds evolve. A glass table that is never reviewed can preserve obsolete dependencies or labels long after the monitored application changes. Teams should include important operational views in the same change process as the services and KPIs they represent.

Maintenance windows and dependencies prevent avoidable noise

Planned maintenance can create predictable KPI changes and events. Maintenance windows allow teams to suppress or manage those expected conditions rather than treating every planned restart as a production incident. The window should match the real scope and duration of work so monitoring resumes promptly when maintenance ends.

Dependencies also matter during changes. If one shared database supports several services, its maintenance can affect multiple health scores. Service models should make that relationship visible before a change occurs. Operational teams can then distinguish expected impact from unrelated degradation that deserves investigation.

Maintenance windows should be auditable. Operators need to know who created the window, which services or entities it covers, and when monitoring resumes. Long or recurring windows can accidentally conceal genuine degradation, so they should be scoped to the planned change rather than used as a general noise-control technique.

Preparation should build a service from data to health score

A strong lab starts with raw data and ends with a service view. Create entities, define a service, add KPIs, configure thresholds, generate test degradation, observe health-score changes, group related events, and build a visualization that helps explain the issue. Then change entity identifiers or remove data to see how brittle assumptions surface.

SPLK-3002 validates established ITSI administration concepts, but its Legacy label should shape expectations. The exam is not a promise that every objective tracks the newest product release. Candidates should use it for environments that still value the credential while continuing to learn current observability practices and metrics-oriented skills such as those covered by Splunk O11y Cloud Metrics.

Candidates can deepen practice by starting with one user symptom—such as checkout latency—and tracing which ITSI service, KPI, entity, and raw search would explain it. That investigation-first approach prevents service-health configuration from becoming abstract and shows how each administrative object helps reduce time to diagnosis.

Service-health programs also need a retirement process. Applications are decommissioned, ownership changes, and old entities can remain discoverable long after they stop supporting real services. Stale services and KPIs dilute operational attention and can distort dashboards. Periodic review should remove obsolete objects, transfer ownership, and confirm that every monitored service still maps to a current business or technical capability.

KPI ownership should be visible as well. When a threshold repeatedly produces confusing results, operators need to know which team can explain the underlying metric and approve changes. Shared ownership between platform administrators and service teams prevents monitoring logic from becoming orphaned configuration that nobody wants to adjust even after the application changes.

Teams should also document which dashboards and alerts consume each KPI so a change can be evaluated for downstream impact before it is promoted.