1. Foundations of Reliability Engineering and SREIntroduction and ContextDigital services have become infrastructure for commerce, public administration, healthcare, education, communication, and industrial activity. A service that is unavailable, excessively slow, insecure, or incapable of recovering from disruption can cause financial loss and damage trust even when its software appears functionally correct. Reliability engineering addresses this broader question: can a system be depended upon to deliver its intended service under stated conditions, including when components fail, demand changes, or operators make mistakes? Site Reliability Engineering (SRE) applies software engineering methods to the operation of large-scale and often distributed systems. It is not merely a collection of monitoring tools or an alternative name for system administration. SRE is an organizational and technical approach that treats reliability as an engineered outcome, measured through user-facing service indicators, managed through explicit risk decisions, and improved by automation and learning. The foundations of SRE are rooted in dependability theory, operations management, software engineering, safety engineering, and systems thinking. Understanding these foundations is essential before studying service-level objectives, incident response, observability, capacity planning, or reliability automation. The central argument of this chapter is that reliability is neither an accidental property nor an absolute condition. It is a managed relationship between user expectations, system behavior, engineering choices, and acceptable risk. Learning ObjectivesAfter studying this chapter, you should be able to: - distinguish dependability, reliability, availability, maintainability, resilience, and safety;
- explain the relationships among faults, errors, failures, and incidents;
- trace the evolution from traditional operations through DevOps, SRE, and platform engineering;
- describe the principles of shared ownership, engineering discipline, and acceptable risk;
- apply reliability concepts to practical service and organizational situations;
- identify common reliability mistakes, governance concerns, and emerging developments.
Dependability as the Umbrella ConceptDependability describes the extent to which a system can be trusted to provide its required service. It is an umbrella concept rather than a single metric. Depending on the system and its stakeholders, dependability may include reliability, availability, maintainability, safety, integrity, security, and resilience. A system is dependable when its behavior remains acceptably trustworthy over time and across expected operating conditions. For an online payment service, this may mean processing legitimate transactions correctly, remaining accessible during peak demand, recovering without data corruption, and protecting confidential information. For an industrial control system, dependability also includes safe behavior when sensors, networks, or control components malfunction. Dependability is relative to a specification. A service cannot be described as reliable in the abstract. It is reliable with respect to a defined function, environment, time period, and acceptable level of performance. A service that responds successfully to 99.9 percent of requests may be adequate for an internal reporting tool but unacceptable for emergency communications. Therefore, reliability engineering begins by clarifying what service users require and what failure consequences are tolerable. ReliabilityReliability is the probability that a system performs its required function without failure for a specified period and under specified conditions. The definition contains four important elements: intended function, failure-free operation, time, and operating conditions. If a component has a constant failure rate, its reliability can be represented conceptually as: R(t) = e^(-λt) where λ is the failure rate and t is time. Real software services rarely have a constant and easily measurable failure rate. They are affected by code changes, dependency failures, traffic patterns, configuration errors, and human actions. Nevertheless, the model illustrates an important principle: reliability concerns continuity of correct service over time, not simply whether a system works at one moment. AvailabilityAvailability is the proportion of time that a service is operational and accessible when required. A commonly used steady-state approximation is: Availability = MTBF / (MTBF + MTTR) where MTBF is mean time between failures and MTTR is mean time to repair or restore. This relationship shows why availability can improve either by preventing failures or by reducing the time required to detect, respond to, and recover from them. Availability is not identical to reliability. A system may fail frequently but recover quickly, producing high availability but poor reliability. Conversely, a system may fail rarely but remain unavailable for a long period after each failure. In modern services, availability should also be evaluated by request success, latency, correctness, and user impact rather than by a simplistic binary measure of whether servers are running. MaintainabilityMaintainability is the ease and speed with which a system can be inspected, repaired, modified, or restored. Maintainability depends on architecture, documentation, deployment processes, diagnostic information, modularity, test quality, and the skills of the operating team. A maintainable service makes failure understandable and recovery repeatable. Automated rollback, clear runbooks, versioned configuration, safe deployment mechanisms, and meaningful logs can reduce recovery time. Maintainability therefore links software design with operational performance. A system that is technically sophisticated but difficult to diagnose may be less dependable than a simpler system that can be restored confidently. ResilienceResilience is the ability of a system and organization to withstand disruption, adapt to changing conditions, recover service, and continue learning. Reliability commonly emphasizes failure-free operation; resilience emphasizes how the system behaves when failure or stress occurs. Resilience may be achieved through redundancy, graceful degradation, isolation, retries with appropriate limits, circuit breakers, backups, failover, rate limiting, and tested recovery procedures. It also includes organizational resilience: communication, decision-making, escalation, and learning during incidents. Resilience is not the same as invulnerability. A resilient system assumes that faults will occur and is designed to limit their consequences. SafetySafety is the absence of unacceptable risk of harm to people, property, the environment, or other protected interests. Reliability and safety overlap but are not equivalent. A system can be highly available yet unsafe, or it can fail operationally in a way that is safe by design. Safety engineering often uses hazard analysis, defense in depth, fail-safe behavior, independent safeguards, and formal approval controls. In a software service that controls physical equipment, a failure should not simply produce an error message; it may need to move the equipment to a safe state. SRE practices must therefore be adapted to the consequences of failure. Rapid deployment and experimentation may be appropriate for a low-risk web feature but require stronger controls in aviation, medical, financial, or critical infrastructure environments. A Failure Vocabulary: Fault, Error, Failure, and IncidentPrecision in terminology improves diagnosis and prevents organizations from treating symptoms as causes. A fault is a defect, abnormal condition, or initiating cause that can produce incorrect behavior. Examples include a defective software statement, failed disk, expired certificate, incorrect access policy, or broken network link. Faults may be dormant and remain undetected until a triggering condition occurs. An error is an incorrect internal state produced when a fault is activated. For example, a service may calculate an invalid memory address, hold an inconsistent database state, or load an incorrect configuration value. An error does not always become visible outside the system. A failure occurs when the delivered service deviates from its specified behavior. A user receiving an incorrect invoice, a request exceeding its latency target, or an API returning errors represents service failure. A fault can produce an error, and an error can lead to failure, but layers of containment may prevent the chain from reaching users. An incident is an operational event that requires response because it threatens or has degraded service, reliability, security, safety, or business objectives. An incident may result from a technical failure, but it can also arise from a security event, severe performance degradation, data-quality problem, or impending capacity exhaustion. Incident management is therefore broader than repairing broken hardware. The causal chain can be represented as: Fault → Error → Failure → Incident This chain is not inevitable. Detection, validation, isolation, redundancy, graceful degradation, and automated recovery can interrupt it. For example, a failed database replica is a fault; an unavailable replica is an internal error condition; if another replica serves requests correctly, no user-visible failure or incident may occur. From Traditional Operations to SRETraditional information technology operations developed around stable infrastructure, scheduled releases, specialized teams, and manual administration. Operations personnel provisioned servers, maintained networks, applied patches, monitored systems, and responded to outages. This model could work when applications changed slowly and environments were relatively predictable. As software delivery accelerated, however, the separation between development and operations created persistent tension. Development teams were often rewarded for delivering features, while operations teams were evaluated on stability. Developers sought frequent change; operations attempted to control change. Handoffs, ticket queues, incomplete documentation, and different performance measures increased deployment risk and slowed recovery. The problem was not simply interpersonal. It was a structural conflict in goals and incentives. DevOps emerged as a set of cultural, organizational, and technical practices intended to improve the flow of value from development to operation. Continuous integration, continuous delivery, infrastructure as code, automated testing, collaborative ownership, and feedback loops reduce the cost and risk of change. DevOps does not eliminate operations; it integrates operational concerns into the software delivery lifecycle. SRE developed as a more specific operating model in which software engineers design and automate the work required to operate reliable services. It emphasizes measurable objectives, error budgets, toil reduction, automation, incident learning, and a balance between feature velocity and reliability. SRE is therefore compatible with DevOps but provides a concrete framework for implementing several DevOps goals. Platform engineering is a further development in which dedicated teams build internal platforms that provide reusable capabilities to application teams. These capabilities may include deployment pipelines, observability, identity, secrets management, databases, service templates, and policy controls. A platform can reduce cognitive load and standardize reliable practices, but it must be treated as a product for internal users. A poorly designed platform merely centralizes complexity and creates a new bottleneck. The evolution may be summarized as follows: - Traditional operations emphasized manual control of infrastructure.
- DevOps emphasized collaboration, automation, and rapid feedback across development and operations.
- SRE emphasized engineering-based operations, measurable reliability, and managed risk.
- Platform engineering emphasized reusable internal products and paved paths for reliable delivery.
These approaches are not mutually exclusive. A mature organization may use DevOps culture, SRE practices, and platform capabilities simultaneously. The SRE Operating PhilosophyShared OwnershipReliability is not the exclusive responsibility of a central operations group. Teams that design and change a service must understand its operational consequences and participate in maintaining it. Shared ownership does not mean that everyone performs every task. It means that responsibility for service outcomes is distributed across the people who can influence them. Shared ownership requires clear service boundaries, on-call arrangements, escalation paths, service documentation, and access to relevant telemetry. It also requires leadership to align incentives. If product teams are rewarded only for feature delivery while another group absorbs the consequences of failures, ownership remains nominal. Engineering DisciplineSRE treats repetitive operational work as a candidate for software, automation, or process redesign. This does not imply that every activity should be automated immediately. It means that recurring work should be measured, understood, and evaluated for reduction. Engineering discipline includes version control for infrastructure and configuration, automated tests, controlled change, peer review, reproducible environments, observability, capacity analysis, and explicit recovery procedures. It also includes disciplined learning after incidents. A post-incident review should identify contributing conditions and systemic improvements rather than search for a person to blame. Acceptable Risk and the Error BudgetPerfect reliability is usually impossible and economically undesirable. Additional redundancy, testing, staffing, and operational controls have costs. SRE therefore frames reliability as a risk-management problem. A service-level objective (SLO) states a target level of performance over a period. If the SLO for successful requests is 99.9 percent over thirty days, the permitted unreliability is 0.1 percent, often called the error budget. The budget is not permission to fail carelessly. It is a decision mechanism that allows teams to balance innovation and reliability. When a service has consumed a substantial portion of its error budget, the organization may slow risky releases, prioritize reliability work, improve capacity, or investigate recurring failure modes. When ample budget remains, the team may accept more experimentation. This approach makes trade-offs visible rather than allowing them to be determined informally by the loudest stakeholder. Error budgets have limitations. A single aggregate percentage may hide severe regional, customer-specific, or security-related harm. A service may meet an availability SLO while returning incorrect data. Consequently, SLOs must reflect meaningful user journeys and may need multiple indicators for availability, latency, correctness, freshness, and safety. Toil and AutomationToil is manual, repetitive, automatable, tactical work that scales with service demand and provides little lasting value. Examples include repeatedly restarting a process, manually creating identical environments, or responding to predictable alerts without improving the underlying condition. Not all operational work is toil. Investigation, architectural improvement, incident coordination, and carefully designed maintenance may be valuable engineering work. The goal is to identify avoidable repetition and redirect effort toward durable improvements. Automation should be observable, tested, secure, and capable of safe failure; an unexamined automation script can amplify an error across many systems. Frameworks for Reliability ThinkingReliability engineering benefits from several complementary models. The reliability lifecycle begins with requirements and risk analysis, continues through architecture and implementation, and extends into deployment, operation, maintenance, and retirement. Reliability cannot be added only at the end through monitoring. Architectural choices such as state management, dependency design, data replication, and failure isolation influence the available reliability outcomes. The bow-tie model separates preventive controls from mitigative controls. On the left, controls such as testing, validation, access management, and redundancy reduce the probability of a hazardous event. On the right, detection, failover, incident response, backups, and recovery reduce consequences after the event. This model encourages organizations to invest in both prevention and response. The Swiss cheese model depicts defenses as layers with weaknesses. An incident occurs when weaknesses in several layers align—for example, an unsafe deployment, inadequate test coverage, an ineffective alert, and an unclear rollback procedure. The model discourages single-cause explanations and supports systemic analysis. STAMP and other systems-theoretic approaches view accidents as consequences of inadequate control within a complex system, not only as component failures. They are particularly useful where software, people, organizations, and regulation interact. In such environments, reliability analysis must include incentives, authority, communication, and operating procedures. Practical Application Across the Service LifecycleReliability work begins during service design. Teams should identify critical user journeys, dependencies, data-loss consequences, recovery objectives, capacity assumptions, and failure domains. Architecture reviews should ask not only whether the normal path works, but also what happens when dependencies are slow, credentials expire, traffic doubles, or a deployment is partially applied. During development, reliability is supported by unit and integration testing, static analysis, dependency management, failure testing, secure defaults, and performance evaluation. Continuous delivery should include progressive exposure, automated rollback, health checks, and controls that prevent an unhealthy version from receiving all traffic. During operation, telemetry should provide evidence about user experience and system condition. Metrics, logs, traces, synthetic checks, and event records serve different purposes. Alerts should be actionable and tied to symptoms or risks rather than every low-level fluctuation. Dashboards should help responders answer: Is the user affected? What changed? Which dependency is implicated? What action is safe? During incidents, the primary objectives are to protect users, stabilize the service, communicate clearly, and preserve evidence for later learning. Responders should use defined roles, escalation procedures, and tested runbooks. After restoration, a blameless review should examine detection, decision-making, technical conditions, coordination, and follow-up actions. Illustrative Case: The Checkout Service at Northstar RetailBackgroundNorthstar Retail operates an online store whose checkout service calls inventory, payment, tax, and shipping services. The company has adopted continuous delivery and wants to release a redesigned checkout experience before a major sales campaign. SituationDuring a staged release, checkout latency rises sharply for a subset of users. The payment provider is responding slowly, and the checkout service retries each request three times. The retries increase traffic to the already slow provider, exhaust application connection pools, and cause unrelated inventory requests to time out. Monitoring reports that servers are healthy because CPU utilization remains moderate. After twenty minutes, the release is halted, but customers continue to experience failed purchases. AnalysisThe immediate trigger is dependency latency, but the incident has several contributing conditions. The system lacks a strict timeout and circuit breaker for payment calls. Retry behavior is unbounded at the system level. The principal service-level indicator measures host availability rather than successful checkout completion. The release process has a rollback mechanism, but rollback does not remove the dependency overload. The organization also lacks a clearly assigned incident commander. Using the fault–error–failure–incident vocabulary, provider slowness is an external fault condition. Excessive outstanding requests and connection exhaustion are internal errors. Failed or delayed checkouts are service failures. The customer-impacting event requiring coordinated response is the incident. Approach and StrategyThe response team first disables the new checkout path and applies a controlled traffic reduction. It then limits retries, introduces bounded timeouts and a circuit breaker, and routes eligible customers to a degraded checkout flow that reserves the cart while payment is retried asynchronously. The team adds an SLO based on completed checkout transactions and a latency objective for the payment step. It also creates alerts based on checkout success and dependency saturation rather than infrastructure health alone. Longer-term actions include dependency contracts, load testing with slow-provider scenarios, progressive delivery, documented incident roles, and a review of error-budget policy before the campaign. The platform team provides a reusable library for timeouts, retry budgets, and telemetry, while the product team remains accountable for the checkout experience. OutcomeThe service is restored without data duplication or permanent loss. The organization concludes that high availability of application hosts had created false confidence because the user journey was failing. The revised design allows checkout to degrade partially rather than fail synchronously whenever the payment provider is slow. Learning PointsThe case demonstrates that reliability is a property of a service system, not an individual component. It also illustrates the danger of retries without budgets, the importance of user-centered SLOs, the value of graceful degradation, and the necessity of shared ownership between product, application, operations, and platform teams. Challenges, Risks, and Common MistakesOne common mistake is treating uptime as the complete definition of reliability. Users may experience incorrect results, unacceptable latency, stale information, or security exposure while uptime remains high. Another mistake is pursuing maximum redundancy without understanding correlated failures. Multiple replicas in one failure domain may fail together, and duplicated complexity can create new failure modes. Organizations also overestimate monitoring. More dashboards do not automatically produce better detection. Noisy alerts cause fatigue, while missing business-level indicators conceal serious harm. Similarly, automation can reduce toil but can also propagate bad configuration, delete resources, or accelerate an unsafe deployment if safeguards are absent. Blame-oriented incident reviews are another serious limitation. Fear discourages reporting, encourages concealment, and overlooks the conditions that made an error likely. A blameless approach does not remove accountability; it distinguishes learning-oriented analysis from intentional misconduct or negligence. SLOs can be misused when selected for convenience, imposed without user evidence, or reduced to a target that teams manipulate. Reliability targets should be reviewed as products, business models, dependencies, and risk profiles change. Finally, reliability initiatives can become detached from economics. Excessive controls may delay valuable change, while insufficient controls expose users and the organization to unacceptable harm. Governance, Ethics, and Professional ResponsibilityReliability decisions distribute risk. A team that chooses not to improve backup recovery, for example, may shift the consequences of failure to customers, employees, or the public. Professional responsibility therefore requires transparent risk assessment, appropriate documentation, and escalation when business pressure conflicts with safety, security, legal obligations, or user welfare. Governance should define authority for production changes, access controls, data protection, auditability, retention, incident communication, and recovery testing. Regulated environments may require evidence that controls operate effectively. Privacy principles must be included in observability design because logs and traces can contain personal or confidential information. Engineers should minimize sensitive data, restrict access, define retention periods, and protect telemetry as carefully as production data. Ethically, reliability teams should avoid misleading availability claims, concealment of incidents, discriminatory service degradation, and experimentation without appropriate safeguards. In high-consequence systems, safety cases, independent review, formal verification, or human override may be necessary. The appropriate level of rigor depends on potential harm, not merely on technical novelty. Technology and Emerging DirectionsCloud platforms, containers, infrastructure as code, managed services, and service meshes have expanded the tools available for reliability engineering. Distributed tracing and high-cardinality telemetry can improve diagnosis, while automated remediation can restore known failure modes rapidly. Chaos engineering tests whether systems behave acceptably under controlled disruption, but it should begin with clear hypotheses, safeguards, and rollback plans. Artificial intelligence is increasingly used for anomaly detection, event correlation, log summarization, capacity forecasting, and assistance during incident investigation. These tools can reduce cognitive load, but their recommendations require validation. False positives may create alert fatigue; false negatives may create dangerous confidence; and automated actions may amplify errors. AI should support, not replace, accountable engineering judgment. Platform engineering is likely to continue emphasizing self-service infrastructure, policy as code, standardized observability, secure software supply chains, and internal developer platforms. At the same time, organizations are recognizing that platform adoption requires user research, product management, documentation, and measured outcomes. A platform is reliable only when its abstractions remain understandable and its failure modes are visible. Best Practices for Foundational SRE WorkEffective organizations generally begin with explicit service definitions and user-centered reliability objectives. They measure meaningful outcomes, design for partial failure, and make changes gradually. They maintain tested backups and recovery procedures, use automation with safety controls, and keep operational knowledge accessible. They also establish clear ownership, sustainable on-call practices, and psychologically safe incident learning. Reliability work is prioritized using evidence from incidents, error-budget consumption, capacity trends, and customer impact. Finally, they treat reliability as a continuous lifecycle concern: requirements, architecture, development, delivery, operation, recovery, and retirement must reinforce one another. Chapter SummaryDependability is the broad quality of being worthy of trust. Reliability concerns failure-free service over a specified time and condition; availability concerns operational accessibility; maintainability concerns ease and speed of repair; resilience concerns resistance, adaptation, and recovery; and safety concerns unacceptable harm. These properties are related but not interchangeable. Faults may create internal errors, which may produce service failures and incidents. Preventive and mitigative controls can interrupt this chain. The movement from traditional operations to DevOps, SRE, and platform engineering reflects a shift toward collaboration, automation, measurable outcomes, and reusable capabilities. SRE rests on shared ownership, engineering discipline, and explicit management of acceptable risk through concepts such as SLOs and error budgets. Reliability must be designed across the service lifecycle and evaluated through user-centered evidence. Incident response, graceful degradation, dependency management, observability, and learning after failure are as important as prevention. Governance and ethics matter because reliability choices distribute risk among organizations, users, and society. Key TermsDependability: The degree to which a system can be trusted to deliver its required service. Reliability: The probability of performing a required function without failure for a specified time and condition. Availability: The proportion of required time during which a service is operational and accessible. Maintainability: The ease and speed with which a system can be repaired, modified, or restored. Resilience: The ability to withstand disruption, adapt, recover, and learn. Safety: Freedom from unacceptable risk of harm to people, property, or the environment. Fault: A defect or abnormal condition capable of causing incorrect behavior. Error: An incorrect internal state resulting from an activated fault. Failure: A deviation of delivered service from specified behavior. Incident: An event requiring coordinated response because service or risk objectives are threatened or degraded. DevOps: An approach integrating development and operations through collaboration, automation, and feedback. Site Reliability Engineering: An engineering-based approach to operating reliable services at scale. Platform Engineering: The creation of internal platforms that provide reusable capabilities to development teams. Service-Level Objective: A target level of service performance over a defined period. Error Budget: The permitted unreliability implied by an SLO. Toil: Repetitive, manual, automatable operational work with little enduring value. Graceful Degradation: Maintaining a reduced but useful service when full functionality is unavailable. Observability: The ability to infer internal system condition from externally generated outputs such as metrics, logs, and traces. Blameless Review: An incident analysis focused on learning and systemic improvement rather than personal blame. Review QuestionsShort Answer Questions1. Why is dependability considered an umbrella concept? 2. Distinguish reliability from availability. 3. What is the relationship among a fault, an error, and a failure? 4. Define toil and give one example. 5. What is the purpose of an error budget? Long Answer Questions1. Explain reliability, availability, maintainability, resilience, and safety, and show why they should not be treated as synonyms. 2. Trace the evolution from traditional operations to DevOps, SRE, and platform engineering. 3. Discuss shared ownership and engineering discipline as organizational foundations of SRE. 4. Explain how SLOs and error budgets support decisions about innovation and reliability. 5. Describe how reliability should be addressed throughout the service lifecycle. Analytical / Application Questions1. A service has few outages but regularly returns incorrect results. Analyze which dependability properties are deficient and propose suitable indicators. 2. A team adds three retries to every dependency call and then experiences cascading overload. Use the fault–error–failure–incident model to analyze the event and recommend controls. 3. Design a reliability strategy for a payment service that must continue operating when its external payment provider becomes slow or intermittently unavailable. Include technical, organizational, and governance measures. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best distinguishes reliability from availability? A. Reliability concerns security, while availability concerns safety. B. Reliability concerns failure-free operation over time, while availability concerns accessibility when required. C. Reliability measures repair effort, while availability measures design complexity. D. Reliability applies only to hardware, while availability applies only to software. Correct Answer: B. Reliability concerns failure-free operation over time, while availability concerns accessibility when required. Question 2A failed database replica produces an inconsistent internal state, but another replica continues serving correct requests. Which outcome has been avoided? A. A fault B. An error C. A user-visible failure D. A maintenance activity Correct Answer: C. A user-visible failure Question 3Which practice most directly reflects SRE’s principle of acceptable risk? A. Requiring every service to achieve 100 percent availability B. Using an error budget to balance releases against reliability work C. Allowing all teams to deploy without review D. Measuring only server CPU utilization Correct Answer: B. Using an error budget to balance releases against reliability work Question 4A service is operational, but users experience very slow checkout transactions. What does this illustrate? A. Infrastructure availability always proves service reliability B. A service can meet a simplistic uptime measure while failing a user journey C. Latency is unrelated to reliability engineering D. Maintainability and availability are identical Correct Answer: B. A service can meet a simplistic uptime measure while failing a user journey Question 5Which sequence correctly represents the typical causal chain described in the chapter? A. Failure → fault → incident → error B. Incident → error → fault → failure C. Fault → error → failure → incident D. Error → incident → failure → fault Correct Answer: C. Fault → error → failure → incident Question 6Which action is the best example of reducing toil? A. Adding another dashboard without changing an operational process B. Manually repeating a server restart every morning C. Automating a tested and observable routine environment-provisioning task D. Increasing the number of people assigned to repetitive ticket handling Correct Answer: C. Automating a tested and observable routine environment-provisioning task Question 7Why can a platform engineering team be viewed as a product team? A. Its platform has internal users whose needs and experience must be understood B. It is exempt from reliability objectives C. It replaces all application ownership D. It only manages physical data centers Correct Answer: A. Its platform has internal users whose needs and experience must be understood Question 8In the Northstar Retail case, why did host-health monitoring fail to reveal the full problem? A. The servers had no operating systems B. Host availability did not measure successful customer checkout C. The payment provider was part of the retail company D. The service had no dependencies Correct Answer: B. Host availability did not measure successful customer checkout Question 9Which control primarily mitigates consequences after a disruptive event has occurred? A. Input validation before deployment B. Peer review of source code C. A tested backup and recovery procedure D. Static analysis of a program Correct Answer: C. A tested backup and recovery procedure Question 10Why should AI-generated incident recommendations remain subject to engineering judgment? A. AI cannot process any operational data B. Automated recommendations may contain false positives, false negatives, or unsafe actions C. AI is useful only for marketing activities D. Incident response never requires evidence Correct Answer: B. Automated recommendations may contain false positives, false negatives, or unsafe actions
|
