10. Observability, Operations and Site Reliability Engineering

Introduction and Context

Cloud deployment does not end when an application is released. Once a service is running, its owners must determine whether it is available, sufficiently fast, correct, secure, and economically sustainable. They must also detect failures, understand their causes, communicate with affected stakeholders, restore service, and learn from incidents. These responsibilities constitute the operational dimension of cloud engineering.

Traditional monitoring usually asks whether a known component is functioning: Is the server reachable? Is CPU utilization high? Is a database connection available? Modern distributed systems require a broader capability. Observability asks whether the internal state of a complex system can be inferred from the evidence it emits. That evidence includes metrics, logs, traces, events, profiles, deployment information, and user-experience signals.

Site Reliability Engineering (SRE) provides a disciplined way to operate software-intensive services. It combines software engineering with operations and treats reliability as a measurable service property rather than an informal aspiration. SRE introduces service-level indicators, objectives, and agreements; error budgets; automation; incident management; and the systematic reduction of operational toil.

For cloud professionals, observability and SRE are particularly important because cloud systems are elastic, distributed, API-driven, and often assembled from managed services. A failure may cross application, network, identity, storage, and third-party boundaries. Tools supplied by AWS, Microsoft Azure, Google Cloud, and independent vendors can collect the necessary evidence, but tools alone do not create reliability. Effective operations depends on measurement design, sound decision-making, clear ownership, and organizational learning.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Explain observability and distinguish metrics, logs, traces, events, and profiles.

2. Design useful operational telemetry for cloud-native applications.

3. Define SLIs, SLOs, SLAs, and error budgets for a service.

4. Construct dashboards and alerts that support action rather than alarm fatigue.

5. Plan incident response, escalation, communication, and post-incident learning.

6. Apply capacity planning, root-cause analysis, runbook automation, and operational analytics.

7. Evaluate reliability trade-offs involving cost, performance, availability, security, and delivery speed.

8. Recognize governance, privacy, ethical, and organizational risks in observability programs.

From Monitoring to Observability

Monitoring is the practice of collecting and presenting information about system behavior. Observability is a property of a system and its instrumentation: the degree to which engineers can explain what is happening internally from available external outputs. A highly observable service does not merely reveal that requests are failing; it helps engineers determine which endpoint, dependency, release, tenant, region, or code path is responsible.

The distinction is important. A dashboard showing CPU, memory, and disk usage may be valuable, but it cannot necessarily explain why customers experience failed payments. Conversely, a service with well-designed request traces, structured logs, business metrics, and deployment metadata may be diagnosable even when infrastructure utilization appears normal.

The principal forms of telemetry are as follows.

Metrics are numerical measurements recorded over time. Examples include request rate, error rate, latency, queue depth, cache hit ratio, and database connection utilization. Metrics are efficient for dashboards, alert evaluation, and trend analysis. Counter metrics increase monotonically, gauges represent current values, histograms represent distributions, and summaries provide statistical approximations. Latency should normally be represented as a distribution or histogram rather than only an average, because averages conceal slow requests and tail behavior.

Logs are timestamped records of events. Application logs should be structured, commonly as JSON, and should include fields such as timestamp, severity, service, environment, request identifier, user or tenant reference where appropriate, operation, and error classification. A useful log explains an event without requiring an engineer to reconstruct it from unstructured text. Logs are valuable for detailed investigation but can become expensive, noisy, and difficult to search if they lack consistent schemas.

Traces represent the path of a request through distributed components. A trace is composed of spans, each describing an operation such as an API call, database query, message publication, or external request. Trace context must be propagated across services and asynchronous boundaries. Distributed tracing is especially effective for identifying latency contribution and dependency relationships.

Events record significant state changes, including deployments, autoscaling actions, configuration changes, certificate renewals, and infrastructure failures. Correlating events with metrics and traces often reveals that a performance change began immediately after a release or policy modification.

Profiles show how a process consumes CPU, memory, locks, or other runtime resources. Continuous or sampled profiling can expose inefficient code paths that ordinary metrics cannot identify. Profiling must be designed carefully for production overhead and data sensitivity.

A mature observability system correlates these signals. A metric alert may link to a dashboard; the dashboard may link to representative traces; a trace may link to logs for a particular request; and the timeline may display deployments or configuration changes. Correlation identifiers and consistent timestamps are therefore foundational design requirements.

Instrumentation in Cloud-Native Systems

Instrumentation can be built into application code, supplied by libraries and agents, or provided by cloud platforms. OpenTelemetry is a widely used framework for generating and exporting metrics, logs, and traces in a vendor-neutral manner. Cloud providers offer native services for collection, storage, visualization, and alerting, while third-party platforms often add cross-cloud analytics and application performance management.

Instrumentation should begin with user journeys and service boundaries rather than with a list of infrastructure counters. For an online ordering service, important measurements may include successful checkout rate, payment authorization latency, order completion time, and the percentage of orders requiring manual intervention. Infrastructure metrics remain useful, but they are supporting evidence rather than a complete definition of service health.

Telemetry design involves trade-offs. High-cardinality labels, such as unrestricted user identifiers or request IDs in metric dimensions, can make time-series storage expensive and queries slow. Sensitive data must not be placed casually in logs or traces. Sampling can reduce cost, but excessive sampling may remove the evidence required to investigate rare failures. A practical design often retains all error traces, samples normal traffic, and adjusts sampling dynamically during incidents.

A basic telemetry pipeline consists of producers, collectors, processors, exporters, and back ends. Applications and infrastructure produce signals. Agents or collectors enrich, filter, batch, and transmit them. Storage systems retain the signals for different periods and resolutions. Dashboards and analytical tools query the stored data. The pipeline itself requires monitoring: dropped spans, delayed logs, exporter failures, and clock skew can create false confidence.

SLIs, SLOs, SLAs and Error Budgets

Reliability becomes operationally useful when it is expressed through measurable objectives. A service-level indicator (SLI) is a quantitative measure of a service aspect. Common SLIs include availability, latency, freshness, correctness, durability, and throughput. An SLI should be defined from the consumer’s perspective where possible.

For example, availability can be defined as:

Availability = successful valid requests / total valid requests

If a request returns a server error or times out, it may be classified as unsuccessful. The definition must state how redirects, client errors, maintenance windows, retries, and dependency failures are treated. A vague statement such as “the service should be highly available” is not an SLI.

A service-level objective (SLO) is a target value for an SLI over a specified period. An objective might require 99.9 percent successful requests over a rolling 30-day window, or 95 percent of search requests to complete within 400 milliseconds. SLOs should be challenging but achievable and should reflect user expectations, business importance, architecture, and cost.

A service-level agreement (SLA) is a formal commitment to customers, often including remedies or credits when targets are not met. An SLO may be stricter than an external SLA. This margin allows the service team to respond before contractual obligations are violated.

The error budget is the permitted unreliability implied by an SLO. If the availability objective is 99.9 percent for a 30-day period, the error budget is 0.1 percent of eligible service time or requests. Request-based budgets are often more meaningful for APIs than time-based budgets because they reflect actual traffic. The budget can be expressed in failed requests, milliseconds of excess latency, or other appropriate units.

Error budgets create a decision framework. When sufficient budget remains, a team may proceed with a risky release, architecture experiment, or feature launch. When the budget is being consumed rapidly or exhausted, the team should prioritize reliability work, freeze selected changes, or increase testing and review. This is not a punishment mechanism; it is a way to balance innovation and dependability using evidence.

SLOs must avoid misleading aggregation. A global availability value can hide severe failure for a small but important customer segment. SLOs may therefore be segmented by region, endpoint, customer tier, or transaction type, provided that segmentation remains understandable and operationally manageable.

Dashboards and Alert Engineering

A dashboard is an instrument panel for a particular decision-maker and purpose. An executive dashboard may show customer-impacting availability, error-budget consumption, and major incidents. A service dashboard may show traffic, errors, latency, saturation, dependency health, and recent changes. A debugging view may provide high-dimensional breakdowns and links to traces and logs.

The four golden signals offer a useful starting point: latency, traffic, errors, and saturation. Latency should include tail percentiles such as p95 or p99 when appropriate. Traffic describes demand. Errors include explicit failures and, where possible, semantically incorrect responses. Saturation indicates how close a resource is to a limit, such as thread pools, queue capacity, database connections, or rate quotas.

Alerts should be actionable. An alert is justified when a human or automated system must take action. It should identify the affected service, severity, evidence, likely impact, and a link to a runbook. Thresholds based only on infrastructure utilization often create noise. SLO-based alerting is stronger because it asks whether the rate of error-budget consumption threatens the objective. Multi-window, multi-burn-rate alerts can detect both fast severe failures and slower degradation.

Alert severity should correspond to customer impact and urgency. Notification channels should reflect the required response: paging for immediate action, ticketing for work during business hours, and dashboards for observation. Every page should have an owner, escalation route, and documented response expectation. Alert fatigue is an operational risk: if engineers receive too many non-actionable alerts, genuine emergencies may be ignored.

Operating the Service: Incidents, Reliability and Learning

An incident is an event that significantly affects service reliability, security, data integrity, or business operations. Incident management is a socio-technical process, not simply a technical debugging exercise. A clear incident command structure separates coordination from investigation.

A typical response assigns an incident commander, an operations or technical lead, a communications lead, and a scribe. The incident commander establishes priorities and prevents parallel work from becoming chaotic. The technical lead coordinates diagnosis and mitigation. Communications personnel provide accurate internal and external updates. The scribe records decisions, timestamps, and actions.

The response usually follows five broad phases: detection, triage, mitigation, recovery, and learning. Triage determines scope, severity, affected users, and recent changes. Mitigation seeks to reduce harm quickly, perhaps through rollback, traffic shifting, feature disabling, rate limiting, or failover. Root-cause investigation may continue after service has been restored. Recovery includes validation, backlog processing, data reconciliation, and stakeholder communication.

A blameless post-incident review examines how system conditions, design decisions, tooling, procedures, and organizational pressures combined to produce the event. “Blameless” does not mean that accountability disappears. It means that the review seeks learning and system improvement rather than personal blame. A strong review records impact, timeline, detection quality, contributing factors, what worked, what failed, and prioritized corrective actions with owners and due dates.

Root-cause analysis should avoid simplistic single-cause explanations. Techniques include the five whys, fault-tree analysis, causal graphs, timeline analysis, and review of change history. In distributed systems, the initiating fault may not be the reason the incident became severe. For example, a slow dependency may have caused a retry storm, which exhausted connection pools and then triggered cascading failures. The analysis should identify both initiating conditions and amplification mechanisms.

Runbooks, Automation and the Reduction of Toil

A runbook is an operational procedure for a known condition. It should state symptoms, scope, safety checks, diagnostic commands or queries, mitigation steps, rollback procedures, escalation criteria, and validation checks. Runbooks must be tested and updated as systems change. A procedure that depends on undocumented personal knowledge is a reliability risk.

Automation is valuable when it is predictable, observable, reversible, and protected by authorization controls. Examples include restarting unhealthy workloads, scaling a worker pool, rolling back a failed deployment, draining a zone, rotating credentials, or replaying messages from a controlled dead-letter queue. Automation should not conceal failure. Each action should emit audit records and expose its result.

SRE distinguishes engineering work from toil. Toil is manual, repetitive, automatable, tactical work that scales with service growth and provides little enduring value. Reducing toil improves reliability and releases engineering capacity. However, automation can amplify mistakes. Changes should be tested in non-production environments, constrained by rate limits and approvals, and designed with safe failure modes.

Capacity Planning and Operational Analytics

Capacity planning ensures that a service can meet expected demand while preserving reliability and acceptable cost. It involves demand forecasting, resource modeling, performance testing, headroom decisions, and monitoring of leading indicators. Historical traffic patterns, product plans, seasonality, customer growth, and failure scenarios should inform forecasts.

A simple utilization model can relate arrival rate, average service time, and concurrency. If requests arrive at rate λ and require average service time W, expected concurrency is approximately λW. This relationship, often associated with Little’s Law, helps engineers reason about queues and worker capacity. It is not a substitute for load testing, because real systems have variable service times, bottlenecks, retries, and dependencies.

Capacity is not limited to virtual machines. It may include database connections, API quotas, partitions, IP addresses, storage IOPS, message throughput, cache memory, certificates, and human response capacity. Cloud elasticity reduces some infrastructure constraints but does not eliminate quotas, cold-start effects, dependency limits, or cost considerations.

Operational analytics combines telemetry, deployment data, incident records, change history, and business outcomes. Useful analyses include error-budget burn by release, latency by endpoint and region, incidents by contributing factor, alert precision, mean time to detect, mean time to restore, change failure rate, and toil hours. These measures should support improvement rather than become simplistic performance rankings. Mean time to restore, for example, can be reduced artificially by closing incidents prematurely; therefore it must be interpreted with quality and recurrence measures.

Illustrative Case: A Checkout Service Under Peak Load

Background

A fictional online retailer operates a cloud-based checkout service composed of an API gateway, order service, payment adapter, inventory service, message queue, and relational database. The service is deployed across multiple availability zones. The retailer has an SLO of 99.9 percent successful checkout requests over a rolling 30-day period and a p95 latency objective of 800 milliseconds.

Situation

During a promotional event, checkout errors rise from 0.3 percent to 8 percent. Infrastructure dashboards show moderate CPU usage. The first alert is triggered by database connection utilization, but several unrelated alerts also page engineers. Customers report duplicate order confirmations and delayed payment messages.

Analysis

The team establishes an incident commander and examines the error-budget dashboard. A trace sample shows that payment requests are slow. The payment provider has not failed completely; it is responding after several seconds. The order service retries payment calls three times with an aggressive timeout. Each retry consumes a database connection while the transaction remains open. Connection pools become exhausted, requests queue, and clients retry at the API layer. The result is a feedback loop involving slow dependency responses, excessive retries, connection exhaustion, and duplicate processing.

Logs are correlated using a request and idempotency identifier. Event data shows that a configuration change increased the retry limit shortly before the promotion. The CPU metric failed to indicate the problem because the dominant bottleneck was connection and dependency capacity rather than compute.

Approach and Solution

The immediate mitigation disables the additional retries, reduces payment concurrency, and routes new traffic through a controlled queue. The team temporarily disables a non-essential promotional feature and communicates the degraded payment experience to stakeholders. It reconciles queued orders and verifies payment status before issuing confirmations.

After recovery, the service is redesigned with bounded retries, exponential backoff, circuit breaking, explicit timeout budgets, and idempotency keys. Database transactions are shortened so that external payment calls do not hold connections unnecessarily. The team adds SLIs for successful completed checkouts, payment latency, duplicate-order rate, and queue age. Alerts are based on error-budget burn and queue growth rather than only CPU. A load test models slow payment-provider responses, and a runbook documents controlled traffic reduction and reconciliation.

Outcome and Learning Points

The incident demonstrates that a service can appear healthy at the infrastructure layer while failing at the user-journey layer. It also shows how retries can amplify dependency failure. Important lessons include the need to define reliability around business transactions, instrument asynchronous workflows, test degraded dependencies, limit automated retries, and treat configuration changes as production changes requiring review and observability.

Challenges, Risks and Professional Responsibilities

Observability programs face cost, complexity, and privacy challenges. Retaining every log and trace indefinitely is usually neither necessary nor economical. Retention should reflect legal obligations, incident-investigation needs, and data classification. Access must be controlled because telemetry can reveal customer behavior, credentials accidentally written to logs, internal topology, or commercially sensitive information.

Teams should adopt data minimization, masking, redaction, encryption, role-based access, retention limits, and audit logging. Production debugging must not justify exposing personal data broadly. Regulatory requirements may govern payment information, health data, location information, or cross-border transfer. Security operations and reliability operations should cooperate, since an attack can appear as an availability or latency incident and an operational shortcut can create a security weakness.

Common mistakes include measuring only infrastructure health, defining too many objectives, using averages instead of distributions, paging on every threshold breach, omitting deployment context, creating dashboards without owners, and writing post-incident reviews that generate untracked action lists. Another mistake is treating availability as the only reliability dimension. Correctness, freshness, durability, privacy, and recoverability may be more important for particular services.

Governance should establish service ownership, severity definitions, escalation expectations, change controls, evidence retention, and review processes. Reliability decisions also have ethical implications. A system that meets a global average SLO while systematically serving a particular region or user group poorly may be operationally and socially unacceptable. Segmentation and fairness analysis can reveal such disparities.

Emerging Directions

Observability is moving toward unified, vendor-neutral telemetry and richer causal analysis. OpenTelemetry-style instrumentation can reduce dependence on a single monitoring vendor, although semantic consistency and operational ownership remain necessary. eBPF-based tools can observe kernel and network behavior with limited application changes, while continuous profiling can identify resource inefficiency in production.

Artificial intelligence and machine learning are increasingly used for anomaly detection, event correlation, log summarization, and incident assistance. These systems can reduce investigation time, but their recommendations require human verification. Automated remediation should begin with narrow, reversible actions and strong safeguards. An AI system that changes routing or deletes resources without reliable context can increase incident severity.

Reliability engineering is also expanding beyond conventional service uptime. Platform engineering teams provide standardized observability, deployment, and incident capabilities. FinOps connects operational behavior with cloud cost. Resilience testing and controlled fault injection test whether systems behave as designed under dependency loss, latency, capacity exhaustion, and regional disruption. The broader trend is toward treating reliability, security, cost, performance, and developer experience as interconnected operational properties.

Best Practices for Cloud Operations

A professional cloud operations program should:

• define user-centered SLIs and realistic SLOs;
• instrument services with consistent metric, log, and trace conventions;
• correlate telemetry with releases, configuration changes, and infrastructure events;
• alert on actionable customer impact and error-budget risk;
• maintain tested, version-controlled runbooks;
• automate repetitive work with safeguards, auditability, and rollback;
• rehearse incidents, dependency failures, recovery, and disaster scenarios;
• perform blameless reviews with owned and measurable actions;
• forecast capacity across technical, provider, financial, and human limits;
• protect telemetry through minimization, access control, encryption, and retention policy; and
• evaluate reliability using both technical and business outcomes.

Chapter Summary

Observability enables engineers to infer the internal condition of distributed cloud systems through metrics, logs, traces, events, and profiles. Effective instrumentation connects technical behavior to user journeys and supports correlation across services, deployments, and dependencies. SRE converts reliability into measurable practice through SLIs, SLOs, SLAs, and error budgets. Dashboards should support decisions, while alerts should be actionable and tied to customer impact or budget consumption.

Reliable operations also requires disciplined incident management, blameless learning, root-cause analysis, tested runbooks, safe automation, capacity planning, and operational analytics. The checkout case illustrates how dependency latency and retries can create cascading failure even when CPU appears normal. Finally, observability must be governed as sensitive operational data, with attention to privacy, security, cost, fairness, and responsible automation.

Key Terms

Observability: The ability to understand a system’s internal state from the outputs and telemetry it produces.

Monitoring: The collection and presentation of information about system behavior and health.

Metric: A numerical measurement recorded over time.

Log: A timestamped record describing an application, infrastructure, or security event.

Trace: A representation of a request’s path through distributed components.

Span: An individual timed operation within a distributed trace.

Structured logging: Logging in a consistent machine-readable format with defined fields.

Cardinality: The number of distinct values in a metric label or data dimension.

Service-Level Indicator (SLI): A quantitative measure of a service characteristic.

Service-Level Objective (SLO): A target value or range for an SLI over a defined period.

Service-Level Agreement (SLA): A formal service commitment, often including remedies for failure.

Error budget: The permitted unreliability implied by an SLO.

Golden signals: Latency, traffic, errors, and saturation.

Alert fatigue: Reduced responsiveness caused by excessive or non-actionable alerts.

Incident commander: The person coordinating priorities, roles, and decisions during an incident.

Runbook: A documented procedure for diagnosing or responding to a known operational condition.

Toil: Repetitive, manual, automatable operational work with limited lasting value.

Root-cause analysis: A structured investigation of initiating and contributing factors in a failure.

Burn rate: The rate at which an error budget is being consumed.

Capacity planning: Forecasting and preparing resources to meet expected demand and reliability requirements.

Review Questions

Short Answer Questions

1. How does observability differ from conventional monitoring?

2. Why are latency percentiles often more useful than average latency?

3. Define an SLI and provide one example for an online checkout service.

4. What is the purpose of an error budget?

5. Identify two responsibilities commonly assigned during incident response.

Long Answer Questions

1. Explain how metrics, logs, traces, events, and profiles complement one another in a cloud-native observability architecture.

2. Discuss the relationship among SLIs, SLOs, SLAs, and error budgets, including their influence on release decisions.

3. Describe the stages of incident management and explain why blameless post-incident reviews are valuable.

4. Explain how capacity planning can include quotas, queues, database connections, cost, and human response capacity rather than only compute resources.

5. Discuss the governance, privacy, security, and ethical issues associated with collecting and analyzing production telemetry.

Analytical / Application Questions

1. An API has normal CPU utilization but rising p99 latency, queue depth, and timeout errors. Design an investigation using telemetry correlation and identify likely categories of bottleneck.

2. A service with a 99.9 percent monthly availability SLO consumes half of its error budget during one deployment. Recommend how the team should decide whether to continue feature delivery, roll back, or invest in reliability work.

3. A payment dependency becomes slow and causes repeated retries, duplicate requests, and database connection exhaustion. Propose immediate mitigations and longer-term design changes, including suitable SLIs and alerts.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes observability in a distributed cloud system?

A. It is the practice of checking whether every server is powered on.

B. It is the ability to infer internal system state from emitted evidence such as metrics, logs, and traces.

C. It is the replacement of all operational procedures with automation.

D. It is the measurement of cloud expenditure without reference to service behavior.

Correct Answer: B. It is the ability to infer internal system state from emitted evidence such as metrics, logs, and traces.

Question 2

Why is p99 latency often more useful than average latency for a customer-facing API?

A. It removes the need to measure errors.

B. It shows the experience of the slowest one percent of measured requests and exposes tail behavior.

C. It always has a lower value than average latency.

D. It measures infrastructure cost directly.

Correct Answer: B. It shows the experience of the slowest one percent of measured requests and exposes tail behavior.

Question 3

Which item is an example of an SLO rather than an SLI?

A. The proportion of successful checkout requests.

B. The p95 latency observed for search requests.

C. At least 99.9 percent of valid requests succeed over a rolling 30-day period.

D. The number of requests received per second.

Correct Answer: C. At least 99.9 percent of valid requests succeed over a rolling 30-day period.

Question 4

A team has exhausted its error budget because of repeated failed deployments. What is the most appropriate SRE response?

A. Ignore the budget because feature development is always more important.

B. Prioritize reliability work and increase controls on further risky changes.

C. Delete the historical telemetry so that the budget appears healthy.

D. Raise every alert threshold until no alerts occur.

Correct Answer: B. Prioritize reliability work and increase controls on further risky changes.

Question 5

Which alert is most likely to be actionable?

A. A page whenever CPU exceeds 40 percent for one minute.

B. A page for every individual application log entry.

C. A notification when rapid error-budget consumption indicates imminent violation of a customer SLO.

D. A page whenever any cloud resource changes state.

Correct Answer: C. A notification when rapid error-budget consumption indicates imminent violation of a customer SLO.

Question 6

In the illustrative checkout incident, what amplified the slow payment provider response?

A. Low CPU utilization and excessive cache capacity.

B. Bounded retries and short database transactions.

C. Aggressive retries that held database connections and caused further queuing.

D. A reduction in payment traffic caused by circuit breaking.

Correct Answer: C. Aggressive retries that held database connections and caused further queuing.

Question 7

What is the primary purpose of a runbook?

A. To provide a tested procedure for diagnosing or mitigating a known operational condition.

B. To replace all architectural documentation.

C. To store unrestricted customer data for future analysis.

D. To define only the financial cost of a cloud service.

Correct Answer: A. To provide a tested procedure for diagnosing or mitigating a known operational condition.

Question 8

Which practice best reduces the risk of unsafe operational automation?

A. Allowing automation to make unlimited irreversible changes.

B. Removing audit records to improve execution speed.

C. Using narrow, reversible actions with authorization, observability, and rollback controls.

D. Running automation only when no telemetry is available.

Correct Answer: C. Using narrow, reversible actions with authorization, observability, and rollback controls.

Question 9

A service’s CPU is stable, but database connection utilization and queue age are increasing with traffic. What does this most directly suggest?

A. The service has no capacity constraint.

B. A non-compute bottleneck or saturation point may be developing.

C. The monitoring system proves that the database is healthy.

D. The service should immediately increase log verbosity without analysis.

Correct Answer: B. A non-compute bottleneck or saturation point may be developing.

Question 10

Why should telemetry data be governed with access controls and retention policies?

A. Telemetry can contain sensitive personal, security, or commercially confidential information.

B. Telemetry has no operational value after one minute.

C. Access controls make all alerts unnecessary.

D. Retention policies eliminate the need for incident reviews.

Correct Answer: A. Telemetry can contain sensitive personal, security, or commercially confidential information.