Splunk O11y Metrics User Sample Questions & Practice Test

Splunk O11y Cloud Certified Metrics User is an observability route for candidates who interpret metrics, dimensions, charts, dashboards, detectors, alerts, latency, and service-health signals in Splunk Observability Cloud.

Use this page to try original IT Mastery sample questions on observability decisions. They are not official Splunk exam questions.

What these questions test

• interpreting metric time series, dimensions, charts, dashboards, and detectors
• distinguishing symptoms from root-cause evidence during service incidents
• choosing alert conditions that reduce noise while preserving useful signal
• using latency, error, saturation, and resource metrics to reason about health

Sample Exam Questions

Question 1

Topic: metrics

A service shows a sharp increase in request latency but no increase in request count. What should the analyst check next?

• A. Dashboard theme settings only
• B. Downstream dependency latency, saturation, error rate, deployment timing, and resource metrics
• C. User profile photos
• D. Whether all alerts can be disabled

Best answer: B

Explanation: Latency can rise without traffic growth. Dependencies, resource saturation, deployments, and errors can explain the change.

Question 2

Topic: dimensions

Why are dimensions useful in metric analysis?

• A. They replace dashboards
• B. They delete old data
• C. They guarantee the alert is correct
• D. They allow metrics to be filtered and grouped by attributes such as service, region, host, or environment

Best answer: D

Explanation: Dimensions provide context for slicing and grouping metrics. They help isolate where a problem is happening.

Question 3

Topic: dashboards

A dashboard should help on-call engineers triage service health. What is the best design?

• A. Show key signals such as latency, traffic, errors, saturation, and recent deployment context
• B. Hide alert status
• C. Use unrelated business metrics only
• D. Include only decorative labels

Best answer: A

Explanation: Operational dashboards should answer triage questions quickly. Key health signals and context help engineers decide where to investigate.

Question 4

Topic: detectors

An alert fires every night because batch workload behavior is expected at that time. What should be tuned?

• A. The service name
• B. The user’s browser settings
• C. Detector logic, thresholds, seasonality, scope, or schedule so expected behavior does not create noise
• D. The company logo

Best answer: C

Explanation: Detectors should distinguish expected patterns from abnormal behavior. Tuning reduces alert fatigue while preserving signal.

Question 5

Topic: alert routing

A database saturation alert should notify the database operations team, not the frontend team. What should be configured?

• A. A shared personal email address
• B. Routing based on service ownership, severity, and escalation policy
• C. A random recipient list
• D. No notification

Best answer: B

Explanation: Alerts must reach the team that can act. Ownership and severity should drive routing and escalation.

Question 6

Topic: latency

Which metric view best helps identify whether latency affects all users or only one region?

• A. A static text note
• B. A list of unrelated hosts
• C. One global average only
• D. Latency grouped by region or relevant location dimension

Best answer: D

Explanation: Grouping by region can expose localized issues hidden by global averages. Dimensions make this comparison possible.

Question 7

Topic: errors

A service’s error rate increases after a deployment. What is the best interpretation?

• A. Deployment timing is relevant evidence, but the team should confirm with logs, traces, metrics, and rollback or fix context
• B. The deployment is unrelated by definition
• C. The service is healthy because traffic is still flowing
• D. All errors are user mistakes

Best answer: A

Explanation: Timing correlation is useful but not final proof. Teams should confirm with multiple signals and deployment context.

Question 8

Topic: saturation

CPU usage is normal, but queue depth and response time are rising. What does this suggest?

• A. Metrics are never useful
• B. The system must be healthy because CPU is normal
• C. There may be bottlenecks outside CPU, such as downstream capacity, worker limits, I/O, or queue processing
• D. Alerts should be deleted

Best answer: C

Explanation: Saturation is not only CPU. Queues, I/O, worker pools, and dependencies can create delays even with normal CPU.

Question 9

Topic: baselines

Why can static thresholds be weak for highly seasonal workloads?

• A. Seasonal workloads do not produce metrics
• B. Normal behavior changes over time, so thresholds may need seasonality-aware or adaptive logic
• C. Dashboards cannot show seasonal data
• D. Static thresholds are always perfect

Best answer: B

Explanation: Seasonal systems can have predictable peaks and troughs. Thresholds should account for expected variation to reduce noise.

Question 10

Topic: service dependency

A frontend service is slow, but its own CPU and memory look normal. What should be checked?

• A. The frontend team’s meeting calendar only
• B. The dashboard description
• C. Whether all alerts can be silenced forever
• D. Downstream services, databases, external APIs, network paths, and trace or dependency metrics

Best answer: D

Explanation: User-facing latency may come from dependencies. Observability should connect frontend symptoms to downstream causes.

Question 11

Topic: incident review

After an incident, why review detectors and dashboards?

• A. To decide whether signal was missing, noisy, late, or unclear during the response
• B. To remove all dimensions
• C. To delete all historical data
• D. To blame the first responder

Best answer: A

Explanation: Post-incident review should improve observability. Teams should ask whether the available signals supported timely action.

Question 12

Topic: service-level indicators

Which signal best aligns with user experience for an API?

• A. Dashboard count
• B. Number of chart colors
• C. Request success rate and latency measured from the user-facing path
• D. Server hostname length

Best answer: C

Explanation: User-facing success and latency are closer to service experience than cosmetic or infrastructure-only measures.

Quick readiness checklist

Related IT Mastery pages

• Splunk Cloud Admin for cloud platform administration
• Splunk Enterprise Admin for Splunk deployment operations
• Linux Foundation Prometheus Certified Associate for observability practice
• AWS SysOps SOA-C03 for cloud operations practice