12. Security, Safety, Compliance and Ethical Reliability

Introduction: Reliability as a Socio-Technical Responsibility

Site Reliability Engineering is often introduced through availability, latency, capacity, and incident response. Those measures are essential, but they do not fully define a reliable service. A system that is available yet exposes personal data, permits unauthorized access, discriminates against users, or places operators under unsafe working conditions cannot be regarded as reliably engineered. Reliability therefore includes the dependable preservation of security, safety, privacy, lawful operation, and human well-being.

This broader view is especially important in distributed and highly automated environments. A deployment pipeline may release software globally within minutes; a machine-learning system may make decisions affecting access to financial or health services; and an on-call engineer may be expected to respond to incidents across several time zones. In each case, technical performance is connected to organizational governance and ethical judgment.

Security reliability concerns the consistent protection of confidentiality, integrity, and availability. Safety reliability concerns preventing systems from causing unacceptable harm to people, property, or the environment. Compliance reliability concerns meeting legal, contractual, regulatory, and internal obligations in a repeatable and auditable manner. Ethical reliability concerns making responsible decisions when objectives conflict, evidence is incomplete, or the consequences fall unevenly on different groups.

The central argument of this chapter is that security, safety, compliance, and ethics should not be treated as reviews performed after engineering work is complete. They must be designed into architecture, delivery, operations, incident management, and organizational decision-making.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain how security, safety, compliance, privacy, and ethics extend the meaning of service reliability.

2. Apply zero-trust principles to service architecture and operational practice.

3. Design controls for software supply-chain security, secrets, identity, data, and third-party dependencies.

4. Distinguish safety risks from conventional availability and security risks.

5. Integrate compliance obligations into automated operational evidence and control processes.

6. Evaluate responsible disclosure, customer impact, transparency, and equitable on-call practices.

7. Analyse ethical trade-offs in automation, incident response, and reliability investment.

8. Recommend governance and engineering practices for trustworthy digital services.

Reliability Beyond Uptime

Traditional service-level indicators such as availability and latency measure whether a service performs its intended function. Security and safety introduce additional dimensions. A service may have excellent uptime while an attacker modifies transaction records. A monitoring system may detect every outage but expose sensitive customer information in its logs. A failover mechanism may preserve availability while causing unsafe physical actions in an industrial environment.

A useful model is to treat reliability as a set of interdependent properties:

• Availability: the service is accessible when required.
• Integrity: systems, code, configurations, and data remain accurate and unaltered except through authorized actions.
• Confidentiality: information is disclosed only to authorized parties.
• Resilience: the organization can withstand, recover from, and learn from disruption.
• Safety: reasonably foreseeable operation does not create unacceptable risk of harm.
• Accountability: decisions and actions can be traced to responsible people, systems, and controls.
• Fairness and respect: service operation does not impose unjustified or hidden burdens on users or workers.

These properties can conflict. Strong authentication may increase friction and reduce accessibility if poorly designed. Aggressive rate limiting may prevent abuse but block legitimate users. A rapid emergency change may restore service while bypassing a compliance control. Ethical reliability requires the organization to recognize these tensions rather than pretending that one metric captures the whole system.

Important Concepts and Terminology

Security reliability is the ability of a service to preserve confidentiality, integrity, and availability under normal operation, failure, and attack. Zero trust is an architectural and operational approach that assumes no implicit trust based solely on network location or previous authentication. Least privilege limits users, services, and processes to the permissions necessary for their tasks. Software supply-chain security addresses risks arising from source code, dependencies, build systems, artifacts, vendors, and deployment infrastructure.

Privacy by design means that privacy protections are incorporated into system design rather than added after implementation. Data minimization limits collection and retention to what is necessary for a legitimate purpose. Safety engineering identifies hazards, estimates risk, and introduces controls to prevent or reduce harm. Compliance evidence is the reliable, reviewable record demonstrating that required controls operated as intended.

An audit trail records relevant actions, actors, timestamps, and outcomes. A vulnerability disclosure is information about a weakness that could affect a system or its users. Responsible disclosure coordinates reporting, remediation, and communication to reduce harm. A blameless post-incident review examines system conditions, decisions, and contributing factors without using humiliation as an investigative method. Blamelessness does not mean absence of accountability; it means that learning is separated from reflexive blame.

An error budget is the acceptable amount of unreliability derived from a service-level objective. In this chapter, the concept can be extended to security and safety: an organization should not spend an availability error budget by knowingly creating unacceptable security or safety risk. Operational technology refers to systems that monitor or control physical processes. Critical service is a service whose failure can produce significant societal, economic, health, or safety consequences.

Zero Trust as an Operating Model

Zero trust is frequently reduced to a slogan, but its practical meaning is disciplined verification and constrained authority. Access decisions should consider identity, device or workload posture, requested resource, context, and risk. Network placement alone is insufficient. A process inside a production network should not automatically trust another process simply because both are internal.

A zero-trust implementation normally combines strong identity, continuous or repeated authorization, segmentation, encryption, device and workload assurance, and detailed telemetry. Human users should authenticate through centrally managed identity systems, preferably with phishing-resistant multifactor authentication for privileged access. Machine identities require equal attention: service accounts, workload identities, certificates, and tokens must have owners, lifetimes, rotation processes, and narrowly defined permissions.

Least privilege should be applied at several levels. A deployment service may be permitted to update one production application but not alter identity policies. An observability platform may read performance metrics but should not automatically read raw customer records. Break-glass access may be necessary during severe incidents, but it should be time-limited, strongly logged, reviewed afterward, and technically difficult to misuse.

Zero trust also changes incident response. When compromise is suspected, the organization should be able to revoke credentials, isolate workloads, rotate secrets, and limit lateral movement without shutting down every service. This requires tested mechanisms rather than policy statements. A control that cannot be exercised during an incident is a weak reliability control.

Securing the Software Supply Chain

Modern services depend on layers of external and internally produced components. Source repositories, build runners, package registries, container images, infrastructure modules, signing systems, and cloud services all represent potential attack paths. A vulnerability in a dependency is only one supply-chain risk; compromised build credentials, malicious code contributions, poisoned artifacts, and unauthorized pipeline changes may be equally serious.

A mature supply-chain program establishes provenance for software artifacts. The organization should know which source revision, dependencies, build environment, and approvals produced a deployed artifact. Version pinning, dependency review, vulnerability scanning, signed commits or artifacts, protected branches, isolated build environments, and controlled promotion between environments reduce tampering opportunities. These controls should be complemented by a process for triaging vulnerabilities according to exploitability, exposure, business impact, and available mitigation.

Automation improves consistency but does not eliminate judgment. A scanner may identify a vulnerable library that is unreachable in the deployed configuration, while a low-severity issue may be dangerous in a public authentication service. Teams should document exceptions, assign owners, define expiration dates, and prevent permanent exemption lists from becoming invisible technical debt.

Third-party risk also belongs within SRE governance. Contracts should address security responsibilities, breach notification, service continuity, data handling, access rights, and exit arrangements. A provider that is essential to recovery but has never been tested under failure conditions creates concentration risk. Important dependencies require alternatives, graceful degradation, cached operation, or a documented decision to accept the risk.

Privacy and Data Reliability

Privacy failures are reliability failures because they damage users, trust, legal standing, and the ability to continue operating. Operational data often contains identifiers, IP addresses, authentication information, payment details, health information, or business secrets. Logs and traces are particularly vulnerable because they are copied into multiple systems and retained by many teams.

Privacy engineering begins with purpose limitation and data minimization. Teams should identify what information is genuinely needed for functionality, security, support, and legal obligations. Sensitive fields should be masked, tokenized, encrypted, or excluded from logs. Access to production data should be exceptional, approved, recorded, and periodically reviewed. Retention schedules should be technically enforced rather than left as informal expectations.

Observability must be designed carefully. High-cardinality telemetry can help diagnose failures, but it can also expose individual behavior. Sampling, aggregation, redaction, access controls, and separate handling of sensitive traces can preserve diagnostic value while reducing exposure. Test environments should use synthetic or de-identified data wherever possible.

Privacy obligations vary by jurisdiction and sector, so organizations must map technical practices to applicable requirements. Reliability engineers do not need to act as legal counsel, but they must know when to involve privacy, legal, security, and risk specialists. A privacy impact assessment is useful when a system introduces new data collection, profiling, monitoring, sharing, or automated decision-making.

Safety Engineering in Digital Operations

Safety is most visible in aviation, healthcare, industrial control, transportation, and energy, but it is relevant to any service whose failure can cause physical or severe social harm. Safety engineering begins with hazard identification rather than with the assumption that all failures are equivalent. A short delay in a media application and an incorrect command to a medical device should not be managed using the same risk model.

Common safety techniques include hazard analysis, fault-tree analysis, failure-mode and effects analysis, safe-state design, redundancy, interlocks, independent monitoring, simulation, and controlled testing. A safe-state design specifies what the system should do when it loses communication, receives invalid data, or detects conflicting commands. Sometimes the safe state is shutdown; in other contexts, continued operation at reduced capability is safer.

Automation must preserve meaningful human oversight where consequences are serious. Human involvement is not automatically protective: an overloaded operator who receives hundreds of poorly prioritized alerts may provide only nominal supervision. Effective oversight requires understandable signals, sufficient response time, authority to intervene, training, and procedures that have been exercised under realistic conditions.

Safety cases should make the argument for why a system is acceptably safe, supported by evidence, assumptions, tests, and identified limitations. They should be updated when architecture, dependencies, operating conditions, or threat assumptions change. In critical systems, reliability engineering and security engineering must cooperate because a cyberattack can become a safety event.

Compliance as an Engineering System

Compliance is often misunderstood as paperwork. In a reliable organization, it is a control system that connects obligations to owners, technical mechanisms, evidence, exceptions, and remediation. Relevant obligations may arise from privacy law, sector regulation, contractual commitments, financial controls, records management, accessibility rules, or internal policy.

The first step is obligation mapping. Each requirement should be translated into a practical control statement. For example, “restrict privileged access” might become centrally managed identities, multifactor authentication, approval workflows, periodic access reviews, and logs retained for a defined period. “Maintain recoverability” might become encrypted backups, separated credentials, recovery objectives, restoration tests, and evidence of test results.

Control automation is valuable when it produces trustworthy evidence. Infrastructure-as-code checks can detect public storage, excessive permissions, or unencrypted resources. Policy-as-code can prevent deployment when required controls are absent. Continuous compliance dashboards can show control status, exceptions, evidence age, and responsible owners. However, automated compliance can create false assurance if the rule is incomplete, the data is stale, or the control is bypassed during emergencies.

An effective governance process distinguishes between a control failure, a documented exception, and an accepted risk. Every exception should state its scope, rationale, compensating controls, owner, approval authority, and expiry or review date. Auditability should be designed into normal workflows, not reconstructed before an external audit.

Responsible Disclosure and Incident Transparency

When a vulnerability is reported, the organization must protect users while investigating and correcting the issue. A responsible disclosure process provides a clear reporting channel, acknowledges receipt, authenticates communications carefully, assigns a technical owner, evaluates severity, develops a remediation plan, and communicates with affected parties when appropriate. Security researchers should not be forced to guess how to report a weakness or threatened merely for raising a good-faith concern.

Disclosure timing involves competing interests. Immediate publication may help defenders but expose unprotected users. Delayed publication may enable remediation but can conceal material risk. Decisions should consider exploitability, evidence of exploitation, affected populations, available mitigations, dependencies, and legal obligations. Communication should be accurate, comprehensible, and proportionate. It should not minimize harm through vague language or exaggerate certainty before investigation is complete.

Incident transparency extends beyond security events. Customers may need to know when service degradation affects financial transactions, data integrity, safety, or contractual service levels. Transparency does not require publishing sensitive attack details or personal information. It requires communicating what happened, what is known, what remains uncertain, what users should do, and what measures are being taken.

Post-incident reviews should examine technical causes and organizational conditions: unsafe defaults, ambiguous ownership, inadequate testing, incentive pressure, missing telemetry, or unrealistic staffing. Accountability may require disciplinary or legal action in cases of misconduct, but routine error analysis should not create fear that suppresses reporting.

Ethical Reliability and Human Work

Reliability decisions allocate risk. Choosing not to fund redundancy may expose customers to outages; choosing aggressive monitoring may expose employees to intrusive surveillance; choosing to automate support may reduce cost while making it difficult for vulnerable users to reach a human. Ethical reliability asks who benefits, who bears the risk, and whether affected people have meaningful alternatives.

On-call practice is a major ethical and operational issue. Continuous disruption, unpredictable escalation, and unequal distribution of night work increase fatigue and error. Equitable on-call design includes realistic staffing, rotation fairness, protected rest, compensation where appropriate, escalation policies, workload measurement, and management attention to recurring alerts. A team should not treat heroism as a capacity plan.

Automation deserves similar scrutiny. An automated remediation system should have bounded authority, clear rollback behavior, audit logs, simulation or canary testing, and a human escalation path for ambiguous situations. Machine-learning systems require monitoring for drift, performance differences across user groups, feedback loops, and inappropriate use of proxy variables. Explainability is not merely a public-relations feature; operators need enough understanding to decide when to override or suspend an automated action.

Ethical decision-making can be structured through questions such as:

1. What harms are reasonably foreseeable?

2. Which users, workers, or communities are disproportionately exposed?

3. What less harmful alternatives exist?

4. Are affected people informed and able to challenge the outcome?

5. Can the decision be reversed, audited, and explained?

6. Is the risk accepted by an authorized person who understands its consequences?

A Practical Governance Framework

Organizations can integrate these concerns through a reliability governance cycle. First, establish service context: users, criticality, data, physical effects, legal obligations, dependencies, and acceptable failure modes. Second, identify threats, hazards, privacy risks, and ethical concerns. Third, define controls and measurable objectives. Fourth, implement controls in architecture and delivery pipelines. Fifth, monitor both service behavior and control effectiveness. Sixth, exercise incident, recovery, disclosure, and communication procedures. Finally, review evidence and adapt the system as assumptions change.

A service risk register can connect each risk to likelihood, impact, affected stakeholders, existing controls, residual risk, owner, and review date. A control catalog can link controls to requirements, automated tests, evidence sources, and escalation paths. Reliability reviews should include security, privacy, safety, legal, customer support, and operations perspectives when the service warrants it.

Useful measures include privileged-access review completion, mean time to revoke compromised credentials, percentage of artifacts with verified provenance, restoration-test success, unresolved high-risk exceptions, sensitive-data leakage in logs, vulnerability remediation time, incident communication timeliness, alert burden per engineer, and distribution of on-call load. Metrics should support learning rather than encourage teams to hide problems. A low incident count may indicate good reliability—or poor detection and reporting.

Illustrative Case Study: The Automated Payment Recovery Service

Background

Northstar Payments, a fictional payment platform, operated a highly available transaction service used by online merchants. To reduce failed transactions, it introduced an automated recovery service that retried requests, switched between payment processors, and adjusted routing based on observed failure rates. The service was deployed through a continuous delivery pipeline and depended on several external libraries and cloud-managed databases.

Situation and Problem

During a regional processor outage, the recovery service began retrying transactions more aggressively than intended. Some transactions were submitted twice, while others were routed to a secondary processor with different fraud-screening behavior. At the same time, diagnostic logs captured partial payment identifiers. The platform remained available, but customers experienced duplicate authorizations, delayed settlement, and uncertainty about which records were correct.

An internal review also found that the deployment identity could modify routing rules and production access policies. The emergency response team considered disabling authentication checks temporarily to speed investigation. On-call engineers had already worked several consecutive nights, and customer support lacked a clear explanation to provide merchants.

Analysis

The event was not simply an availability incident. It involved integrity risk, privacy exposure, supply-chain and access-control weaknesses, customer harm, and unsafe operating conditions. The recovery algorithm had been tested for processor failure but not for duplicate submission semantics. Its error budget had been considered in terms of successful requests, not financial correctness. The broad deployment identity violated least privilege. Logging practices created unnecessary data exposure. Fatigue increased the chance of an unsafe emergency change.

Approach and Strategy

Northstar first paused automated retries for affected transaction types and introduced an idempotency key that had to be preserved across processor changes. It reconciled payment records using independent sources and notified merchants whose transactions required review. The company rotated relevant credentials, reduced the deployment identity’s permissions, and created a time-limited break-glass process rather than disabling authentication.

The engineering team added failure-mode analysis for payment routing, including duplicate authorization, inconsistent processor responses, and delayed settlement. Recovery tests were expanded to include degraded dependencies and partial network failure. Logs were redesigned to use tokenized identifiers and stricter access controls. Software artifacts were signed, dependency versions were pinned, and pipeline changes required separate approval for production identity policies.

Management changed the on-call model by adding a second responder for payment incidents, enforcing rest periods, and routing routine customer communication to a trained support group. A public incident notice described the period of impact, the types of transactions affected, corrective actions, and customer steps without exposing security-sensitive details.

Outcome

The platform restored transaction consistency and completed customer reconciliation. The organization also discovered that its previous availability dashboard had overstated reliability because it counted a transaction as successful when a processor accepted it, even if the final customer record was inconsistent. New indicators measured financial integrity, duplicate rate, reconciliation delay, privacy incidents, and recovery correctness.

Learning Points

The case demonstrates that automation can preserve availability while damaging integrity. It also shows that zero trust, privacy controls, supply-chain assurance, customer communication, and humane staffing are not separate concerns. They jointly determine whether a critical service is worthy of trust.

Challenges, Limitations, and Common Mistakes

One common mistake is control theatre: producing policies, dashboards, or certifications without testing whether controls work under pressure. Another is treating security as a blocking department rather than a shared engineering responsibility. Excessive controls can encourage bypasses, while weak controls create unacceptable exposure. The objective is risk-proportionate control design.

Organizations also struggle with incomplete asset inventories, unclear ownership, legacy systems, dependency opacity, and inconsistent environments. Compliance frameworks may not align neatly with technical architecture. Privacy requirements can conflict with long-term debugging needs. Safety analysis is difficult when failures are rare but severe. Ethical impacts are often invisible in aggregate metrics and require engagement with affected users and workers.

A further danger is automation bias: assuming that an automated decision is objective because it is produced by software. Automation can scale a flawed assumption, conceal responsibility, and make harmful actions occur faster. Human review can also become ceremonial if people lack time, information, or authority. Controls must therefore be evaluated in their actual organizational context.

Current Developments and Emerging Directions

Software supply-chain security is moving toward stronger artifact provenance, signed builds, isolated build environments, dependency transparency, and automated policy enforcement. Confidential computing and improved hardware-backed identity may reduce exposure of data during processing, although they introduce operational complexity. Artificial intelligence is increasingly used for anomaly detection, incident summarization, code generation, and automated remediation. These applications require controls against hallucination, data leakage, insecure generated code, model drift, and excessive autonomous authority.

Regulators and customers are also demanding greater evidence of resilience, privacy protection, cyber risk management, accessibility, and responsible automation. This trend favors organizations that can produce trustworthy operational evidence continuously rather than assemble documents only for audits. The strategic direction is toward measurable digital trust: the ability to demonstrate not only that a service works, but that it works safely, lawfully, securely, and accountably.

Best Practices for Professional Practice

• Define reliability objectives that include integrity, privacy, security, safety, and customer impact where appropriate.
• Use strong identity, least privilege, segmentation, encryption, short-lived credentials, and tested revocation.
• Establish provenance and ownership for source code, dependencies, build systems, artifacts, and vendors.
• Minimize sensitive data in logs and test environments; enforce retention and access rules technically.
• Integrate hazard analysis and safe-state design into critical-service architecture.
• Convert obligations into owned, testable controls with current evidence and time-bounded exceptions.
• Maintain clear vulnerability reporting and incident communication processes.
• Design on-call work around human limits, fairness, recovery time, and sustainable staffing.
• Bound automated actions with approvals, rollback, monitoring, and escalation paths.
• Use post-incident learning to improve systems without suppressing reporting.

Chapter Summary

Reliable service operations protect more than uptime. They preserve confidentiality, integrity, privacy, safety, accountability, and fair treatment of users and workers. Zero trust replaces implicit network trust with explicit identity, context-aware authorization, segmentation, and continuous evidence. Supply-chain controls establish provenance and reduce risks in dependencies, build systems, artifacts, and vendors. Privacy engineering limits collection, exposure, and retention of sensitive information.

Safety engineering identifies hazards and designs safe states, independent controls, meaningful human oversight, and tested recovery for systems whose failures can cause serious harm. Compliance becomes reliable when obligations are translated into owned, automated, reviewable controls rather than isolated paperwork. Responsible disclosure and transparent incident communication protect customers while preserving appropriate confidentiality. Finally, ethical reliability requires attention to unequal impacts, sustainable on-call work, automation limits, and the consequences of managerial choices. The professional SRE must therefore combine technical competence with governance, judgment, and responsibility.

Key Terms

Zero trust: A security model that grants no implicit trust based solely on network location or prior access.

Least privilege: Limiting an identity or process to the permissions necessary for its authorized work.

Security reliability: The dependable preservation of confidentiality, integrity, and availability under failure and attack.

Software supply-chain security: Protection of source code, dependencies, build systems, artifacts, vendors, and delivery pipelines.

Provenance: Verifiable information about how, from which inputs, and under what process a software artifact was produced.

Privacy by design: Incorporating privacy safeguards into system architecture and development from the beginning.

Data minimization: Collecting, processing, and retaining only data necessary for a legitimate purpose.

Safety engineering: Systematic identification and control of hazards that could cause unacceptable harm.

Safe state: A system condition intended to minimize harm when normal operation is impossible or uncertain.

Compliance evidence: Records demonstrating that a required control operated as intended.

Audit trail: A traceable record of relevant actions, actors, timestamps, and outcomes.

Responsible disclosure: Coordinated reporting and remediation of vulnerabilities to reduce harm to users.

Break-glass access: Exceptional, urgent access granted under controlled, logged, and reviewable conditions.

Error budget: The permitted unreliability derived from a service-level objective.

Privacy impact assessment: A structured evaluation of privacy risks associated with a system or change.

Blameless post-incident review: An analysis focused on system conditions and learning rather than reflexive personal blame.

Operational technology: Computing systems that monitor or control physical processes.

Residual risk: Risk that remains after safeguards and mitigations have been applied.

Automation bias: The tendency to over-trust or insufficiently question an automated recommendation or decision.

Review Questions

Short Answer Questions

1. Why is availability alone an inadequate definition of reliability?

2. State four practical principles associated with zero-trust operations.

3. What is the purpose of software artifact provenance?

4. Explain data minimization in an SRE context.

5. Why should on-call design be treated as a reliability concern?

Long Answer Questions

1. Explain how security, privacy, safety, compliance, and ethics interact in the operation of a critical digital service.

2. Describe a practical framework for converting compliance obligations into testable and auditable engineering controls.

3. Discuss the role of hazard analysis, safe-state design, and human oversight in automated systems.

4. Analyse the benefits and limitations of supply-chain security controls in continuous delivery.

5. Explain how responsible disclosure and transparent incident communication can protect both customers and the organization.

Analytical / Application Questions

1. A deployment pipeline can release code globally, but its service account can also change identity policies and read customer logs. Identify the risks and propose a zero-trust redesign.

2. An automated fraud-control system reduces financial loss but rejects legitimate transactions from one customer segment at a higher rate. How should reliability engineers evaluate and govern this system?

3. During a major outage, exhausted engineers propose disabling authentication and retaining raw customer data in logs for faster debugging. Evaluate the proposal and recommend a safer response.

22. Multiple Choice Questions with Answers

Question 1

Which situation most clearly demonstrates that availability alone is not sufficient for reliability?

A. A service responds within its latency target but exposes customer records in logs

B. A service has a temporary increase in CPU utilization

C. A deployment uses automated testing

D. A dashboard displays several service-level indicators

Correct Answer: A. A service responds within its latency target but exposes customer records in logs

Question 2

What is the central operational assumption of zero trust?

A. Internal network traffic is trusted by default

B. No user, device, or workload receives implicit trust based only on location

C. All access should be denied permanently

D. Security depends primarily on perimeter firewalls

Correct Answer: B. No user, device, or workload receives implicit trust based only on location

Question 3

Which control best supports software artifact provenance?

A. Removing version numbers from dependencies

B. Allowing unrestricted production changes during incidents

C. Recording and verifying the source, dependencies, build process, and approvals for an artifact

D. Storing all artifacts without identifying their creators

Correct Answer: C. Recording and verifying the source, dependencies, build process, and approvals for an artifact

Question 4

A production deployment identity can modify application code and identity policies. Which principle is most directly violated?

A. Data minimization

B. Least privilege

C. Safe-state design

D. Responsible disclosure

Correct Answer: B. Least privilege

Question 5

Which practice best reflects privacy by design in observability?

A. Logging all raw customer data permanently

B. Copying production records into every test environment

C. Using tokenization, masking, limited retention, and controlled access for sensitive telemetry

D. Disabling monitoring for systems containing sensitive data

Correct Answer: C. Using tokenization, masking, limited retention, and controlled access for sensitive telemetry

Question 6

What is the principal purpose of a safe-state design?

A. To maximize feature delivery during every failure

B. To specify a condition that minimizes harm when normal operation is impossible or uncertain

C. To eliminate the need for human operators

D. To ensure that every system failure causes shutdown

Correct Answer: B. To specify a condition that minimizes harm when normal operation is impossible or uncertain

Question 7

Which characteristic makes a compliance control reliable?

A. It exists only in a policy document

B. It is owned, testable, supported by current evidence, and reviewed when exceptions occur

C. It is checked only immediately before an external audit

D. It cannot be changed under any circumstances

Correct Answer: B. It is owned, testable, supported by current evidence, and reviewed when exceptions occur

Question 8

An organization receives a vulnerability report from a security researcher. What is the most responsible initial approach?

A. Ignore the report until public disclosure occurs

B. Threaten legal action against the researcher

C. Acknowledge, validate, assess severity, coordinate remediation, and communicate appropriately

D. Publish all technical details immediately

Correct Answer: C. Acknowledge, validate, assess severity, coordinate remediation, and communicate appropriately

Question 9

Why is equitable on-call practice strategically important?

A. It eliminates the need for incident automation

B. It reduces fatigue-related errors and supports sustainable operational reliability

C. It guarantees that incidents will not occur

D. It transfers all responsibility to junior engineers

Correct Answer: B. It reduces fatigue-related errors and supports sustainable operational reliability

Question 10

An automated payment recovery system retries requests and causes duplicate charges. Which reliability dimension is most directly compromised?

A. Integrity

B. Confidentiality only

C. Physical safety only

D. Developer productivity

Correct Answer: A. Integrity