I85PREP
⌘ K
Observability Foundation study materials
Observability Foundation study resources

Observability Foundation practice questions

One question at a time. Build your Observability Foundation 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 culture and principles (Three Pillars, why monitoring alone is not enough)

In the three pillars model of observability, which pillar records discrete events with a timestamp and a payload describing what happened at a specific moment?

  1. Traces
  2. Profiles
  3. Metrics
  4. Logs Correct answer.

Explanation

Logs are discrete, timestamped records of events, and each entry carries a message plus optional structured fields describing what happened at that moment. Metrics are aggregated numeric measurements over time, and traces follow a request across services, so neither captures arbitrary event detail the way a log entry does.

Question 2Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A team can see that CPU utilization on a service is high but cannot determine which customer requests are slow or why. Which limitation of metrics-only monitoring does this illustrate?

  1. Metrics lack the high-cardinality context needed to isolate individual requests Correct answer.
  2. Metrics cannot be stored for longer than a few hours
  3. Metrics cannot be aggregated across multiple hosts
  4. Metrics are always sampled too infrequently to detect CPU spikes

Explanation

Metrics are cheap because they aggregate, which means they typically drop high-cardinality dimensions such as user ID or request ID. Without that context, an alert on CPU shows a symptom but not which requests or customers are affected, which is why metrics are paired with traces and logs.

Question 3Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What distinguishes observability from traditional monitoring?

  1. Observability lets you answer novel questions about internal state without shipping new code Correct answer.
  2. Observability replaces the need for alerting entirely
  3. Observability only applies to serverless architectures
  4. Observability requires collecting every log line at full fidelity

Explanation

Monitoring checks known failure modes against predefined dashboards and alerts, while observability is the property of being able to interrogate internal state to answer questions you did not anticipate. That usually means rich, well-correlated telemetry rather than simply more data.

Question 4Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A trace is composed of spans. What does a single span represent?

  1. A log file rotated on disk
  2. A single aggregated counter for the whole service
  3. A configuration snapshot of the deployment
  4. One timed operation within a request, with a start time, duration, and parent relationship Correct answer.

Explanation

A span records one unit of work, such as a database call or an HTTP handler, including its start, duration, attributes, and its parent span. The parent-child links assemble spans into a trace that shows where time was spent across the call path.

Question 5Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which metric type is most appropriate for tracking the number of currently open database connections at a point in time?

  1. A histogram
  2. A summary
  3. A counter
  4. A gauge Correct answer.

Explanation

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

Question 6Observability culture and principles (Three Pillars, why monitoring alone is not enough)

An engineer wants to know the 99th percentile latency of an endpoint over the last hour. Which pillar most directly answers this?

  1. Events
  2. Logs
  3. Traces
  4. Metrics Correct answer.

Explanation

Latency distributions are numeric time series, and histograms or summaries in a metrics system are designed to compute percentiles over a window. Logs and traces can be used to derive latency, but they are not the primary tool for routine percentile queries at scale.

Question 7Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Why is high cardinality often called the central problem of observability data?

  1. High cardinality causes clock skew between hosts
  2. High cardinality prevents distributed tracing from working
  3. The number of unique dimension combinations can grow explosively, driving storage and query cost Correct answer.
  4. High cardinality makes logs unreadable to humans

Explanation

Cardinality is the count of unique combinations of dimensions such as user ID, request ID, or URL. When those combinations multiply, index size, memory, and query cost grow quickly, which is why teams must decide deliberately where to keep high-cardinality context.

Question 8Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What does a service-level objective (SLO) express?

  1. The maximum number of pods a cluster may run
  2. The vendor contract for cloud infrastructure
  3. The list of on-call engineers for a quarter
  4. A target level of reliability for a service measured over a defined window Correct answer.

Explanation

An SLO states a measurable reliability target, such as 99.9 percent of successful requests over 30 days, tied to a service-level indicator. It gives teams a shared, quantitative definition of acceptable health that alerts and error budgets can reference.

Question 9Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A team's error budget is nearly exhausted mid-quarter. What is the intended cultural response?

  1. Ignore the budget because it is only a reporting artifact
  2. Disable alerting until the next quarter
  3. Increase the SLO target so the budget resets
  4. Slow down risky releases and prioritize reliability work until the budget recovers Correct answer.

Explanation

An error budget operationalizes the SLO by defining how much unreliability is acceptable, and spending it signals that risk should be reduced. The usual response is to prioritize reliability and limit change velocity until the budget recovers, which balances feature delivery against stability.

Question 10Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which practice best reflects a blameless postmortem culture?

  1. Identifying the individual who caused the outage and documenting their error
  2. Focusing on system conditions and process gaps that allowed the failure Correct answer.
  3. Restricting the postmortem to managers only
  4. Waiting until the next incident before reviewing the previous one

Explanation

Blameless postmortems assume people act rationally given the information and tools available, so the analysis targets systemic conditions, safeguards, and process gaps. This encourages honest reporting, which improves the quality of the learning.

Question 11Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What is the primary purpose of instrumenting code with structured telemetry rather than ad hoc print statements?

  1. To eliminate the need for testing
  2. To make the application run faster
  3. To produce consistent, queryable records that can be correlated across services Correct answer.
  4. To reduce the number of lines of code in the repository

Explanation

Structured telemetry emits fields such as trace IDs, service names, and status codes in a consistent schema, which makes records queryable and correlatable. Ad hoc prints lack that schema and cannot be reliably joined to traces or metrics.

Question 12Observability culture and principles (Three Pillars, why monitoring alone is not enough)

How does correlation between pillars typically work in a modern observability system?

  1. Each pillar uses a separate random identifier with no shared field
  2. Correlation requires copying all logs into the metrics database
  3. A shared trace ID or exemplar links logs, metrics, and traces for the same request Correct answer.
  4. Pillars are correlated only by matching wall-clock timestamps to the second

Explanation

Context propagation assigns a trace ID that is attached to spans, logs, and metric exemplars, allowing an engineer to pivot from an alert to the exact trace and its logs. Timestamp matching alone is too imprecise when many requests occur in the same second.

Question 13Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which statement best describes a distributed trace's role during incident triage?

  1. It shows where time is spent across service boundaries for a single request Correct answer.
  2. It reports the total disk usage of each node
  3. It defines the alert thresholds for the service
  4. It stores the full text of application error messages

Explanation

A trace visualizes the call path and per-span durations, so responders can see which downstream service or database call dominates latency. Logs carry detailed messages, and metrics carry thresholds, but the trace explains the request's time distribution.

Question 14Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What is the key difference between a counter and a histogram in a metrics system?

  1. A counter can decrease, while a histogram cannot
  2. A counter records distributions, while a histogram only counts total events
  3. A counter accumulates a monotonic total, while a histogram records the distribution of observed values Correct answer.
  4. A counter is stored only in logs, while a histogram is stored in traces

Explanation

Counters track cumulative totals that only go up, and rate functions derive per-second change from them. Histograms bucket observed values so that quantiles and averages over a window can be computed, which a plain counter cannot provide.

Question 15Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Why do many teams adopt sampling for distributed traces in high-traffic systems?

  1. Tracing every request is costly, so sampling preserves representative visibility at lower cost Correct answer.
  2. Sampling removes the need to propagate trace context
  3. Sampling makes spans immutable
  4. Sampling guarantees every error is captured

Explanation

Full-fidelity tracing at high volume generates enormous storage and processing cost, so sampling keeps a representative subset. Tail-based sampling can retain all traces containing errors or high latency while dropping routine ones, balancing cost against diagnostic value.

Question 16Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A dashboard shows a service is healthy by all golden signals, yet users report failures. What does this most likely reveal about the monitoring approach?

  1. The dashboard refresh interval is too long
  2. The golden signals are inherently unreliable and should be removed
  3. The signals measure infrastructure and server-side behavior but not the user-perceived journey Correct answer.
  4. The service has too few instances to measure

Explanation

Server-side signals can look healthy while failures occur in the client, in a dependency, or in a path the dashboard does not cover. Observability requires measuring the user journey end to end, for example with synthetic checks or real user monitoring, rather than only host and service internals.

Question 17Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What does the term telemetry most precisely refer to?

  1. The manual review of source code for defects
  2. The archival of database backups
  3. The automated collection and transmission of measurements and events from a system Correct answer.
  4. The process of writing runbooks for on-call staff

Explanation

Telemetry is data emitted by a system and shipped to a backend for analysis, covering metrics, logs, traces, and events. It is collected automatically by instrumentation rather than produced by manual review or documentation.

Question 18Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which characteristic most clearly indicates that an organization has an observability culture rather than only observability tooling?

  1. The company has purchased a commercial observability platform
  2. Logs are retained for thirty days
  3. Dashboards are created for every service
  4. Engineers routinely ask new questions of production data and share findings across teams Correct answer.

Explanation

Culture is shown by behavior: teams treat telemetry as a shared resource, explore it to answer unanticipated questions, and spread what they learn. Buying a platform, creating dashboards, or setting retention are supporting practices but do not by themselves demonstrate the culture.

Question 19Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What is the purpose of an exemplar in a metrics system?

  1. To define the retention period for a metric series
  2. To compress metric time series on disk
  3. To rename labels during ingestion
  4. To attach a sample trace or log reference to a metric observation for later drill-down Correct answer.

Explanation

An exemplar links an aggregated metric data point, such as a histogram bucket, to a concrete trace or log sample that contributed to it. This lets an engineer jump from an aggregate spike to a specific request for detailed investigation.

Question 20Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Why is it important to record the version and deployment identifier as a telemetry attribute?

  1. It reduces the storage cost of the telemetry
  2. It lets responders correlate behavior changes with specific releases Correct answer.
  3. It encrypts telemetry in transit
  4. It replaces the need for trace context

Explanation

Attaching version or deployment identifiers to metrics, logs, and spans lets teams compare behavior before and after a release and quickly attribute a regression to a specific build. This shortens diagnosis during incidents and supports canary analysis.

Question 21Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which scenario best demonstrates the value of observability over threshold-based alerting alone?

  1. A known disk-full condition triggers its configured alert
  2. A novel failure mode appears that no existing alert covers, and engineers investigate it from raw telemetry Correct answer.
  3. A certificate renewal job logs its success
  4. A scheduled backup completes on time

Explanation

Threshold alerts only catch conditions someone anticipated and encoded. Observability matters most when an unanticipated failure appears, because rich telemetry lets engineers form and test new hypotheses without shipping code.

Question 22Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What does context propagation accomplish in a distributed system?

  1. It carries trace identifiers and metadata across service calls so spans join into one trace Correct answer.
  2. It replicates databases between regions
  3. It rotates encryption keys on a schedule
  4. It balances traffic across load balancers

Explanation

Context propagation passes trace and span identifiers through headers or in-process context as a request moves between services. Each service continues the trace with correct parentage, producing a single coherent view of the request path.

Question 23Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A team instruments only its own service and not its dependencies. What is the most likely observability consequence?

  1. Logs will be duplicated across services
  2. Metrics will stop being collected for the service
  3. Traces terminate at the service boundary, hiding latency and errors inside downstream calls Correct answer.
  4. The SLO will automatically adjust to the missing data

Explanation

Without instrumentation in downstream services, the trace cannot show internal timing or errors beyond the boundary, so responders see the client-side wait but not its cause. End-to-end tracing requires participation along the call path.

Question 24Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which pair correctly matches a pillar with its typical storage and query model?

  1. Metrics with time-series databases and range queries over labels Correct answer.
  2. Metrics with full-text search indexes over messages
  3. Traces with relational tables of user accounts
  4. Logs with time-series databases and percentile functions

Explanation

Metrics are stored in time-series systems optimized for range queries, aggregation, and label-based filtering. Logs usually live in search or columnar stores, and traces in specialized trace backends keyed by trace ID.

Question 25Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Why does observability guidance recommend measuring symptoms users experience rather than only causes such as CPU?

  1. Cause-based signals cannot be collected automatically
  2. Symptom-based signals require no storage
  3. Cause-based signals are always inaccurate
  4. Symptom-based signals reflect actual impact and catch failures whose cause is unknown or varied Correct answer.

Explanation

Users experience latency, errors, and unavailability, and many different causes can produce them. Alerting on symptoms such as error rate and latency captures real impact and remains valid even when the underlying cause differs from what was anticipated.

Question 26Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which trio of telemetry types is conventionally described as the three pillars of observability?

  1. Incident tickets, postmortems, and on-call rotations
  2. CPU, memory, and disk utilization
  3. Dashboards, alerts, and runbooks
  4. Metrics, logs, and traces Correct answer.

Explanation

The three pillars are metrics, logs, and traces: each captures a different shape of telemetry and together they let an operator move from a broad signal to a specific request. Dashboards and alerts are consumption surfaces built on top of telemetry, not telemetry types themselves.

Question 27Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A team can state precisely which hosts are up and what their CPU load is, but cannot answer why a specific customer's checkout request failed. What does this most directly illustrate?

  1. Monitoring alone answers known-unknown questions, while observability addresses unknown-unknowns Correct answer.
  2. Checkout failures are impossible to observe without synthetic testing
  3. CPU metrics are always more valuable than request-level telemetry
  4. Host-level monitoring should be removed once logs are collected

Explanation

Classic monitoring checks conditions the team anticipated in advance, so it handles known failure modes well. Observability is the property of being able to ask new, unanticipated questions of the telemetry after the fact, such as why one particular request failed.

Question 28Observability culture and principles (Three Pillars, why monitoring alone is not enough)

In observability vocabulary, what distinguishes a metric from a log event?

  1. A metric is stored only in memory, while a log is stored only on disk
  2. A metric is a numeric measurement aggregated over time, while a log is a timestamped record of a discrete event Correct answer.
  3. A metric is always human-readable text, while a log is always a numeric value
  4. A metric describes a single request, while a log describes a whole fleet

Explanation

Metrics are cheap, aggregated numeric time series suited to trends and alerting, whereas logs are discrete timestamped records that carry rich per-event detail. The two differ in shape and cost profile, which is why they are queried differently.

Question 29Observability culture and principles (Three Pillars, why monitoring alone is not enough)

An on-call engineer receives an alert that a service's error rate crossed a threshold, and within minutes must determine which downstream dependency caused it. Which pillar is most useful for that specific step?

  1. A quarterly service-level report
  2. A list of past incident tickets
  3. A capacity-planning spreadsheet
  4. Distributed traces showing the request path across services Correct answer.

Explanation

Traces record the path of a request through services and show where time was spent or an error originated, which is exactly the dependency-localization step. The other artifacts describe capacity, historical trends, or process rather than the anatomy of a failing request.

Question 30Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which statement best captures the difference between an SLI and an SLO?

  1. An SLI is a legal contract, while an SLO is an internal dashboard
  2. An SLI is a measured indicator such as success rate, while an SLO is a target range for that indicator Correct answer.
  3. An SLI is a target range, while an SLO is the raw measurement
  4. An SLI applies only to infrastructure, while an SLO applies only to business revenue

Explanation

A service-level indicator is the actual measurement, for example the proportion of successful requests, and a service-level objective is the target you commit to for that measurement over a window. Keeping the measurement and the target distinct is what makes error budgets computable.

Question 31Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A team defines an SLO of 99.9 percent successful requests over 28 days and has consumed most of the resulting error budget with three weeks remaining. Which action is most consistent with error-budget practice?

  1. Tighten the SLO to 99.99 percent so the budget looks healthier
  2. Disable alerting until the next quarter begins
  3. Prioritize reliability work and slow risky releases until the budget recovers Correct answer.
  4. Ignore the budget because the SLO is only a guideline

Explanation

The error budget is a pre-agreed allowance for failure, and exhausting it early is a signal to shift investment toward reliability and reduce release risk. Changing the target to hide the shortfall defeats the purpose of the agreement.

Question 32Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which behavior most clearly distinguishes an organization with an observability culture from one that merely owns observability tooling?

  1. Dashboards are reviewed once per quarter by management
  2. Every service emits the same fixed set of default metrics
  3. Engineers routinely ask new questions of telemetry during incidents and feed findings back into instrumentation Correct answer.
  4. The organization has purchased a commercial observability platform

Explanation

Culture shows up in behavior: people interrogate telemetry to answer unanticipated questions and then improve instrumentation so the next investigation is easier. Owning a platform or a fixed metric set is a capability, not evidence of the feedback loop.

Question 33Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What is the primary purpose of a blameless postmortem?

  1. To learn how system and process conditions allowed an incident and to prevent recurrence Correct answer.
  2. To assign a permanent owner to every alert
  3. To identify which individual should be disciplined for the outage
  4. To satisfy an audit requirement with a signed document

Explanation

Blameless postmortems focus on the conditions, tooling, and decisions that made an incident likely so the organization can fix the system rather than punish a person. Punitive framing suppresses the honest reporting that makes the analysis useful.

Question 34Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Why does observability guidance favor structured telemetry over ad hoc print statements in production code?

  1. Print statements cannot be captured by log collectors
  2. Structured telemetry removes the need for any logging framework
  3. Print statements consume no CPU and structured telemetry does
  4. Structured fields can be filtered and aggregated consistently, while free text must be parsed heuristically Correct answer.

Explanation

Structured events carry typed, named fields that query tools can filter, join, and aggregate reliably, whereas free-form text requires fragile parsing. The benefit is queryability and consistency, not a difference in runtime cost or collector compatibility.

Question 35Observability culture and principles (Three Pillars, why monitoring alone is not enough)

How do the three pillars typically become correlated in a modern observability system?

  1. Shared identifiers such as trace and span IDs are attached to logs and metrics so a query can pivot between signals Correct answer.
  2. Each pillar is stored in a separate team's spreadsheet and reconciled manually
  3. Correlation happens only when an engineer copies values between browser tabs
  4. Metrics are converted into logs before storage

Explanation

Correlation depends on shared context: a trace identifier recorded on log lines and exemplars lets an operator jump from an aggregate metric to the exact trace and logs. Without shared identifiers the pillars remain isolated datasets.

Question 36Observability culture and principles (Three Pillars, why monitoring alone is not enough)

An engineer wants to jump from a spike on a latency histogram to an example trace that contributed to that spike. Which mechanism is designed for this?

  1. A log line that records only the request count
  2. A counter incremented on every request
  3. A second histogram with wider buckets
  4. Exemplars attached to the histogram buckets Correct answer.

Explanation

An exemplar is a sampled reference, usually a trace identifier, stored alongside a metric observation so an aggregate spike can be traced back to a concrete example. Wider buckets or raw counters change aggregation but do not link to individual traces.

Question 37Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What is the most precise meaning of telemetry in an observability context?

  1. The process of manually testing a system before release
  2. Data emitted by a system about its own behavior and environment, collected remotely for analysis Correct answer.
  3. Any document a team writes about its architecture
  4. The set of dashboards displayed in a team's office

Explanation

Telemetry is the automated output a system produces about itself, such as metrics, logs, and traces, which is collected and analyzed away from the source. Architecture documents, dashboards, and manual testing are related activities but are not the emitted data itself.

Question 38Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Why is high cardinality considered the central problem of observability data?

  1. Low-cardinality dimensions are impossible to index
  2. High-cardinality data is always inaccurate and should be discarded
  3. The number of distinct attribute combinations grows explosively, driving storage and query cost Correct answer.
  4. Cardinality only affects log volume and never metrics

Explanation

Cardinality counts distinct combinations of attribute values, and something like a user or request identifier can multiply into millions of series. That explosion makes indexing, storage, and query latency expensive, which is why cardinality management shapes observability design.

Question 39Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A service's golden signals all look healthy, yet users report slow page loads caused by a third-party script. What does this most likely reveal?

  1. Third-party scripts always appear in server traces
  2. The service should stop collecting server metrics
  3. The telemetry measures server-side health but not the user-perceived experience Correct answer.
  4. The golden signals are mathematically incorrect

Explanation

Server-side signals describe what the backend sees, and a client-side dependency can degrade the real user experience without touching those signals. Closing that gap usually requires client-side or real-user telemetry rather than a change to server metrics.

Question 40Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Observability guidance recommends alerting on symptoms users experience rather than only on causes such as CPU saturation. What is the main reason?

  1. Cause-based metrics cannot be collected at scale
  2. Symptom-based alerts require no thresholds at all
  3. CPU saturation never precedes an outage
  4. Symptom-based alerts fire when users are actually affected, while many cause-based alerts are harmless Correct answer.

Explanation

Many resource conditions are benign, so cause-based alerts generate noise that erodes trust in paging. Alerting on user-facing symptoms such as error rate or latency ties the page to real impact, with cause metrics used for diagnosis.

Question 41Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A team instruments only its own service and none of its dependencies. What is the most likely observability consequence?

  1. Error budgets can no longer be defined
  2. Traces end at the service boundary, so time spent in dependencies appears as unexplained latency Correct answer.
  3. Metrics from the instrumented service stop being collected
  4. The service's logs become unqueryable

Explanation

A trace is only as complete as the services that participate in it, so an uninstrumented dependency becomes a gap where latency and errors are invisible. The local service's own metrics and logs continue to work, but cross-boundary diagnosis is crippled.

Question 42Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which pairing correctly matches a pillar with its typical storage and query model?

  1. Metrics with time-series storage queried by aggregation over labels Correct answer.
  2. Logs with fixed-size counters queried by percentile
  3. Traces with full-text inverted indexes queried by keyword
  4. Metrics with document stores queried by fuzzy string match

Explanation

Metrics are numeric samples over time, so time-series engines store them and queries aggregate across label dimensions. Traces need span-oriented storage and logs need text indexing, so the other pairings misdescribe the models.

Question 43Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Why do high-traffic systems commonly sample distributed traces?

  1. Sampling guarantees that no error is ever missed
  2. Traces cannot be stored without sampling
  3. Sampling removes the need for trace identifiers
  4. Full capture of every request is expensive, and a statistical sample still reveals latency distributions and error paths Correct answer.

Explanation

At high volume, storing every span is costly, so sampling keeps a representative subset that still supports latency and error analysis. Sampling is a cost-control tradeoff and can miss rare events, which is why tail-based strategies exist.

Question 44Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which practice best reflects learning-oriented rather than blame-oriented incident review?

  1. Asking what conditions made the engineer's action seem reasonable at the time Correct answer.
  2. Recording which engineer caused the outage in the permanent record
  3. Requiring engineers to defend their actions before leadership
  4. Limiting the review to the single faulty commit

Explanation

Learning-oriented review reconstructs the context in which an action seemed sensible, which surfaces the systemic conditions that should change. Naming culprits or narrowing to one commit suppresses the broader analysis and discourages candor.

Question 45Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A team's dashboards show healthy averages while a small fraction of users experience multi-second delays. Which observability principle does this best illustrate?

  1. Averages are always the most reliable summary statistic
  2. Latency cannot be measured for individual requests
  3. Averages hide tail behavior, so distributions and percentiles are needed Correct answer.
  4. Dashboards should be replaced entirely by logs

Explanation

A mean can look fine while a slow tail affects real users, so latency should be examined as a distribution with percentiles. This is a core reason observability data must preserve enough detail to see beyond aggregates.

Question 46Observability culture and principles (Three Pillars, why monitoring alone is not enough)

What is the main purpose of attaching a deployment or version identifier to telemetry?

  1. To reduce the storage cost of log lines
  2. To correlate changes in behavior with specific releases and roll back confidently Correct answer.
  3. To satisfy a licensing requirement of telemetry vendors
  4. To replace the need for trace identifiers

Explanation

Version attributes let an operator segment error rates and latency by release, which quickly ties a regression to a deployment and supports rollback decisions. It is a diagnostic dimension, not a cost or licensing mechanism.

Question 47Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which scenario best demonstrates a question that observability can answer but fixed threshold alerting cannot?

  1. Confirming that a scheduled backup completed
  2. Investigating why latency rose only for users on a specific client version in one region Correct answer.
  3. Knowing whether the service process is running
  4. Receiving a page when disk usage exceeds 90 percent

Explanation

The first scenario requires slicing telemetry by attributes the team never anticipated when configuring alerts, which is the essence of exploratory observability. The others are anticipated conditions expressible as simple threshold or presence checks.

Question 48Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Why does the observability community emphasize measuring the user experience rather than only internal resource health?

  1. Users always report problems before monitoring detects them
  2. Internal resource health can be normal while the delivered experience is degraded, so user-facing indicators detect impact earlier Correct answer.
  3. Internal metrics cannot be aggregated over time
  4. Resource metrics are unreliable and should not be trusted

Explanation

Resource health is a proxy for service quality, and proxies can look fine while users suffer, for example when a dependency or client-side issue degrades the experience. Measuring outcomes such as success rate and latency directly ties telemetry to impact.

Question 49Observability culture and principles (Three Pillars, why monitoring alone is not enough)

A team adds a request identifier to every log line and trace span but never links the two datasets in its tooling. What is the most accurate assessment?

  1. The shared identifier enables correlation, but the value is realized only when queries can pivot between logs and traces Correct answer.
  2. Correlation is automatic once both datasets exist
  3. The identifier should be removed to save storage
  4. The identifier is useless because logs and traces can never be correlated

Explanation

A shared identifier is the necessary substrate for correlation, but the payoff comes when tooling lets an operator move from a trace to its logs and back. Without that pivot the data is correlatable in principle yet unused in practice.

Question 50Observability culture and principles (Three Pillars, why monitoring alone is not enough)

Which statement best explains why counters and histograms serve different observability needs?

  1. A counter is used only for logs, while a histogram is used only for traces
  2. A counter is sampled, while a histogram is never aggregated
  3. A counter tracks cumulative totals suitable for rates, while a histogram records a distribution of values suitable for percentiles Correct answer.
  4. A counter records distributions, while a histogram tracks cumulative totals

Explanation

Counters only increase and are used to compute rates such as requests per second, whereas histograms bucket observations so percentiles and distributions can be derived. Choosing the wrong type loses the ability to answer the intended question.