Security, Dependability and Resilience Engineering

Introduction

Modern software is part of critical social and economic infrastructure. A full-stack application may process personal data, authorize financial transactions, control physical devices, or support decisions in healthcare, transport, and public administration. A defect, cyberattack, unavailable dependency, or unsafe recovery action can therefore cause more than inconvenience: it can produce financial loss, privacy violations, legal liability, physical harm, or loss of public trust.

Security, dependability, and resilience engineering provide complementary ways to manage these risks. Security protects confidentiality, integrity, authenticity, and availability against intentional misuse. Dependability concerns the degree to which a system can be trusted to deliver its required service. Resilience is the capability to anticipate, withstand, recover from, and adapt to disruptive events. These qualities must be engineered throughout the life cycle rather than inspected into a finished product.

This chapter presents secure-by-design practices, threat modeling, privacy engineering, safety analysis, fault tolerance, risk assessment, secure software supply chains, and resilience testing. It also considers regulated and mission-critical contexts, where evidence, traceability, and assurance are as important as implementation.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish security, safety, reliability, availability, dependability, and resilience;
• apply secure-by-design and privacy-by-design principles across the development life cycle;
• construct a practical threat model using assets, actors, attack paths, and controls;
• assess software risks using likelihood, impact, exposure, and uncertainty;
• explain fault tolerance, graceful degradation, recovery, and resilience testing;
• evaluate software supply-chain risks and propose appropriate controls;
• identify governance and assurance requirements in regulated or mission-critical systems;
• analyze trade-offs between security, usability, performance, cost, and operational continuity.

1. Quality Attributes and Their Relationships

A quality attribute describes a system property that influences how well it performs its required function. Functional requirements state what a system does; quality requirements state the conditions under which it must do it.

These properties overlap but are not interchangeable. A system may be highly available yet insecure if it remains accessible to attackers. It may be secure against unauthorized access yet unsafe if an authorized command can produce a hazardous physical action. A safety system may deliberately stop service, reducing availability in order to prevent harm.

Dependability is an umbrella concept commonly associated with availability, reliability, safety, integrity, and maintainability. Its interpretation depends on the system context and stakeholder expectations. Engineering begins by identifying unacceptable outcomes and converting them into measurable requirements, such as recovery time, maximum data loss, authentication strength, or probability of hazardous failure.

Secure by Design

Secure by design means that protection is treated as a primary architectural property, not as a final penetration-testing activity. Important principles include:

1. Least privilege: each identity, process, and service receives only the permissions necessary for its task.
2. Secure defaults: the system starts in a protective configuration; users must deliberately enable risky capabilities.
3. Defense in depth: independent controls reduce dependence on any single barrier.
4. Fail securely: errors should not disclose secrets or grant unauthorized access.
5. Complete mediation: authorization is checked whenever access to a protected resource occurs.
6. Separation of duties: sensitive actions require appropriately separated responsibilities.
7. Minimization: collect, retain, expose, and process only what is necessary.
8. Explicit trust boundaries: data crossing a boundary is validated, authenticated, and authorized.
9. Secure observability: logging supports detection and investigation without unnecessarily recording sensitive data.

Security is a socio-technical property. Training, operational procedures, supplier practices, identity governance, and incident response are part of the security design.

2. Security and Privacy Across the Life Cycle

Security activities should be connected to ordinary engineering work.

Requirements

Security and privacy requirements should be specific and testable. Examples include:

• “Administrative access shall require phishing-resistant multifactor authentication.”
• “A customer may view and export only records belonging to that customer.”
• “The service shall restore essential ordering functions within two hours after a regional outage.”
• “Personal location data shall be deleted after the stated retention period.”

Requirements should identify the protected asset, threat or harm, control, verification method, and owner. Ambiguous requirements such as “the system must be secure” cannot guide design or acceptance testing.

Architecture and Design

Architects identify trust boundaries, entry points, privileged components, data flows, failure domains, and recovery dependencies. A public web interface, application programming interface, message broker, database, identity provider, cloud account, and administrator workstation may all have different trust assumptions.

Privacy engineering adds questions about purpose and proportionality: Why is the data needed? Can the purpose be achieved with less data? Who can access it? How long is it retained? Can a person exercise access, correction, deletion, or objection rights? Privacy impact assessments are useful when processing is extensive, sensitive, automated, or likely to create significant risks.

Implementation

Developers apply parameterized queries, output encoding appropriate to the context, safe serialization, robust input validation, secure session handling, cryptographic libraries, dependency controls, and error handling that avoids information leakage. Secrets should not be embedded in source code or container images; they should be managed through controlled secret stores and rotated according to risk.

Verification and Validation

Verification asks whether the product was built according to its specification. Validation asks whether it meets the real operational need. Relevant techniques include code review, static analysis, dynamic testing, dependency scanning, fuzzing, penetration testing, abuse-case testing, configuration review, and independent assessment. No single technique proves absence of vulnerabilities.

Operations and Retirement

Operational security includes patch management, monitoring, access reviews, backup protection, incident response, vulnerability disclosure, and practiced recovery. Retirement requires revoking credentials, removing integrations, securely deleting or archiving data, and communicating changes to affected parties. Unsupported software is a known risk even if it has not yet been attacked.

3. Threat Modeling

Threat modeling is a structured method for anticipating how a system could be abused or fail. It is most effective when performed early and revisited after significant changes.

A useful process is:

1. Define scope and objectives. Identify system boundaries, stakeholders, assumptions, and unacceptable outcomes.
2. Inventory assets. Examples include credentials, payment records, source code, safety commands, availability, and audit evidence.
3. Map data flows and trust boundaries. Record processes, data stores, external entities, and communication paths.
4. Identify actors and capabilities. Consider anonymous users, ordinary users, insiders, compromised services, suppliers, and highly capable attackers.
5. Enumerate threats and abuse cases. Ask how confidentiality, integrity, availability, authenticity, or privacy could be compromised.
6. Estimate risk and prioritize. Consider impact, likelihood, exploitability, exposure, and uncertainty.
7. Select treatments. Avoid, reduce, transfer, accept, or share the risk with explicit authority.
8. Record assumptions and verify controls. A threat model is an engineering artifact, not a one-time workshop.

Threat categories may be organized with STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. STRIDE helps generate questions; it does not replace domain-specific safety, privacy, or operational analysis.

An attack tree starts with an attacker goal and decomposes it into conditions that could achieve the goal. An abuse case describes behavior that violates intended use. Both are useful for identifying missing controls and monitoring signals.

Controls should be linked to threats. For example, a threat of account takeover may require phishing-resistant authentication, rate limiting, anomaly detection, secure recovery, and user notification. A password rule alone is not a complete treatment.

4. Risk Assessment and Decision-Making

Risk is not simply a number; it is a reasoned judgment based on evidence and assumptions. A basic qualitative matrix may classify likelihood and impact as low, medium, or high. More detailed analysis can use an expected-loss model:

Here, E[L] is expected loss over a defined period, P(L) is the probability of the loss event in that period, and I is its impact, expressed in a consistent unit such as monetary cost. The model assumes that the probability and impact estimates are meaningful and that the event definition and time period are clear. It is unsuitable as the sole basis for decisions involving irreversible or catastrophic harm, where low-probability events may require controls regardless of expected value.

For availability, a simple operational measure is:

MTTF is mean time to failure and MTTR is mean time to repair or restore. Both must use the same time unit, and the expression assumes a stable long-run cycle in which failures and restorations can be meaningfully averaged. For example, if MTTF is 999 hours and MTTR is 1 hour, availability is 999 ÷ 1000 = 0.999, or 99.9%. This estimate does not capture correlated failures, planned maintenance, data corruption, or regional disasters.

Risk treatment should consider control effectiveness, residual risk, cost, usability, and consequences of failure. A risk register should record the risk statement, owner, affected asset, causes, existing controls, likelihood, impact, treatment, due date, and acceptance authority. Risk acceptance must be explicit and time-bounded, particularly in regulated systems.

5. Privacy Engineering and Responsible Data Use

Privacy is not identical to secrecy. A person may be harmed by excessive collection, unjustified inference, discriminatory profiling, loss of control, or unexpected secondary use even when data are not publicly disclosed.

Common privacy principles include lawfulness and transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability. Specific legal duties vary by jurisdiction; engineers must work with legal and compliance specialists rather than assuming that one framework applies universally.

Technical patterns include:

• pseudonymization, which separates identifying information from operational data but does not make the data anonymous;
• aggregation, which reduces individual detail for reporting;
• access control and encryption, which limit unauthorized use;
• retention automation, which reduces accidental accumulation;
• consent and preference management, where consent is the appropriate legal and ethical basis;
• privacy-preserving analytics, including carefully applied noise or restricted queries;
• data subject mechanisms, such as access, correction, portability, and deletion workflows where applicable.

Engineers should avoid claiming that data are anonymous merely because names were removed. Linkage with other datasets may re-identify individuals. Privacy controls must also address logs, backups, analytics platforms, test data, support tickets, and machine-learning training datasets.

6. Safety, Reliability, and Fault Tolerance

Safety engineering asks whether a system can avoid unacceptable harm, including harm caused by normal operation, misuse, component failure, or environmental conditions. It is especially important when software controls vehicles, medical devices, industrial processes, energy systems, or financial systems whose failure can destabilize essential services.

A safety analysis identifies hazards, causes, consequences, safeguards, and evidence. Techniques include hazard and operability studies, failure mode and effects analysis, fault-tree analysis, event-tree analysis, and structured hazard logs. Safety requirements should be independent enough to detect failures in the primary control path where necessary.

A fault is a hypothesized cause of an error. An error is an incorrect internal state. A failure is externally observable deviation from required service. Fault tolerance seeks to prevent faults from becoming failures or to limit their consequences.

Common mechanisms include:

• redundancy, such as replicated services or diverse sensors;
• timeouts and circuit breakers for unresponsive dependencies;
• retries with bounded attempts and exponential backoff, avoiding retry storms;
• bulkheads that isolate resource pools;
• idempotent operations, enabling safe repeated requests;
• transactional integrity and durable queues;
• health checks that test meaningful service behavior;
• graceful degradation, in which nonessential functions are disabled while essential functions continue;
• fail-safe states, where stopping or restricting operation is safer than continuing;
• checkpoints, backups, and tested restoration.

Redundancy does not automatically improve dependability. Replicas sharing the same software defect, credentials, region, network, or supplier can fail together. Independence, diversity, and failure-domain separation are therefore important.

A recovery objective must be explicit. Recovery time objective (RTO) is the maximum tolerable time to restore a service after disruption. Recovery point objective (RPO) is the maximum tolerable age of data after recovery, expressed as a time interval. For example, an RPO of 15 minutes means that the organization accepts losing at most approximately 15 minutes of changes under the stated recovery scenario; it does not guarantee zero loss.

7. Resilience Engineering

Resilience extends beyond prevention. A resilient organization prepares for known and unknown disturbances, detects abnormal conditions, maintains essential functions, recovers, and learns.

A resilience strategy typically includes:

• identification of critical business and safety functions;
• dependency mapping and concentration-risk analysis;
• capacity margins and rate limits;
• multiple recovery options and tested backups;
• incident command, communication, and escalation procedures;
• observability based on meaningful indicators;
• rehearsals, game days, and post-incident learning;
• adaptation when assumptions, threats, or operating environments change.

Resilience must be evaluated at several levels: component, service, application, organization, supplier, and ecosystem. A technically redundant application may still fail if its identity provider, cloud region, payment processor, or emergency staffing model is a single point of failure.

Testing should progress from controlled tests to realistic exercises. Backup restoration tests verify that backups are usable, not merely that jobs report success. Fault injection can disable dependencies, introduce latency, corrupt messages, exhaust resources, or revoke credentials in a controlled environment. Chaos engineering is valuable when hypotheses, safety boundaries, rollback procedures, and observation criteria are defined in advance. It must never become uncontrolled disruption of production systems.

Useful measures include restoration time, recovery-point achievement, failed-change rate, detection time, response time, percentage of critical dependencies with tested alternatives, and recurrence of previously identified causes. Metrics can be gamed; they should be interpreted with qualitative evidence and incident narratives.

8. Secure Software Supply Chains

Applications increasingly depend on open-source libraries, package registries, container images, build tools, cloud services, contractors, and automated pipelines. The supply chain can be attacked through malicious packages, typosquatting, dependency confusion, compromised maintainers, stolen signing keys, vulnerable build systems, or tampered artifacts.

Supply-chain controls include:

• maintaining an inventory or software bill of materials (SBOM);
• pinning and verifying dependency versions and integrity hashes;
• using trusted registries and controlled mirrors;
• scanning dependencies for known vulnerabilities while recognizing that scanners have false positives and negatives;
• reviewing licenses and maintenance health;
• applying least privilege to build agents and deployment identities;
• isolating builds and protecting signing keys;
• producing reproducible or attestable builds where feasible;
• signing artifacts and verifying provenance before deployment;
• monitoring advisories and rapidly evaluating exposure;
• defining supplier security, notification, audit, continuity, and exit requirements.

A vulnerability record alone does not establish risk. Exploitability, reachable code, configuration, exposure, compensating controls, and business impact must be considered. Conversely, absence of a known vulnerability is not proof of safety.

9. Governance, Regulation, and Assurance

Regulated and mission-critical systems require demonstrable control, not merely confident claims. Governance establishes who may make risk decisions, who verifies controls, how exceptions are managed, and what evidence is retained.

Relevant evidence may include requirements traceability, threat models, architecture decisions, test results, code-review records, access reviews, change approvals, incident reports, supplier assessments, backup exercises, and training records. Traceability links a requirement to implementation, verification, deployment, and operational monitoring.

Common governance themes across sectors include privacy protection, secure development, access control, records retention, segregation of duties, vulnerability management, incident reporting, business continuity, and independent assessment. Applicable standards and laws differ by jurisdiction and sector; examples include information-security management standards, privacy regulations, software security frameworks, safety standards, and sector-specific resilience rules. Compliance is a baseline, not a substitute for engineering judgment.

Ethical responsibilities are especially important when systems affect vulnerable people. Engineers should question excessive surveillance, opaque automated decisions, discriminatory outcomes, unsafe defaults, and designs that make consent meaningless. A technically legal action may still be ethically unacceptable if it exploits asymmetry of power or conceals material risk.

10. Illustrative Case: A Regional Digital Prescription Service

Background

A fictional national health organization operates a web and mobile service through which clinicians issue prescriptions and pharmacies retrieve them. The service uses a cloud platform, a national identity provider, a message queue, and several external suppliers. Availability is important, but confidentiality, integrity, patient safety, and regulatory accountability are equally significant.

Problem

An initial design stored long-lived access tokens in a browser, trusted client-supplied patient identifiers, retried failed pharmacy requests indefinitely, and relied on nightly backups that had never been restored in a full exercise. A third-party library also had an unreviewed transitive dependency. The organization’s first instinct was to purchase a penetration test.

Analysis

The engineering team first defined unacceptable outcomes: an unauthorized prescription, alteration of dosage, disclosure of medical information, duplicate dispensing, inability to access urgent prescriptions, and loss of audit evidence. A data-flow threat model identified the browser, identity provider, API gateway, prescription service, queue, pharmacy integration, database, logging platform, and supplier build pipeline. Trust boundaries were drawn around every external service.

Threats included account takeover, tampering with prescription messages, replay of requests, denial of service, compromised dependencies, insider misuse, and regional cloud failure. Safety analysis identified duplicate or delayed dispensing as hazards. Privacy analysis identified excessive logs and retention of patient identifiers. Risk owners and acceptance authorities were assigned rather than leaving the findings as an undifferentiated list.

Approach and Solution

The team replaced browser-held long-lived tokens with short-lived sessions and protected refresh mechanisms, enforced server-side authorization based on authenticated identity and role, and used signed, uniquely identified messages with replay detection. Prescription operations were made idempotent so that a retry could not create a second dispensing instruction. The queue applied bounded retries and dead-letter handling, while pharmacists received clear status information.

The service introduced separation between clinical authorization and infrastructure administration, encrypted sensitive data in transit and at rest, minimized identifiers in logs, and automated retention. Build agents were isolated, dependencies were inventoried, and release artifacts were signed and verified. Backups were encrypted and restored in a separate environment. Regional recovery procedures were tested against the RTO and RPO requirements.

A staged resilience exercise simulated identity-provider unavailability, queue delay, database read failure, and a compromised dependency. The service entered a controlled degraded mode: urgent verified prescriptions remained available through an approved process, while nonessential reporting was suspended. Incident communications and clinical escalation were rehearsed.

Outcome

The organization did not claim that risk had been eliminated. Instead, it reduced high-priority risks, documented residual risks, improved evidence for auditors, and discovered operational weaknesses that a conventional penetration test alone would not have revealed. The case demonstrates that security, safety, privacy, supply-chain assurance, and resilience must be engineered as a connected system.

Learning Points

• Start with harmful outcomes and critical functions, not only attack techniques.
• Treat external identity, cloud, and supplier services as dependencies with failure modes.
• Make recovery requirements measurable and test them under realistic conditions.
• Combine automated tools with architectural reasoning, human review, and operational exercises.
• Preserve evidence and assign accountable owners for residual risk.

11. Challenges and Limitations

Security and resilience controls create costs and trade-offs. Strong authentication may increase friction; replication may increase expense and consistency complexity; extensive logging may support investigations but create privacy risk; rapid patching may conflict with validation requirements; and graceful degradation may reduce functionality during an incident.

Risk models are uncertain. Historical incident frequency may be sparse, attackers adapt, and impacts may be nonlinear. Availability averages can hide short but critical outages and correlated failures. Automated vulnerability tools cannot understand all business logic, while human assessments can be inconsistent. Compliance checklists may encourage evidence production without genuine protection.

The answer is not to avoid measurement but to state assumptions, use multiple forms of evidence, revisit models, and involve domain experts and affected stakeholders. Critical systems require independence in assurance, clear escalation, and a willingness to stop deployment when evidence is inadequate.

12. Contemporary Developments and Best Practices

Cloud-native architectures, continuous delivery, software-defined infrastructure, artificial intelligence, and increasingly connected devices expand both capability and attack surface. AI-assisted coding can introduce insecure patterns, licensing concerns, fabricated dependencies, or leakage of confidential source material. Generated code requires the same review, testing, provenance, and ownership as human-written code. AI systems also require evaluation for data leakage, prompt abuse, model manipulation, bias, and unsafe automation.

A practical professional baseline is to:

1. define security, privacy, safety, and resilience requirements before implementation;
2. maintain threat, hazard, dependency, and data-flow models;
3. use secure defaults, least privilege, strong identity, and protected secrets;
4. automate tests and checks without treating automation as proof;
5. maintain dependency inventories, provenance, and supplier assurance;
6. design for bounded failure, graceful degradation, and recoverability;
7. test restoration, incident response, and degraded operation;
8. monitor meaningful signals and protect logs;
9. document decisions, exceptions, residual risks, and evidence;
10. learn from incidents, near misses, exercises, and changing threats.

For a full-stack developer, employability increasingly depends on being able to explain not only how a feature works, but also who can misuse it, what happens when a dependency fails, what data are retained, how the service recovers, and how the team can demonstrate that controls operate as intended.

Chapter Summary

Security, dependability, and resilience are interconnected system qualities that must be addressed across requirements, architecture, implementation, verification, operations, and retirement. Secure-by-design uses principles such as least privilege, secure defaults, defense in depth, complete mediation, and explicit trust boundaries. Threat modeling identifies assets, actors, attack paths, and controls; risk assessment prioritizes treatment while acknowledging uncertainty. Privacy engineering limits unnecessary collection, use, retention, and disclosure of personal data. Safety analysis focuses on unacceptable harm, while reliability and fault tolerance address failures through redundancy, isolation, idempotency, graceful degradation, and recovery.

Resilience requires preparation, detection, continuity, recovery, and learning across technical and organizational boundaries. Supply-chain security depends on dependency inventories, provenance, protected build systems, artifact verification, and supplier governance. Regulated and mission-critical environments require traceability, independent assurance, tested recovery, accountable risk acceptance, and ethical consideration of affected people. No single tool or test proves that a system is secure or dependable; confidence comes from layered controls, evidence, realistic exercises, and continuous learning.

Key Terms

Security: Protection against unauthorized access, use, disclosure, alteration, disruption, or destruction.

Dependability: The extent to which a system can be trusted to deliver required service.

Resilience: The capability to anticipate, withstand, recover from, and adapt to disruption.

Safety: Avoidance of unacceptable harm to people, property, or the environment.

Reliability: The ability to perform required functions without failure for a specified time and conditions.

Availability: The degree to which a service is operational and accessible when required.

Threat model: A structured representation of assets, actors, threats, trust boundaries, and controls.

Trust boundary: A point where data, authority, or assumptions cross between different trust domains.

Least privilege: Granting only the permissions necessary for an authorized task.

Defense in depth: Use of multiple independent or partially independent protective controls.

Privacy by design: Embedding privacy protections into system design and life-cycle decisions.

Fault tolerance: The ability to continue acceptable service despite specified faults.

Graceful degradation: Reducing nonessential functionality while preserving essential service.

RTO: Maximum acceptable time to restore a service after disruption.

RPO: Maximum acceptable age of data after recovery.

SBOM: A structured inventory of software components and dependencies.

Supply-chain attack: Compromise introduced through a supplier, dependency, tool, or build process.

Residual risk: Risk remaining after controls are applied.

Traceability: Evidence linking requirements, implementation, verification, deployment, and operation.

Hazard: A condition or event with potential to cause harm.

Review Questions

Short Answer Questions

1. How do security, safety, and resilience differ?
2. What is the purpose of a trust boundary in threat modeling?
3. Define RTO and RPO.
4. Why is an SBOM useful in software supply-chain security?
5. What does least privilege mean?

Long Answer Questions

1. Explain how security and privacy should be integrated across the software development life cycle.
2. Describe a complete threat-modeling process and explain how its outputs guide design decisions.
3. Compare reliability, availability, fault tolerance, and resilience using practical examples.
4. Discuss the benefits and limitations of redundancy, retries, circuit breakers, and graceful degradation.
5. Explain why regulated systems require traceability and evidence in addition to technical controls.

Analytical / Application Questions

1. A payment service depends on one identity provider and one regional database. Analyze its security and resilience risks and propose a prioritized treatment plan.
2. A mobile application collects precise location data continuously for a feature used once per day. Apply privacy-engineering principles to assess the design and recommend alternatives.
3. During an incident, a queue retries requests indefinitely and creates duplicate orders. Analyze the failure mechanism and design a safer message-processing approach.

Multiple Choice Questions with Answers

Question 1

Which principle requires a component to receive only the permissions necessary for its task?

A. Least privilege

B. Open access

C. Data replication

D. Failover clustering

Correct Answer: A. Least privilege

Question 2

In threat modeling, what is a trust boundary?

A. A point where trust assumptions or authority change

B. A backup copy stored in another region

C. A list of software licenses

D. A measure of database performance

Correct Answer: A. A point where trust assumptions or authority change

Question 3

If MTTF is 999 hours and MTTR is 1 hour, what is the estimated availability under the stated simple model?

A. 90%

B. 99%

C. 99.9%

D. 99.99%

Correct Answer: C. 99.9%

Question 4

What does an RPO of 15 minutes specify?

A. The maximum time allowed to authenticate a user

B. The maximum acceptable age of data after recovery

C. The maximum number of retries for a request

D. The maximum time a password may remain active

Correct Answer: B. The maximum acceptable age of data after recovery

Question 5

Which practice most directly reduces the risk of duplicate effects when a request is safely repeated?

A. Idempotent operation design

B. Longer session duration

C. Removing audit logs

D. Disabling timeouts

Correct Answer: A. Idempotent operation design

Question 6

Which statement about an SBOM is correct?

A. It proves that every component is vulnerability-free

B. It inventories software components and dependencies

C. It replaces the need for access control

D. It is only relevant to hardware manufacturing

Correct Answer: B. It inventories software components and dependencies

Question 7

Which activity best tests whether backups can actually support recovery?

A. Checking that a backup job produced a success message

B. Counting the number of backup files

C. Performing a controlled restoration exercise

D. Increasing backup compression

Correct Answer: C. Performing a controlled restoration exercise

Question 8

Why can redundant replicas still fail together?

A. Redundancy always reduces availability

B. They may share a common defect or failure domain

C. Replicas cannot be monitored

D. Replication prevents encryption

Correct Answer: B. They may share a common defect or failure domain

Question 9

Which is a privacy-engineering concern?

A. Collecting and retaining data beyond the stated purpose

B. Using bounded retries for a dependency

C. Separating build agents from production

D. Testing a circuit breaker

Correct Answer: A. Collecting and retaining data beyond the stated purpose

Question 10

What is the primary purpose of graceful degradation?

A. To preserve essential functions when some capabilities fail

B. To eliminate all software defects before release

C. To maximize the number of enabled features during an outage

D. To remove the need for incident response

Correct Answer: A. To preserve essential functions when some capabilities fail