I85PREP
⌘ K
LF Observability study materials
LF Observability study resources

LF Observability practice questions

One question at a time. Build your LF Observability understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Observability Fundamentals

In observability, what distinguishes a metric from a log entry as a data type?

  1. A metric is a full-text record of a single request, while a log entry is an aggregated counter.
  2. A metric is stored only in memory, while a log entry is always persisted to disk.
  3. A metric always contains a stack trace, while a log entry never carries structured fields.
  4. A metric is a numeric measurement aggregated over time, while a log entry is a timestamped record of a discrete event with a payload. Correct answer.

Explanation

Metrics are numeric time-series values that are cheap to aggregate and alert on, whereas logs capture discrete events with rich contextual payloads. The two complement each other: metrics reveal trends, logs reveal specifics of individual occurrences.

Question 2Observability Fundamentals

What is the primary purpose of distributed tracing in an observability platform?

  1. To follow a single request across service boundaries and show where time is spent in each hop Correct answer.
  2. To capture application log lines and route them to a central store
  3. To enforce authentication and authorization between microservices
  4. To aggregate CPU and memory counters into hourly rollups for capacity planning

Explanation

A trace stitches together spans from multiple services using a shared trace context, letting you see the full path and latency breakdown of one request. This is essential for diagnosing cross-service latency and failure propagation.

Question 3Observability Fundamentals

A team wants to know the rate of HTTP 5xx responses per second over the last five minutes and alert when it spikes. Which signal is the most appropriate primary source?

  1. A dashboard panel showing the total number of requests since deployment
  2. A trace span attribute recording the status code of one sampled request
  3. A counter metric of 5xx responses evaluated with a rate function and an alert rule Correct answer.
  4. A debug log line emitted only when an exception is thrown

Explanation

Counters with a rate function give a per-second error rate over a sliding window, which is exactly what threshold-based alerting needs. Traces and logs are sampled or event-driven and do not reliably produce a continuous rate.

Question 4Observability Fundamentals

Why is high cardinality a concern when designing metric labels?

  1. Each unique label combination creates a separate time series, which multiplies storage and query cost Correct answer.
  2. High cardinality disables the ability to attach units to the metric
  3. High cardinality forces the metric type to change from counter to gauge
  4. High cardinality prevents the metric from being scraped by a collector

Explanation

In a time-series database, the label set defines series identity, so unbounded values such as user IDs or request IDs explode the number of series. That growth drives memory, storage, and query latency costs, so such dimensions belong in logs or traces instead.

Question 5Observability Fundamentals

What does the RED method focus on for request-driven services?

  1. Requests, Endpoints, and Deployments per release
  2. Retries, Exceptions, and Dependencies across a call graph
  3. Rate, Errors, and Duration of requests handled by a service Correct answer.
  4. Replicas, Events, and Disk usage of a node

Explanation

RED is a service-level monitoring framework built on request Rate, Error count, and Duration distribution. It suits microservices because it reflects the experience of callers rather than internal resource consumption.

Question 6Observability Fundamentals

The USE method is best applied to which kind of target?

  1. Source code branches awaiting merge review
  2. Resources such as CPUs, memory, disks, and network interfaces Correct answer.
  3. Business key performance indicators such as revenue per region
  4. Individual user sessions and their conversion funnels

Explanation

USE stands for Utilization, Saturation, and Errors, and it is designed for diagnosing resource bottlenecks on hosts and infrastructure components. It answers whether a resource is busy, queuing, or failing.

Question 7Observability Fundamentals

An SLO for a checkout API states that 99.9% of requests must succeed within 300 ms over a rolling 30-day window. What is the error budget for that window?

  1. The error budget equals the p99 latency value of 300 ms
  2. Approximately 1% of requests, corresponding to about 7 hours of allowed downtime
  3. Approximately 0.1% of requests, or about 43 minutes of the 30-day window expressed as allowed failure time Correct answer.
  4. Zero failures, because an SLO requires perfect reliability

Explanation

The error budget is the complement of the SLO target, so 100% minus 99.9% leaves 0.1% of events or time available for failure. Over 30 days that 0.1% corresponds to roughly 43 minutes of budget.

Question 8Observability Fundamentals

What is the key difference between an SLI and an SLO?

  1. An SLI is the measured indicator, while an SLO is the target value or range for that indicator Correct answer.
  2. An SLI is always a percentage, while an SLO is always a duration in milliseconds
  3. An SLI is a contractual penalty clause, while an SLO is an internal dashboard
  4. An SLI applies only to infrastructure, while an SLO applies only to business metrics

Explanation

The indicator is what you actually measure, such as the proportion of successful requests, and the objective is the threshold you commit to for it. Reliability practice separates measurement from the target so both can be tracked and reviewed.

Question 9Observability Fundamentals

What does an SLA add beyond an SLO?

  1. A guarantee that the service will never fail
  2. A method for sampling traces at the collector
  3. A replacement for monitoring dashboards
  4. An explicit agreement with consequences, such as credits, when the objective is missed Correct answer.

Explanation

An SLA formalizes the reliability commitment between provider and consumer and specifies remedies if the target is breached. SLOs are typically internal engineering targets that inform, but do not by themselves define, the contractual terms.

Question 10Observability Fundamentals

Which trace concept represents a single unit of work with a start time, duration, and parent relationship?

  1. Exporter
  2. Exemplar
  3. Resource attribute
  4. Span Correct answer.

Explanation

A span records one operation within a trace, carrying timing, status, and attributes, and spans nest via parent references. A trace is simply the tree of spans sharing one trace identifier.

Question 11Observability Fundamentals

What is trace context propagation responsible for?

  1. Assigning sampling rates based on service CPU usage
  2. Passing trace and span identifiers between services so their work joins one distributed trace Correct answer.
  3. Converting traces into log lines for long-term retention
  4. Compressing span payloads before they reach the backend

Explanation

Propagation carries identifiers, usually in HTTP headers, across process and network boundaries so each downstream span can reference the correct parent. Without it, each service would emit disconnected traces.

Question 12Observability Fundamentals

A service emits a log line for every request with structured fields for user ID, route, and latency. Which practice most improves the usefulness of these logs for debugging?

  1. Concatenating all fields into one free-text sentence
  2. Emitting them as structured JSON with consistent field names and a correlation identifier Correct answer.
  3. Reducing them to a single counter per route
  4. Writing them only to local disk on each pod

Explanation

Structured logs with stable keys can be filtered and aggregated reliably, and a correlation identifier links a log to its trace. Free-text lines resist machine parsing, which slows investigation.

Question 13Observability Fundamentals

Why do observability platforms commonly sample traces in high-traffic systems?

  1. To reduce the volume and cost of stored spans while retaining a representative view of request behavior Correct answer.
  2. To increase the cardinality of metric label sets
  3. To eliminate the need for metrics and logs entirely
  4. To guarantee that every error is captured without exception

Explanation

Full trace retention is expensive at scale, so sampling keeps a statistically useful subset while controlling storage and processing cost. Tail-based sampling can still prioritize errors and slow requests to limit blind spots.

Question 14Observability Fundamentals

What is the difference between head-based and tail-based trace sampling?

  1. Head-based runs in the backend, while tail-based runs only in the client SDK
  2. Head-based decides at trace start without knowing the outcome, while tail-based decides after seeing the complete trace Correct answer.
  3. Head-based samples only errors, while tail-based samples only successful requests
  4. Head-based stores all spans, while tail-based stores none

Explanation

Head-based sampling makes a probabilistic decision at the root, which is cheap and consistent but blind to whether the trace later fails. Tail-based sampling buffers spans and decides at completion, so it can keep all errors and slow traces at the cost of more collector memory.

Question 15Observability Fundamentals

Which metric type is appropriate for tracking the current number of active database connections?

  1. Histogram
  2. Gauge Correct answer.
  3. Summary
  4. Counter

Explanation

A gauge represents a value that can rise and fall, such as current connections or queue depth. Counters only increase, and histograms and summaries describe distributions of observed values.

Question 16Observability Fundamentals

A histogram metric records request latency buckets. What do the cumulative bucket counts enable you to compute?

  1. The total CPU time consumed by the server
  2. Approximate quantiles such as p95 and p99 across the observed requests Correct answer.
  3. The number of distinct users who made requests
  4. The exact value of every individual request

Explanation

Cumulative histogram buckets let a backend estimate quantiles by interpolation within the bucket where the target percentile falls. The estimate is approximate because exact values are discarded once bucketed.

Question 17Observability Fundamentals

Why is averaging latency across a window often misleading when assessing user experience?

  1. Averages always overstate the impact of the slowest requests
  2. Averages require histograms and cannot be computed from sums and counts
  3. Averages are only valid for gauges, never for latency
  4. Averages hide tail latency, so a small share of very slow requests can be invisible in the mean Correct answer.

Explanation

The mean is dominated by the bulk of fast requests, so a long tail affecting a minority of users may barely move it. Percentiles such as p95 and p99 surface the slow experiences that averages conceal.

Question 18Observability Fundamentals

In the four golden signals, what does saturation describe?

  1. The total count of requests arriving per second
  2. The proportion of requests that returned an error
  3. The time taken to serve a request end to end
  4. How close a resource is to its capacity limit, often reflected by queuing or throttling Correct answer.

Explanation

Saturation measures how full a constrained resource is, and it predicts degradation before errors appear. Latency, traffic, and errors are the other three golden signals.

Question 19Observability Fundamentals

A dashboard shows p50 latency steady at 40 ms while p99 has climbed from 200 ms to 900 ms. What is the most reasonable interpretation?

  1. Latency is irrelevant whenever the error rate is zero
  2. The metric is broken because p50 and p99 must move together
  3. Typical requests are fine but a subset of users now experience severe slowness, so tail behavior needs investigation Correct answer.
  4. Overall performance has improved because the median is unchanged

Explanation

Divergence between the median and the tail indicates that a minority of requests are degrading while most remain fast, a pattern that averages would hide. Investigators should segment by route, host, or dependency to find the slow cohort.

Question 20Observability Fundamentals

What role does a collector play in an observability pipeline?

  1. It receives telemetry from instrumented services, processes it, and forwards it to one or more backends Correct answer.
  2. It authenticates end users before they can view dashboards
  3. It stores all telemetry permanently as the system of record
  4. It replaces application instrumentation by generating spans automatically

Explanation

A collector acts as an intermediary that batches, filters, samples, and routes telemetry, decoupling applications from specific vendors. This lets operators change backends or apply processing centrally without redeploying services.

Question 21Observability Fundamentals

Why is correlating telemetry by a shared trace identifier valuable during incident response?

  1. It lets an engineer jump from a slow metric or log line to the exact distributed trace of that request Correct answer.
  2. It guarantees that all telemetry is stored in a single database
  3. It automatically rolls back the faulty deployment
  4. It removes the need to instrument downstream services

Explanation

When logs and spans carry the same trace ID, an investigator can pivot between signals to reconstruct what happened to a specific request. This shortens diagnosis compared with searching each signal store independently.

Question 22Observability Fundamentals

Which statement best describes exemplars in metrics?

  1. They are duplicate copies of a metric stored for redundancy
  2. They are the labels that define a metric's time series identity
  3. They are deprecated counters replaced by gauges
  4. They attach sampled trace references to metric observations so a spike can be linked to concrete requests Correct answer.

Explanation

Exemplars embed trace or span identifiers alongside metric samples, letting an operator navigate from an aggregate anomaly to a representative trace. This bridges the gap between high-level metrics and detailed request data.

Question 23Observability Fundamentals

What is the purpose of a service-level indicator defined as the ratio of good events to valid events?

  1. It records the deployment history of the service
  2. It lists every individual failed request for manual review
  3. It replaces the need for any logging or tracing
  4. It expresses reliability as a measurable proportion that can be compared against an objective over a window Correct answer.

Explanation

Defining an SLI as good events divided by valid events produces a normalized ratio that supports objective comparison and error-budget tracking. It is a summary measure, so detailed investigation still relies on logs and traces.

Question 24Observability Fundamentals

An engineer proposes using a user ID label on a request-count metric to enable per-user debugging. What is the most defensible objection?

  1. Per-user debugging is impossible without a service mesh
  2. Unbounded user IDs would create an unmanageable number of time series, so per-user detail belongs in logs or traces Correct answer.
  3. Adding a user ID label would change the counter into a gauge
  4. User IDs cannot be used as labels because labels must be numeric

Explanation

Label values with unbounded domains multiply series and overwhelm the metric store, which is a classic cardinality trap. High-detail, per-entity context is better served by logs and trace attributes designed for that granularity.

Question 25Observability Fundamentals

What does an alert rule based on a burn rate for an error budget measure?

  1. The ratio of CPU usage to memory usage on each host
  2. How quickly the service is consuming its allowed error budget relative to the SLO window Correct answer.
  3. The count of deployments made during the window
  4. The total number of alerts fired in the last hour

Explanation

Burn-rate alerting compares the current error rate to the rate that would exactly exhaust the budget over the SLO window, so a high multiplier signals fast budget consumption. Multi-window burn-rate rules reduce noise while catching both fast and slow burns.

Question 26Observability Fundamentals

Which statement best describes the relationship between observability and monitoring in modern distributed systems?

  1. Observability replaces the need to define any alerts because anomalies are always detected automatically.
  2. Monitoring requires distributed tracing, while observability only requires collecting host CPU and memory metrics.
  3. Monitoring answers predefined questions about known failure modes, while observability lets you investigate arbitrary novel questions from the telemetry you emit. Correct answer.
  4. Observability is a synonym for monitoring that only applies to infrastructure hosts rather than application services.

Explanation

Monitoring checks conditions you anticipated in advance, such as a threshold on error rate. Observability is the property of a system whose emitted telemetry lets you ask new, unanticipated questions and diagnose unknown failure modes. The two are complementary: alerts often come from monitoring, while root-cause investigation relies on observability.

Question 27Observability Fundamentals

Which set of telemetry signals is conventionally described as the three pillars of observability?

  1. CPU, memory, and disk utilization
  2. Metrics, logs, and traces Correct answer.
  3. Dashboards, runbooks, and on-call rotations
  4. Deployments, feature flags, and configuration files

Explanation

The three pillars are metrics, logs, and traces, each answering different questions: metrics for aggregate trends, logs for discrete events and detail, traces for request flow across services. Together they support investigation beyond prebuilt dashboards. Operational artifacts like runbooks or resource gauges are not pillars of observability.

Question 28Observability Fundamentals

A team needs to count how many HTTP 5xx responses a service returned during the last hour and alert on the rate. Which telemetry signal is the most direct fit?

  1. A continuous CPU profile of the service
  2. A counter metric labeled by status code Correct answer.
  3. A debug-level log line per request
  4. A distributed trace span per request

Explanation

Counters are cumulative metrics designed to be aggregated and rate-computed, so a counter labeled by status code directly supports counting 5xx responses and alerting on their rate. Logs and traces can also record errors, but counting them requires scanning large volumes rather than querying an aggregate series. Profiles describe where time is spent in code, not response outcomes.

Question 29Observability Fundamentals

What distinguishes a structured log entry from an unstructured one?

  1. Structured entries encode fields as machine-parseable key-value pairs, while unstructured entries are free-form text. Correct answer.
  2. Structured entries are sampled, while unstructured entries are always retained in full.
  3. Structured entries are always written to disk, while unstructured entries are only held in memory.
  4. Structured entries must be emitted at ERROR level, while unstructured entries are emitted at INFO level.

Explanation

Structured logging emits fields such as user ID or route as explicit key-value pairs, typically JSON, so tools can filter and aggregate without fragile text parsing. Unstructured logs are free-form strings that require regex extraction to query reliably. Storage medium, severity, and sampling are independent of whether a log is structured.

Question 30Observability Fundamentals

In distributed tracing, what does a span represent?

  1. A metric time series aggregated over a scrape interval
  2. A complete end-to-end request across all services
  3. A named, timed operation within a trace that may have a parent span and attributes Correct answer.
  4. A single log line emitted by an application

Explanation

A span is one timed unit of work, such as a database query or an HTTP handler, carrying a name, start time, duration, and optional parent reference and attributes. A trace is the collection of spans sharing one trace ID that together describe the whole request. Spans are not log lines or metric series.

Question 31Observability Fundamentals

Which statement best captures the purpose of a service-level objective (SLO)?

  1. It defines which metrics the collector should scrape from each host.
  2. It sets an internal reliability target for a measured indicator over a defined window. Correct answer.
  3. It is a legally binding contract that specifies financial penalties for downtime.
  4. It records the on-call engineer responsible for each incident.

Explanation

An SLO is an internal target, such as 99.9 percent of requests succeeding within a window, applied to a service-level indicator. It guides engineering priorities and error-budget policy without being a commercial commitment. Legal commitments with penalties are service-level agreements, and scraping or ownership details are unrelated.

Question 32Observability Fundamentals

What is the primary purpose of a service map derived from distributed traces?

  1. To schedule on-call shifts based on service ownership
  2. To store the raw log payloads for each individual request
  3. To list the source code files that changed in the most recent deployment
  4. To show which services call which others and where latency accumulates across the request path Correct answer.

Explanation

Trace-derived service maps aggregate parent-child span relationships to reveal call topology and per-edge latency, helping engineers localize where time is spent. They do not track code changes, store log payloads, or manage staffing. The map is a diagnostic view built from span data.

Question 33Observability Fundamentals

Which practice best supports correlating a log entry with the trace that produced it?

  1. Including the active trace ID and span ID as fields in the log entry Correct answer.
  2. Storing logs in a separate system that cannot be queried by identifier
  3. Writing the log entry without any identifiers so it stays compact
  4. Emitting the log entry only after the request has fully completed

Explanation

Adding the current trace ID and span ID to log records lets you pivot from a log line to the exact trace and back, which shortens incident investigation. This is the core of telemetry correlation. Omitting identifiers or isolating logs in an unqueryable store defeats that pivot.

Question 34Observability Fundamentals

A service reports that its p99 latency is 1.2 seconds while the mean is 90 milliseconds. Which interpretation is most defensible?

  1. The p99 value is invalid whenever it exceeds the mean by more than tenfold.
  2. Latency is uniformly distributed, so both values describe the same experience.
  3. A small fraction of requests are much slower than typical, and the mean hides that tail. Correct answer.
  4. Most requests take about 1.2 seconds, so the mean is misreported.

Explanation

A high p99 with a low mean indicates a long tail: most requests are fast, but roughly one percent are far slower. Because the mean is pulled only slightly by outliers, it conceals the slow requests that some users actually experience. Percentiles expose that tail, and a large gap between p99 and mean is normal for skewed latency.

Question 35Observability Fundamentals

Which metric type is most appropriate for tracking the total number of bytes served since a process started?

  1. Summary
  2. Gauge
  3. Histogram
  4. Counter Correct answer.

Explanation

A counter is a monotonically increasing value suited to cumulative totals such as bytes served or requests handled. Query systems compute rates and increases from counters. Gauges are for values that rise and fall, while histograms and summaries describe distributions of observations rather than running totals.

Question 36Observability Fundamentals

An engineer wants to know the rate of change of a counter metric over five minutes. What operation should the query perform?

  1. Average the raw counter values across all samples in the window
  2. Compute the per-second increase across the window and extrapolate to the range Correct answer.
  3. Read the raw counter value at the end of the window
  4. Take the maximum raw counter value observed during the window

Explanation

Counters are cumulative, so their absolute value is not meaningful for rate; you must compute the increase between samples over the window and divide by elapsed time. This yields a per-second rate that can be alerted on or graphed. Reading or averaging raw values mixes in the arbitrary process start time.

Question 37Observability Fundamentals

Which label design avoids unbounded cardinality in a request-count metric?

  1. Labeling by user ID
  2. Labeling by raw request URL including query string
  3. Labeling by HTTP method and route template Correct answer.
  4. Labeling by a unique request identifier

Explanation

Cardinality grows with the number of distinct label value combinations, so labels should have a small, bounded set of values. HTTP method and route template are naturally limited and safe. Raw URLs, user IDs, and request IDs each produce a new series per distinct value, which can overwhelm the metrics backend.

Question 38Observability Fundamentals

A team wants to alert when the error budget for an SLO is being consumed unusually fast. Which alerting approach fits best?

  1. A daily digest email listing all error log lines
  2. A multi-window burn-rate alert that compares the observed error rate to the budget Correct answer.
  3. A static alert on CPU utilization above 80 percent
  4. An alert that fires whenever any single request fails

Explanation

Burn-rate alerting compares the current error rate against the rate the budget allows, so it signals budget exhaustion speed rather than raw errors. Multi-window variants reduce false positives from brief spikes while still catching sustained burn. CPU thresholds and single-request alerts are not tied to the reliability target.

Question 39Observability Fundamentals

What is the main benefit of tail-based sampling over head-based sampling for traces?

  1. It eliminates the cost of collecting spans at the application.
  2. The sampling decision can use the full trace outcome, so slow or failed traces can be kept preferentially. Correct answer.
  3. It removes the need to propagate trace context between services.
  4. It guarantees that every span is stored without any sampling loss.

Explanation

Tail-based sampling defers the keep-or-drop decision until the whole trace is seen, allowing policies that retain errors and high-latency traces while sampling the routine majority. Head-based sampling decides at the start, before the outcome is known. Neither approach removes the need for context propagation or application instrumentation.

Question 40Observability Fundamentals

Why is a histogram preferred over a single average when reporting request latency?

  1. It converts latency into a counter that can only increase.
  2. It automatically discards slow requests so the average stays stable.
  3. It stores only the maximum latency, which is the value users care about.
  4. It records bucketed counts that let you compute quantiles and see the distribution shape. Correct answer.

Explanation

Histograms accumulate observations into buckets, so you can derive approximate quantiles and inspect how latency is distributed rather than collapsing it into one number. This reveals tails that an average hides. They do not store only the maximum, drop slow requests, or behave as monotonic counters.

Question 41Observability Fundamentals

A dashboard shows high request rate and high latency on a database service, while its connection pool is fully checked out. Which golden signal does the checked-out pool describe?

  1. Latency
  2. Errors
  3. Saturation Correct answer.
  4. Traffic

Explanation

In the four golden signals, saturation measures how full a constrained resource is, such as a connection pool at capacity. Traffic counts demand, errors count failed requests, and latency measures response time. A fully utilized pool indicates the service is near its limit and predicts degradation.

Question 42Observability Fundamentals

Which statement best describes how exemplars link metrics to traces?

  1. An exemplar replaces the need for histogram buckets by storing raw latency values.
  2. An exemplar is a log severity level used only for error events.
  3. An exemplar duplicates every trace into the metrics store for permanent retention.
  4. An exemplar attaches a sample trace ID to a metric observation so you can jump from a bucket to a representative trace. Correct answer.

Explanation

Exemplars are metadata attached to metric samples, typically carrying a trace ID from a representative request in a histogram bucket. They let you pivot from an aggregate spike to a concrete trace for investigation. They do not duplicate traces, replace buckets, or act as a log level.

Question 43Observability Fundamentals

A team is choosing between a gauge and a counter for tracking the number of items currently queued for processing. Which choice is correct and why?

  1. A counter, because queue depth only ever increases over time
  2. A histogram, because queue depth should be bucketed by size
  3. A gauge, because the queue depth rises and falls and its current value is what matters Correct answer.
  4. A summary, because quantiles of queue depth are always required

Explanation

Queue depth is a snapshot value that can increase or decrease as items arrive and are consumed, which is exactly what a gauge models. Counters only increase and would misrepresent a value that falls. Histograms and summaries describe distributions of observations, not a current level.

Question 44Observability Fundamentals

During an incident, an engineer sees error logs from one service but cannot tell which upstream requests triggered them. Which telemetry improvement most directly addresses this gap?

  1. Adding more host-level CPU metrics to the dashboard
  2. Lowering the log level to DEBUG for all services
  3. Propagating trace context across service boundaries and recording it in log fields Correct answer.
  4. Increasing the log retention period from seven to thirty days

Explanation

The gap is the inability to connect a downstream error to the originating request, which trace context propagation solves. Once the trace ID flows across services and appears in logs, the engineer can pivot from the error line to the full request path. Retention, verbosity, and host metrics do not establish that linkage.

Question 45Observability Fundamentals

Which statement best explains why observability data is often described as high cardinality and high dimensionality?

  1. Data is aggregated to one series per host before storage.
  2. Each event stores only a single numeric value to keep storage costs low.
  3. Attributes are limited to a fixed set defined at compile time.
  4. Each event can carry many attributes with many distinct values, enabling slicing by combinations such as user, route, and version. Correct answer.

Explanation

Observability events like spans and structured logs carry many attributes, and each attribute can take on many distinct values. This dimensionality lets you ask questions that slice by arbitrary combinations, which is why wide structured events are valuable. Restricting to one value or a fixed set would remove that flexibility.

Question 46Observability Fundamentals

An SLO of 99.9 percent availability over 30 days yields an error budget. A team has consumed 60 percent of the budget in the first five days of the window. What is the most reasonable conclusion?

  1. The SLO is automatically violated once half the budget is used.
  2. The current consumption rate will exhaust the budget well before the window ends unless the trend changes. Correct answer.
  3. The error budget should be reset to zero to restore the target.
  4. The budget is healthy because 40 percent still remains.

Explanation

Consuming 60 percent of a 30-day budget in five days implies a burn rate far above the sustainable pace, so the budget would be exhausted long before the window closes if the trend continues. Remaining budget must be judged against remaining time, not in isolation. An SLO is violated only when the target is actually missed, and budgets are not reset to fix it.

Question 47Observability Fundamentals

A team instruments spans but omits parent references when exporting them. What capability is most directly lost?

  1. Reconstructing the causal call hierarchy and per-hop latency breakdown of a request Correct answer.
  2. Attaching attributes such as HTTP status to each operation
  3. Storing the trace ID on each operation
  4. Recording the duration of each individual operation

Explanation

Parent references define the span tree, which is what lets you reconstruct the call hierarchy and attribute latency to specific hops. Without them, spans still carry their own duration, attributes, and trace ID, but the causal structure collapses into a flat list. The loss is structural, not per-span metadata.

Question 48Observability Fundamentals

A platform team wants to reduce metrics storage cost without losing the ability to alert on per-route error rates. Which approach best balances cost and capability?

  1. Store every raw URL as a label and downsample only after thirty days
  2. Keep low-cardinality route-template labels for alerting and move high-cardinality detail into sampled traces and structured logs Correct answer.
  3. Replace metrics entirely with full-fidelity logs for all requests
  4. Drop all labels from the metrics so only a single aggregate series remains

Explanation

Alerting needs stable, bounded series, so route-template labels preserve per-route error rates at low cardinality. High-cardinality detail such as individual URLs or users belongs in traces and structured logs, which are better suited to wide attributes and sampling. This splits signals by their strengths instead of overloading metrics.

Question 49Observability Fundamentals

Two services report healthy p99 latency individually, yet users experience slow checkout. Which explanation is most consistent with the telemetry?

  1. Both services must be misreporting their latency percentiles.
  2. The p99 metric is only valid for single-service architectures.
  3. User-perceived latency is unrelated to the sum of downstream service times.
  4. Latency accumulates in the serial chain of calls and in retries between services, so no single service's p99 reflects end-to-end time. Correct answer.

Explanation

End-to-end latency includes queueing, network hops, and retries across the call chain, so each service can meet its own p99 while the composed request is slow. This is why end-to-end tracing and a user-facing SLI are needed alongside per-service metrics. The individual percentiles are not wrong; they measure a narrower scope.

Question 50Observability Fundamentals

An engineer proposes sampling logs at the application to cut volume, keeping only one in a hundred INFO lines but all ERROR lines. What is the main analytical risk?

  1. Rare or unusual successful paths may disappear, biasing investigations that rely on comparing normal and abnormal behavior. Correct answer.
  2. Sampling increases storage volume by duplicating retained lines.
  3. Log sampling makes trace context propagation impossible.
  4. ERROR lines will be lost because sampling always applies uniformly across severities.

Explanation

Severity-aware sampling preserves errors but thins the baseline of normal behavior, which investigations often need for comparison. Rare successful paths and unusual flows can vanish, producing a skewed picture. Sampling does not inherently break context propagation or increase volume, and here ERROR lines are explicitly retained.