Non-Functional Quality, Reliability and Resilience

Introduction and Context

Software quality is not limited to whether a system produces the correct functional result. A cloud service may calculate an order correctly yet fail because it responds too slowly, becomes unavailable during peak demand, exposes personal data, or cannot recover after a regional outage. Non-functional quality concerns the properties that determine how a system performs, operates, evolves, protects stakeholders, and responds to adverse conditions.

For contemporary systems, these properties are interdependent. A microservice architecture may improve independent deployment but increase network failure modes. Encryption may strengthen confidentiality while introducing latency and key-management obligations. Aggressive autoscaling may improve elasticity but cause instability if scaling decisions react too slowly or oscillate. Consequently, quality assurance must evaluate quality attributes as measurable system behaviours rather than as isolated checklists.

This chapter examines performance, scalability, reliability, availability, usability, accessibility, compatibility, maintainability, safety, security, privacy, and resilience in cloud, mobile, microservice, and distributed systems. It combines quality models, quantitative measures, engineering practices, testing strategies, governance concerns, and an applied case.

Learning Objectives

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

1. Distinguish major non-functional quality attributes and explain their interactions.

2. Define and apply metrics for performance, reliability, availability, scalability, and resilience.

3. Evaluate quality risks in cloud, mobile, microservice, and distributed architectures.

4. Design suitable assurance activities, including load, fault-injection, security, accessibility, and recovery testing.

5. Interpret service-level objectives and make trade-offs using evidence.

6. Assess ethical, privacy, safety, regulatory, and governance implications.

1. Non-Functional Quality as a Systems Property

A quality attribute is a measurable or assessable characteristic of a system. The term “non-functional” is useful for distinguishing quality constraints from business functions, but it can be misleading: these properties are still observable behaviours. For example, “the system shall support 500 requests per second with a 95th-percentile latency below 300 ms” is an externally testable requirement.

A high-quality requirement should identify:

• the quality attribute;
• the stimulus or operating condition;
• the measurable response;
• the threshold or target;
• the measurement method;
• the scope and environment; and
• the consequences of failure.

“Fast” is weakly specified. “For authenticated checkout requests at 500 requests per second, 95% shall complete within 300 ms, excluding third-party payment timeouts, during a 30-minute steady-state test” is substantially more useful.

Quality models such as ISO/IEC 25010 organize quality into characteristics including performance efficiency, compatibility, usability, reliability, security, maintainability, portability, and safety-related concerns in applicable contexts. Models support completeness, but they do not remove the need to select context-specific measures. A medical device, a social-media application, and a batch analytics platform require different quality priorities.

Quality attributes also exhibit trade-offs. Replication can improve availability but create consistency and storage costs. Strong authentication can reduce unauthorized access but increase user friction. Fine-grained microservices can improve change isolation but increase operational complexity. Quality assurance therefore involves optimization under constraints rather than maximizing every attribute independently.

2. Performance and Scalability

2.1 Performance concepts and metrics

Performance describes system behaviour with respect to time and resource use. Important measures include:

• Response time or latency: elapsed time between a request and the corresponding response.
• Throughput: completed operations per unit time, such as requests per second.
• Concurrency: number of operations in progress simultaneously.
• Utilization: proportion of a resource’s capacity being used.
• Saturation: a condition in which additional demand causes disproportionate degradation.
• Tail latency: high-percentile latency, such as the 95th, 99th, or 99.9th percentile.

Average latency can hide serious user impact. If 99% of requests complete in 100 ms but 1% take 10 seconds, the mean is approximately 199 ms, yet one user in one hundred experiences a very slow operation. Percentiles therefore provide a more informative view of service quality. Percentiles must nevertheless be interpreted with sample size, workload composition, and time window; a percentile is not an explanation of causality.

A basic utilization relationship is Little’s Law:

L = λW

where L is the average number of items in a stable system, λ is the average arrival or throughput rate, and W is the average time an item spends in the system. The relationship assumes a stable long-run system and consistent units. For example, if a service processes 200 requests per second and the average response time is 0.25 seconds, the average number of requests in the system is 200 × 0.25 = 50. The result includes requests waiting and being processed. Little’s Law does not by itself predict response time under a new workload.

Amdahl’s Law helps reason about optimization. If fraction p of execution can be improved by a factor s, the overall speedup is:

Speedup = 1 / ((1 − p) + p/s)

The formula assumes the workload and non-optimized portion remain comparable. If 60% of execution is improved by a factor of 4, speedup is 1 / (0.4 + 0.6/4) = 1 / 0.55 ≈ 1.82. Optimizing a component that contributes little to total execution produces limited overall benefit.

2.2 Performance assurance

Performance engineering begins during architecture and requirement analysis, not immediately before release. Activities include workload characterization, capacity modeling, performance budgets, benchmarking, profiling, and production observability.

A workload model should specify request mix, payload size, user behaviour, concurrency, arrival pattern, data volume, cache state, geographic distribution, and dependencies. A test that sends uniform requests to a warm cache may not represent real operation.

Major test types include:

• Load testing: expected demand under defined conditions.
• Stress testing: demand beyond normal capacity to identify failure behaviour.
• Spike testing: abrupt demand changes.
• Soak testing: sustained operation to expose leaks, degradation, or thermal effects.
• Scalability testing: change in capacity as resources or workload increase.
• Capacity testing: determination of the maximum acceptable workload under stated objectives.

Distributed systems require end-to-end measurement. A fast application server may still produce poor user experience if database calls, queues, DNS, TLS negotiation, or third-party services dominate latency. Distributed tracing, correlation identifiers, metrics, and structured logs help locate bottlenecks.

2.3 Scalability and elasticity

Scalability is the ability to handle increasing workload by adding resources or changing system design while maintaining acceptable quality. Vertical scaling increases the capacity of an individual resource; horizontal scaling adds instances. Elasticity is the ability to provision and release resources in response to changing demand.

The ideal linear scaling relationship is rarely achieved. Coordination, serialization, shared databases, network communication, lock contention, cache invalidation, and uneven workload partitioning reduce efficiency. A useful empirical measure is the scalability factor:

E(n) = T(n) / T(1)

where T(n) is throughput with n resource units and T(1) is throughput with one unit, assuming the same workload and measurement conditions. Linear scaling would yield E(n) = n. This is a descriptive metric, not a universal law.

Cloud designs should consider quotas, autoscaling delays, cold starts, noisy neighbours, zonal dependencies, cost limits, and data locality. Autoscaling policies require stabilization and suitable signals. CPU alone may be a poor signal for queue-driven systems; queue depth, request rate, or latency may be more appropriate.

3. Reliability, Availability and Resilience

3.1 Reliability

Reliability is the probability that a system performs required functions without failure for a specified time under specified conditions. It is conditional, not an inherent permanent label. Reliability claims must state workload, environment, duration, and failure definition.

For a constant failure rate λ and an exponential failure-time model, reliability at time t is:

R(t) = e^(−λt)

The model assumes a constant hazard rate and is often inappropriate during early-life defects, wear-out, or changing operational conditions. If λ = 0.001 failures per hour, R(100) = e^(−0.1) ≈ 0.9048. This does not mean every system will fail exactly according to that curve; it is a model-based estimate.

Mean time between failures (MTBF) is commonly used for repairable systems, while mean time to failure (MTTF) is used for non-repairable or first-failure contexts. These terms must not be treated as interchangeable without specifying the operational model. Failure data should include exposure time, severity, detection quality, and repair assumptions.

3.2 Availability

Availability is the proportion of time a service is usable according to an agreed definition. A simple steady-state approximation is:

A = MTBF / (MTBF + MTTR)

where MTTR is mean time to restore or repair. The formula assumes repeated cycles with stable average failure and restoration times and does not fully represent correlated or planned events.

Availability targets are often expressed as “nines.” A 99.9% monthly availability target permits approximately 0.1% downtime. For a 30-day month, the period is 43,200 minutes, so permitted downtime is 43.2 minutes. A 99.99% target permits 4.32 minutes in the same period. The calculation does not state whether partial degradation, maintenance, dependency failures, or failed requests count; those conditions must be defined in the service-level objective (SLO).

An SLO is an internal or contractual target, such as successful requests exceeding 99.9% over a rolling 30-day period. A service-level indicator (SLI) is the measurement, such as successful request ratio. A service-level agreement (SLA) is a formal commitment, potentially including remedies. An error budget is the allowed unreliability implied by the SLO. Error budgets support risk-based release decisions: consuming the budget rapidly may justify slowing feature delivery to improve reliability.

For independent components connected in series, system availability is approximately the product of component availabilities: A_system = A1 × A2 × … × An. Independence is a strong assumption. Shared power, identity systems, networks, databases, or operational teams create common-cause failures and invalidate simplistic multiplication. For redundant parallel components, availability improves only when redundancy, detection, failover, and independence are genuine.

3.3 Resilience

Resilience is the capability to withstand, absorb, adapt to, and recover from adverse conditions while preserving an acceptable level of service. It includes more than uptime. A resilient system may degrade gracefully, isolate faults, restore state correctly, and learn from incidents.

Key concepts include:

• Fault: an underlying defect or abnormal condition.
• Error: an incorrect internal state caused by a fault.
• Failure: externally observable deviation from required service.
• Blast radius: extent of impact from a failure.
• Graceful degradation: maintaining reduced but useful functionality.
• Bulkhead: isolating resources so one workload cannot exhaust all capacity.
• Circuit breaker: temporarily stopping calls to an failing dependency.
• Backpressure: controlling producers when consumers cannot keep up.
• Idempotency: repeated execution having the same intended effect as one execution.
• Recovery point objective (RPO): maximum tolerable data loss measured in time.
• Recovery time objective (RTO): target time to restore service after disruption.

Retries can improve transient-failure handling but can also amplify overload. They should use bounded attempts, exponential backoff, jitter, and clear retry classification. Operations that are not idempotent require careful design, such as idempotency keys or transactional safeguards.

Resilience testing includes dependency failure, packet loss, latency injection, process termination, node failure, zone outage, credential expiry, resource exhaustion, and corrupted or unavailable data. Chaos engineering is a controlled practice of experimenting on a system to test resilience hypotheses. It requires a steady-state definition, limited blast radius, monitoring, abort conditions, and learning review; random disruption without governance is not rigorous chaos engineering.

4. Quality in Distributed, Cloud, Mobile and Microservice Systems

Distributed systems introduce partial failure: one component may fail while others continue. Network communication is slower and less reliable than local calls, clocks may differ, and state may be replicated. The CAP theorem states that when a network partition occurs, a distributed data system cannot simultaneously guarantee both strong consistency and availability in the usual partition-tolerance model. CAP is about partition conditions and does not mean systems simply choose two permanent properties. Real designs make more nuanced decisions involving consistency levels, latency, conflict resolution, and business semantics.

Microservices require explicit contracts, versioning, timeout budgets, service ownership, observability, and dependency mapping. Synchronous call chains multiply latency and failure propagation. Asynchronous messaging can decouple services but introduces delivery duplication, ordering issues, delayed consistency, poison messages, and operational complexity. Consumer-driven contract testing can detect incompatible interface changes without requiring every service combination to be deployed together.

Cloud assurance must address provider dependencies, regions and zones, identity control planes, quotas, managed-service behaviour, tenant isolation, cost runaway, and exit strategies. Infrastructure as code, immutable deployment patterns, automated configuration validation, backup restoration tests, and policy-as-code reduce configuration drift. Multi-region deployment is not automatically resilient: replicated defects, shared identity, DNS problems, data conflicts, and common release pipelines can still create global failure.

Mobile applications operate across variable networks, battery constraints, device capabilities, operating-system versions, permissions, and interrupted execution. Assurance should include offline and intermittent-connectivity behaviour, synchronization conflicts, secure local storage, accessibility settings, screen sizes, and upgrade or rollback paths. Crash-free sessions, startup time, battery impact, and network data consumption are important operational measures.

5. Usability, Accessibility and Compatibility

Usability concerns effectiveness, efficiency, learnability, error tolerance, and satisfaction in a specified context of use. It should be evaluated with representative users and realistic tasks, not inferred solely from developer opinion. Measures can include task completion, time on task, error rate, abandonment, and user-reported workload.

Accessibility ensures that people with diverse sensory, physical, cognitive, and communication abilities can use the system. Relevant practices include semantic structure, keyboard operation, visible focus, sufficient contrast, scalable text, captions, alternatives for non-text content, clear error messages, and compatibility with assistive technologies. Automated accessibility checkers are useful but incomplete; human evaluation and assistive-technology testing remain necessary. Accessibility is both an inclusion obligation and a quality concern that improves robustness for many users.

Compatibility includes interoperability with browsers, operating systems, devices, protocols, data formats, versions, and external services. A compatibility strategy should define a support matrix, prioritise risk-based combinations, test upgrades and backward compatibility, and monitor real-world usage. Containerization can improve environmental consistency but does not remove kernel, network, browser, database, or service-version differences.

6. Maintainability and Evolvability

Maintainability is the ease with which a system can be analyzed, modified, tested, and operated. It is affected by modularity, cohesion, coupling, duplication, code clarity, dependency management, testability, documentation, observability, and deployment automation.

Technical debt is not merely poor code; it is a design or implementation shortcut that creates future cost or risk. Debt can be deliberate and rational if recorded, bounded, and repaid. Architecture fitness functions, static analysis, code review, mutation testing, dependency scanning, and maintainability indicators provide evidence, but no single metric represents maintainability completely.

An evolvable system separates stable domain contracts from replaceable infrastructure, supports backward-compatible interfaces, and uses automated regression tests. Operational maintainability includes runbooks, ownership, alert quality, safe deployment, rollback, and incident learning. A system that is easy to modify but difficult to operate is not fully maintainable.

7. Safety, Security and Privacy

Safety addresses prevention of unacceptable harm arising from system operation, including hazards caused by failures, misuse, or interaction with the physical environment. Safety analysis may use hazard identification, fault-tree analysis, failure-mode and effects analysis, safety cases, independent review, and defense in depth. Safety requirements should address safe states, emergency behaviour, human override, diagnostic coverage, and evidence of assurance.

Security protects confidentiality, integrity, availability, authenticity, and accountability against adversarial threats. Threat modeling identifies assets, trust boundaries, actors, attack paths, and mitigations. Secure development includes least privilege, secure defaults, input validation, dependency and supply-chain control, secrets management, cryptographic key lifecycle management, vulnerability remediation, logging, detection, and incident response.

Security testing includes static and dynamic analysis, penetration testing, fuzzing, configuration assessment, abuse-case testing, and review of authentication and authorization. A test that finds no vulnerability is not proof of security. Risk depends on exploitability, exposure, impact, detectability, and compensating controls.

Privacy concerns appropriate collection, use, disclosure, retention, and deletion of information relating to identifiable or identifiable persons. Privacy by design includes data minimization, purpose limitation, transparency, access and correction mechanisms, retention controls, pseudonymization where appropriate, and protection against re-identification. Consent is not a universal substitute for lawful, fair, and proportionate processing. Governance should consider applicable privacy laws, cross-border transfers, breach notification, data-subject rights, records of processing, and processor responsibilities.

Security, safety, and privacy can conflict. Detailed logging may support accountability but expose personal information. Automated fraud controls may reduce financial harm but unfairly affect particular groups. Decisions should be documented, risk assessed, reviewable, and subject to human oversight where consequences are significant.

8. Verification, Validation and Operational Evidence

Verification asks whether the system was built according to specified requirements; validation asks whether it solves the intended problem in its actual context. Non-functional assurance requires both.

A quality strategy should map each attribute to evidence. Examples include:

• performance requirements to controlled load tests and production telemetry;
• availability objectives to error-budget measurement and incident records;
• recoverability requirements to restore and failover exercises;
• accessibility requirements to automated and expert testing;
• security requirements to threat models, scans, penetration tests, and remediation evidence;
• privacy requirements to data-flow maps, impact assessments, and retention checks;
• maintainability requirements to review, architecture tests, deployment measures, and change-failure analysis.

Production observability should distinguish symptoms from causes. Metrics show trends, logs provide event detail, and traces show request paths. Alerts should be actionable and tied to user or business impact. Synthetic monitoring complements real-user monitoring, while privacy-preserving telemetry is essential.

Safe delivery practices include feature flags, canary releases, blue-green deployment, progressive exposure, automated rollback, database migration compatibility, and post-release verification. These practices reduce release blast radius but do not replace good architecture or testing.

9. Illustrative Case: Resilient Cloud Payments Platform

Background

A fictional online retailer operates a cloud payment platform using mobile and web clients, an API gateway, order, inventory, payment, and notification microservices, and a managed relational database. The business requires high checkout availability and must protect payment and personal data.

Problem

During a promotional event, latency rose sharply. Retries from the order service multiplied calls to the payment provider, the database reached connection limits, and customers received duplicate order confirmations. The platform’s nominal availability target did not capture severe partial degradation. Recovery procedures had been documented but never exercised.

Analysis

Tracing showed a long synchronous call chain. The payment provider occasionally returned slow responses, but the client and services used unbounded retries. There was no idempotency key for payment requests. Inventory and payment state transitions were not clearly separated, and the notification service could not distinguish a repeated event from a new order. A review also found excessive personal data in logs and insufficient testing on low-bandwidth mobile networks.

The team defined SLIs for successful checkout, checkout latency, duplicate-charge rate, and order-confirmation delay. It set an SLO for successful checkout, a separate latency objective, and an explicit maximum duplicate-charge rate. RPO and RTO were established for transactional data. These measures made customer impact visible rather than relying only on host uptime.

Approach and solution

The platform introduced bounded, jittered retries only for classified transient failures; payment requests used idempotency keys. Circuit breakers and bulkheads isolated the payment provider. A queue decoupled notification from checkout, while an outbox pattern ensured that committed order events were published reliably. Consumers became idempotent, and dead-letter handling was added for unprocessable messages.

The team redesigned database connection pools, added queue-depth autoscaling, and tested capacity using a realistic promotional workload. It implemented progressive deployment, distributed tracing, dependency dashboards, and synthetic checkout probes. Recovery exercises included database restoration, zone failure, payment-provider unavailability, and message replay. Logs were minimized and sensitive fields were redacted. Mobile testing covered interrupted connectivity and safe retry behaviour.

Outcome

In subsequent controlled tests, payment-provider latency caused slower checkout but no duplicate charges; notifications were delayed without blocking order creation. The service met its defined availability and latency objectives under expected load and degraded safely during injected dependency failures. The organization also discovered that recovery time depended on access permissions and operational knowledge, leading to improvements in on-call training and access governance.

Learning points

The case demonstrates that reliability is not equivalent to server uptime. Idempotency, dependency isolation, observability, realistic workload models, privacy-aware logging, and exercised recovery procedures are mutually reinforcing. It also illustrates that quality objectives must be expressed in user-visible outcomes and measured across the complete transaction path.

10. Challenges, Limitations and Contemporary Developments

Non-functional measurement is difficult because environments change, failures are correlated, and quality attributes interact. Laboratory tests may not predict production behaviour; production experiments may create risk. Percentiles can be unstable with small samples, availability can conceal degraded functionality, and composite quality scores can obscure critical hazards.

AI-enabled systems introduce additional concerns: variable outputs, model drift, prompt or data leakage, adversarial inputs, explainability, fairness, and uncertain resource consumption. Conventional deterministic test oracles may be insufficient. Assurance may require reference datasets, metamorphic testing, red-teaming, monitoring for distribution shift, human review, and documented limits of use. AI should not be used to make high-impact quality claims without traceable evidence.

Contemporary practice increasingly combines SRE, DevSecOps, software supply-chain security, platform engineering, policy-as-code, observability, and resilience engineering. The central principle remains evidence-based assurance: define acceptable behaviour, measure it under realistic conditions, test adverse conditions deliberately, and learn from operational evidence.

Best-Practice Checklist

1. Express each important quality attribute as a measurable, testable scenario.

2. Prioritize attributes according to stakeholder harm, business value, and regulatory obligations.

3. Measure end-to-end user outcomes, not only component health.

4. Use realistic workload, device, dependency, and failure models.

5. Design for timeout control, idempotency, isolation, graceful degradation, and recovery.

6. Treat security, privacy, accessibility, and safety as lifecycle responsibilities.

7. Define SLIs, SLOs, error budgets, RPO, and RTO before incidents occur.

8. Test backups, failover, rollback, and operational access rather than merely documenting them.

9. Make telemetry actionable and minimize sensitive data.

10. Reassess quality after architectural, dependency, workload, or regulatory change.

Chapter Summary

Non-functional quality describes how a system behaves and remains trustworthy under normal, changing, and adverse conditions. Performance involves latency, throughput, concurrency, utilization, and tail behaviour; scalability concerns capacity growth, while elasticity concerns dynamic resource adjustment. Reliability models failure-free operation, availability measures usable service over time, and resilience addresses resistance, adaptation, graceful degradation, recovery, and learning after disruption.

Cloud and distributed architectures require explicit treatment of partial failure, dependency chains, data consistency, common-cause failures, operational limits, and recovery objectives. Usability, accessibility, compatibility, maintainability, safety, security, and privacy require distinct evidence and governance, although they interact through design trade-offs. Quality assurance is strongest when requirements are measurable, tests reflect real workloads and threats, production telemetry is meaningful, and recovery is exercised. SLOs, SLIs, SLAs, error budgets, RPO, and RTO provide a language for technical and managerial decision-making. Ultimately, quality is a system property demonstrated through evidence rather than asserted through architecture diagrams or isolated test results.

Key Terms

Quality attribute: A measurable or assessable characteristic of a system.

Performance: System behaviour concerning time and resource use.

Tail latency: High-percentile response time experienced by the slowest portion of requests.

Scalability: Ability to handle increased workload while maintaining acceptable quality.

Elasticity: Ability to add or release resources in response to demand.

Reliability: Probability of performing required functions without failure for a specified time and condition.

Availability: Proportion of time a service is usable according to an agreed definition.

Resilience: Capability to withstand, adapt to, and recover from adverse conditions.

MTBF: Mean time between failures for a repairable system.

MTTR: Mean time to restore or repair service.

SLI: Measured indicator of service performance or reliability.

SLO: Target value or range for an SLI.

SLA: Formal service commitment, often with contractual consequences.

Error budget: Permitted unreliability implied by an SLO.

RPO: Maximum tolerable data loss expressed as a time interval.

RTO: Target time for restoring service after disruption.

Idempotency: Property whereby repeating an operation has the same intended effect as performing it once.

Graceful degradation: Continued delivery of reduced but useful functionality during impairment.

Threat modeling: Systematic identification of assets, threats, trust boundaries, and mitigations.

Privacy by design: Integrating privacy protection into system design and lifecycle decisions.

Review Questions

Short Answer Questions

1. Why are percentile latency measures often more useful than average latency?

2. Distinguish reliability from availability.

3. What is the purpose of an error budget?

4. Explain idempotency and its importance in distributed systems.

5. Why is automated accessibility testing insufficient on its own?

Long Answer Questions

1. Explain how performance, scalability, reliability, and resilience interact in a cloud microservice architecture.

2. Discuss the assumptions and limitations of the availability formula A = MTBF/(MTBF + MTTR).

3. Compare load, stress, spike, soak, and capacity testing, giving an appropriate use for each.

4. Explain how safety, security, and privacy differ and where their assurance activities overlap.

5. Design a non-functional quality strategy for a mobile banking system, including metrics and evidence.

Analytical / Application Questions

1. A service receives 400 requests per second and has an average response time of 150 ms. Use Little’s Law to estimate the average number of requests in the system. State the assumptions.

2. A service has MTBF of 999 hours and MTTR of 1 hour. Estimate steady-state availability using the stated availability model, and explain why the estimate may not represent correlated cloud failures.

3. Design a failure experiment for a checkout microservice that tests graceful degradation without causing uncontrolled customer impact. Specify the hypothesis, fault injection, metrics, safeguards, and expected learning.

Multiple Choice Questions with Answers

Question 1

A service processes 200 requests per second with an average response time of 0.25 seconds. According to Little’s Law, what is the average number of requests in the system?

A. 50

B. 80

C. 200

D. 800

Correct Answer: A. 50

Question 2

Which metric is most useful for revealing poor experience affecting the slowest fraction of users?

A. Average CPU utilization

B. 99th-percentile latency

C. Total source-code lines

D. Mean payload size

Correct Answer: B. 99th-percentile latency

Question 3

An SLO is best described as:

A. A measured observation of service behaviour

B. A formal contract with mandatory compensation

C. A target for a service-level indicator

D. A disaster-recovery backup

Correct Answer: C. A target for a service-level indicator

Question 4

Which practice most directly prevents duplicate effects when a distributed operation is retried?

A. Increasing log verbosity

B. Using idempotency keys

C. Removing timeouts

D. Disabling monitoring

Correct Answer: B. Using idempotency keys

Question 5

For a constant failure rate model, reliability at time t is represented by:

A. R(t) = 1 − λt for all t

B. R(t) = λ/t

C. R(t) = e^(−λt)

D. R(t) = MTTR/MTBF

Correct Answer: C. R(t) = e^(−λt)

Question 6

A 99.9% availability target over a 30-day month permits approximately how much downtime?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 1,440 minutes

Correct Answer: B. 43.2 minutes

Question 7

Which condition is a characteristic challenge of distributed systems?

A. Partial failure of components

B. Guaranteed zero network latency

C. Absence of independent components

D. Automatic global consistency

Correct Answer: A. Partial failure of components

Question 8

What is the primary purpose of a circuit breaker?

A. To compress database records

B. To prevent calls to a failing dependency from causing cascading damage

C. To replace all authentication mechanisms

D. To guarantee zero packet loss

Correct Answer: B. To prevent calls to a failing dependency from causing cascading damage

Question 9

Which statement about accessibility assurance is correct?

A. Automated checkers completely replace user testing

B. Accessibility applies only to mobile applications

C. Assistive-technology and human evaluation complement automated checks

D. Accessibility is unrelated to usability

Correct Answer: C. Assistive-technology and human evaluation complement automated checks

Question 10

Which objective specifies the maximum tolerable data loss after a disruption?

A. RTO

B. RPO

C. MTTR

D. SLO

Correct Answer: B. RPO