All Practice Exams

100+ Free LF Observability Practice Questions

Pass your Linux Foundation Observability Self-Hosted Fundamentals exam on the first try — instant access, no signup required.

✓ No registration✓ No credit card✓ No hidden fees✓ Start practicing immediately
Not published Pass Rate
100+ Questions
100% Free
1 / 100
Question 1
Score: 0/0

Which three signals are commonly referred to as the 'three pillars of observability'?

A
B
C
D
to track
2026 Statistics

Key Facts: LF Observability Exam

60

Exam Questions

Linux Foundation

75%

Passing Score

Linux Foundation

90 min

Exam Duration

Linux Foundation

$250

Exam Fee

Linux Foundation

5

Content Domains

LF Observability

2 years

Certification Validity

Linux Foundation

The LF Observability Fundamentals exam has 60 multiple-choice questions in 90 minutes with a 75% passing score. It covers observability fundamentals (20%), OpenTelemetry (25%), Prometheus and PromQL (25%), logging and tracing (20%), and SLO/SLI plus eBPF observability (10%). Aligns with LFS148 (OpenTelemetry) and LFS241 (Prometheus) curricula.

Sample LF Observability Practice Questions

Try these sample questions to test your LF Observability exam readiness. Each question includes a detailed explanation. Start the interactive quiz above for the full 100+ question experience with AI tutoring.

1Which three signals are commonly referred to as the 'three pillars of observability'?
A.Metrics, logs, and traces
B.Alerts, dashboards, and runbooks
C.CPU, memory, and disk
D.Errors, warnings, and info
Explanation: The three pillars of observability are metrics (numeric measurements over time), logs (timestamped event records), and traces (records of requests as they flow through distributed systems). Together they let operators answer different questions: metrics show what is happening at scale, logs show why a specific event occurred, and traces show how a request traversed services.
2What does the OpenTelemetry Collector primarily provide?
A.A managed cloud database for storing metrics
B.A vendor-agnostic agent that receives, processes, and exports telemetry data
C.A code instrumentation library for application developers
D.A frontend dashboard for visualizing traces
Explanation: The OpenTelemetry Collector is a vendor-agnostic proxy that can receive telemetry in many formats (OTLP, Jaeger, Zipkin, Prometheus, Fluent Forward), process it via pipelines (batching, filtering, attribute enrichment), and export it to one or more backends. It decouples application instrumentation from backend choice.
3Which protocol is the native, vendor-neutral wire format for OpenTelemetry data?
A.StatsD
B.Graphite plaintext
C.OTLP (OpenTelemetry Protocol)
D.Syslog
Explanation: OTLP (OpenTelemetry Protocol) is the native protocol for transmitting metrics, logs, and traces between SDKs, Collectors, and backends. It is defined by the OpenTelemetry project and is available over gRPC and HTTP/protobuf, with HTTP/JSON as an option for browsers and constrained environments.
4In the RED method for monitoring services, what do the letters R, E, and D stand for?
A.Reliability, Endurance, Density
B.Rate, Errors, Duration
C.Requests, Exceptions, Defects
D.Resources, Events, Dependencies
Explanation: The RED method, popularized by Tom Wilkie, focuses on three request-centric metrics for any service: Rate (requests per second), Errors (rate or count of failed requests), and Duration (latency distribution of requests). RED is well suited to request-driven, user-facing services such as HTTP and RPC APIs.
5In Brendan Gregg's USE method, what do U, S, and E represent?
A.Uptime, Speed, Errors
B.Utilization, Saturation, Errors
C.Usage, Service, Events
D.Users, Sessions, Exceptions
Explanation: USE stands for Utilization, Saturation, and Errors. It is applied to every resource (CPU, memory, disk, network) to quickly identify performance bottlenecks. Utilization is the percent time the resource was busy, saturation is the queue depth or backlog, and errors are the count of error events for the resource.
6Which Prometheus collection model does the server use by default?
A.Push: applications POST samples to Prometheus
B.Pull: Prometheus scrapes HTTP endpoints exposed by targets
C.Stream: long-lived gRPC connection per target
D.Polling DNS TXT records
Explanation: Prometheus uses a pull (scrape) model: the server periodically issues HTTP GET requests to /metrics endpoints exposed by instrumented applications and exporters. This makes target health observable, lets Prometheus rate-limit itself, and avoids needing instrumented apps to know where the server lives.
7Which Prometheus metric type represents a value that can go up or down, such as current memory usage?
A.Counter
B.Gauge
C.Histogram
D.Summary
Explanation: A Gauge is a metric that can arbitrarily go up and down. It is suitable for instantaneous measurements such as current memory in use, queue depth, or temperature. By contrast, a Counter only ever increases (or resets to zero on process restart).
8Which PromQL function calculates the per-second average rate of increase of a counter over the supplied range?
A.delta()
B.rate()
C.avg_over_time()
D.absent()
Explanation: rate(v[range]) computes the per-second average rate of increase of a counter over the time range, automatically handling counter resets. It is the canonical way to convert a counter into a rate, for example rate(http_requests_total[5m]) yields requests per second over the last 5 minutes.
9What does an SLI (Service Level Indicator) measure?
A.The legal contract between a provider and customer
B.A specific quantitative measure of an aspect of service quality, such as request success ratio
C.The internal target the team commits to internally
D.The maximum allowable downtime per quarter
Explanation: An SLI is a carefully defined quantitative measure of service quality, typically expressed as the ratio of good events to total events (for example, the proportion of requests with HTTP status < 500 served within 250 ms). SLIs are the raw input that SLOs and error budgets are derived from.
10What is an error budget?
A.The dollar amount allocated to fix bugs each quarter
B.The amount of unreliability allowed by an SLO before action must be taken
C.A list of error codes the application is allowed to return
D.The maximum number of incidents per year
Explanation: An error budget is the allowable amount of unreliability under an SLO, typically expressed as 100% minus the SLO target. For example, a 99.9% availability SLO over 30 days yields ~43.2 minutes of allowable downtime — once consumed, teams are expected to halt feature work and focus on reliability.

About the LF Observability Exam

The Linux Foundation Observability Self-Hosted Fundamentals certification validates working knowledge of OpenTelemetry, Prometheus, Grafana, Loki, Tempo, Jaeger, fluent bit/fluentd, and eBPF observability tooling. It covers the three pillars (metrics, logs, traces), RED and USE methods, four golden signals, SLI/SLO/error-budget design, and how to operate a self-hosted telemetry pipeline on Kubernetes.

Questions

60 scored questions

Time Limit

90 minutes

Passing Score

75%

Exam Fee

$250 (exam voucher) (Linux Foundation (PSI proctoring))

LF Observability Exam Content Outline

20%

Observability Fundamentals

Three pillars (metrics, logs, traces), RED method (Rate/Errors/Duration), USE method (Utilization/Saturation/Errors), four golden signals, observability vs monitoring, and high-cardinality wide events

25%

OpenTelemetry

OTel SDK and Collector, OTLP wire protocol, semantic conventions, resource attributes, baggage, manual vs automatic instrumentation, tail vs head sampling, and Collector deployment patterns (sidecar, agent, gateway)

25%

Prometheus and PromQL

Scrape model, metric types (counter, gauge, histogram, summary), PromQL (rate, irate, increase, histogram_quantile), recording rules, alerting rules, Alertmanager (routing, grouping, silences, inhibition), exporters, federation, and long-term storage with Thanos or Mimir

20%

Logging and Tracing

Loki and LogQL, Tempo and TraceQL, Jaeger storage backends, Fluent Bit and Fluentd, structured logging, W3C Trace Context (traceparent/tracestate), span attributes/events/links, exemplars, and trace-log correlation

10%

SLO/SLI and eBPF Observability

SLI/SLO/SLA definitions, error budgets, multi-window multi-burn-rate alerts, latency SLIs, alert fatigue avoidance, and eBPF observability tools (Pixie, Parca, Cilium Hubble)

How to Pass the LF Observability Exam

What You Need to Know

  • Passing score: 75%
  • Exam length: 60 questions
  • Time limit: 90 minutes
  • Exam fee: $250 (exam voucher)

Keys to Passing

  • Complete 500+ practice questions
  • Score 80%+ consistently before scheduling
  • Focus on highest-weighted sections
  • Use our AI tutor for tough concepts

LF Observability Study Tips from Top Performers

1Memorize the three pillars (metrics, logs, traces) and how each one answers different operator questions before moving on
2Practice writing PromQL: rate(metric[5m]), histogram_quantile(0.95, sum by (le)(rate(bucket[5m]))), and increase() patterns until they feel natural
3Know the OpenTelemetry signal types and instruments cold: Counter vs UpDownCounter, Histogram, and Asynchronous Counter
4Remember W3C Trace Context headers — traceparent and tracestate — and how head-based vs tail-based sampling differ
5Drill the RED method (Rate, Errors, Duration), USE method (Utilization, Saturation, Errors), and the four golden signals (latency, traffic, errors, saturation)
6Compute error budgets quickly: a 99.9% SLO over 30 days = ~43.2 minutes of allowed downtime; understand multi-window multi-burn-rate alerts
7Compare Loki labels to Prometheus labels — both reward low cardinality; know why request IDs should never be Loki labels
8Stand up a small LGTM stack (Loki, Grafana, Tempo, Mimir) plus the OTel Collector locally — the muscle memory pays off on scenario questions

Frequently Asked Questions

What does the LF Observability Self-Hosted Fundamentals exam cover?

The exam covers the three pillars of observability (metrics, logs, traces), OpenTelemetry SDK and Collector, OTLP, Prometheus and PromQL, Grafana, Loki/LogQL, Tempo/TraceQL, Jaeger, Fluent Bit/Fluentd, eBPF tools (Pixie, Parca, Cilium Hubble), and SLI/SLO/error-budget design for self-hosted stacks.

What is the format and passing score?

The exam is 60 multiple-choice questions delivered online with PSI proctoring. Candidates have 90 minutes and need to score 75% to pass. Linux Foundation foundational exams typically include one free retake within 12 months of purchase.

Is this the same as the OpenTelemetry Certified Associate (OTCA) or PCA?

It is broader than either. OTCA focuses specifically on OpenTelemetry and PCA on Prometheus. The Observability Self-Hosted Fundamentals exam combines both stacks plus logs (Loki, Fluent Bit), traces (Tempo, Jaeger), eBPF observability, and SLO/SLI design.

Do I need to know Kubernetes to pass?

Familiarity with Kubernetes helps because most self-hosted observability stacks run on Kubernetes (DaemonSets for log collectors, sidecars for OTel Collectors, kube-state-metrics, cAdvisor). Deep cluster operations knowledge is not required, but you should be comfortable with pods, services, and YAML.

Which Linux Foundation courses align with this exam?

LFS148 (Getting Started with OpenTelemetry, free) and LFS241 (Monitoring Systems and Services with Prometheus, paid) cover the bulk of the material. LFS162 (DevOps and SRE) and LFS261 (SRE Foundations) help with the SLO/SLI portion. Hands-on practice with Grafana, Loki, and Tempo is strongly recommended.