5. Secure Architecture and Design Patterns

Introduction and Context

Secure software is not created merely by removing defects from source code. It is created by making sound decisions about how components are divided, how trust is established, how data moves, and how failures are contained. These decisions belong primarily to architecture and design. A vulnerability discovered during testing may be corrected in code, but a weakness embedded in the architecture—such as unrestricted service-to-service trust or a shared administrative database—can be expensive and sometimes impossible to eliminate without redesign.

Software architecture describes the significant structures of a system, the relationships among its components, and the principles governing their evolution. Secure architecture adds explicit attention to trust boundaries, attack surfaces, data sensitivity, control placement, failure behavior, and operational accountability. Design patterns then provide reusable solutions to recurring security problems. They do not guarantee security; rather, they help architects avoid known classes of error and make security decisions consistent across a system.

This chapter evaluates monolithic, layered, microservice, event-driven, serverless, and distributed architectures. It also examines patterns for authentication, authorization, isolation, input mediation, secrets management, tenancy, resilience, and logging. The central argument is that no architecture is inherently secure. Security depends on the alignment between architectural choices, threat assumptions, organizational capability, regulatory obligations, and the value of the assets being protected.

Learning Objectives

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

1. Explain how architectural structure influences attack surface, trust boundaries, and failure propagation.

2. Compare monolithic, layered, microservice, event-driven, serverless, and distributed architectures from a security perspective.

3. Apply secure design patterns for identity, authorization, input handling, isolation, secrets, tenancy, resilience, and auditability.

4. Identify dangerous anti-patterns, including implicit trust, confused deputy behavior, insecure direct object references, and centralized single points of failure.

5. Evaluate architectural trade-offs using risk, cost, performance, operability, and governance criteria.

6. Design a defensible architecture for a realistic software system and justify its security decisions.

Architecture as a Security Decision

A useful architectural analysis begins with assets, actors, trust boundaries, and abuse cases. Assets include credentials, personal information, payment records, source code, availability, and the integrity of business transactions. Actors may include ordinary users, administrators, internal services, contractors, automated jobs, and attackers. A trust boundary exists wherever data or control moves between parties with different levels of authority. Examples include a browser-to-API boundary, an API-to-database boundary, a service-to-service boundary, and a cloud-provider-to-customer boundary.

Threat modeling makes these relationships explicit. Data-flow diagrams can show processes, data stores, external entities, and flows. STRIDE is often used to consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Attack trees and abuse cases complement this approach by describing how an adversary might achieve a goal. The purpose is not to predict every attack, but to identify design assumptions that require controls.

Security properties should be expressed as architectural requirements. For example, “only an account owner may download an invoice” is an authorization requirement; “a compromised reporting function must not modify payment records” is an isolation requirement; and “all privileged changes must be attributable to an authenticated administrator” is an auditability requirement. These statements are more useful than vague claims that a system must be “secure.”

A recurring principle is secure control placement. A control should operate at the boundary where the relevant decision can be made and should not rely solely on an untrusted caller. Client-side validation may improve usability, but the server must enforce the rule. An API gateway may reject malformed requests, but each service must still validate the data and authorization relevant to its own operation. Defense in depth is therefore not the indiscriminate duplication of controls; it is the deliberate use of independent controls whose failure modes differ.

Architectural Styles and Their Security Consequences

Monolithic Architecture

In a monolith, major business capabilities are deployed as one application unit, commonly sharing a process and often a database. This structure can simplify deployment, testing, transaction management, and local reasoning. Internal calls may be fast and reliable, and fewer network interfaces need to be exposed.

The principal security danger is excessive internal trust. A vulnerability in one module may provide access to functions, memory, configuration, or database tables belonging to another module. If all components run under one operating-system identity and share broad database privileges, compromise of a low-risk feature can become compromise of the entire application. A monolith may also develop into a “big ball of mud” in which security responsibilities are unclear.

A monolith can nevertheless be secure. Strong module boundaries, least-privilege database access, explicit authorization at business-operation boundaries, centralized but carefully governed security libraries, and separation of administrative functions can reduce risk. Modular monoliths are often a sensible choice when a team needs simple operations but still wants bounded domains.

Layered Architecture

Layered architecture separates concerns such as presentation, application services, domain logic, and persistence. Its security value lies in controlled dependency direction and the possibility of placing controls at meaningful layers. Input normalization may occur at an interface layer, business authorization in the domain or application layer, and database access through restricted repositories.

Layers do not automatically create isolation. If the presentation layer can bypass domain authorization and query the database directly, the diagram is secure only on paper. A common mistake is placing all security in a front controller while allowing internal code paths to bypass it. Layering is effective when dependency rules are enforced through interfaces, code review, automated tests, and restricted permissions.

Microservice Architecture

Microservices divide a system into independently deployable services, usually organized around business capabilities. Each service ideally owns its data and exposes a narrow API. This can limit the effect of a compromise and allow different services to use controls appropriate to their risk.

The security cost is substantial. Network calls replace many in-process calls, creating more endpoints, credentials, protocols, and failure modes. Service discovery, container orchestration, message brokers, API gateways, and observability systems become part of the attack surface. Authentication must be established between services, while authorization must determine whether a particular service may perform a particular action on a particular resource. Mutual TLS may authenticate workloads, but it does not by itself establish business permission.

The “shared database microservices” anti-pattern is especially dangerous. It creates the appearance of independent services while allowing one service to bypass another’s rules. A service should normally expose business operations rather than raw tables. Distributed transactions also require careful design; compensating actions, idempotency, and explicit state transitions are often safer than assuming a single atomic transaction across many services.

Event-Driven Architecture

In event-driven systems, producers publish events and consumers react asynchronously. Events can improve scalability, decouple teams, and preserve a history of business facts. They also introduce security questions about who may publish, subscribe, replay, transform, or delete events.

An event should be treated as untrusted input even when produced internally. Consumers must validate schema, issuer, event type, version, and authorization context. Sensitive data should not be placed in events unnecessarily because messages may persist in brokers, backups, caches, and monitoring systems. Replay can cause duplicate payments or repeated privileged actions unless consumers are idempotent and events have suitable identifiers and ordering assumptions.

Event-driven systems also complicate accountability. The original request identity must be carried in a controlled form, while consumers must distinguish the initiating user from the service that performs the action. Logs should connect a business transaction across asynchronous boundaries without exposing credentials or excessive personal data.

Serverless Architecture

Serverless functions reduce infrastructure administration and can provide fine-grained scaling. Their short-lived execution model can limit persistence of some compromises, but it does not remove security responsibility. Function permissions, event triggers, dependency packages, environment configuration, temporary storage, and downstream services all require control.

A function should have only the permissions needed for its specific task. Broad permissions such as unrestricted access to all storage or all database tables turn a small vulnerable function into a powerful attack tool. Event sources must be authenticated or controlled, and function concurrency must be considered in denial-of-service and cost-exhaustion scenarios. Cold-start behavior, third-party dependencies, and provider-managed logs also raise privacy and governance questions.

Distributed Architecture

A distributed system consists of components that coordinate over networks and may fail independently. Its security must account for partial failure, clock differences, retries, duplicate messages, inconsistent views, and degraded dependencies. Availability controls can become integrity problems if fail-open behavior permits unauthorized operations.

The distributed-systems principle that communication is uncertain has direct security implications. Every request needs an explicit timeout, an appropriate retry policy, and a clear failure decision. Retries must not multiply sensitive operations. Time-based authorization, token expiry, and audit ordering should not depend on perfectly synchronized clocks. Strong consistency may be necessary for some security decisions, while eventual consistency may be acceptable for less sensitive views.

Reusable Secure Design Patterns

Strong Authentication and Workload Identity

Authentication establishes who or what is making a request. Modern systems should distinguish human identity, device or application identity, and workload identity. Passwords should be stored using a memory-hard password hashing scheme with unique salts, while stronger authentication factors should be used for privileged or high-impact actions. Sessions and tokens require bounded lifetime, secure storage, audience restriction, issuer validation, and revocation or rotation strategies appropriate to the risk.

For service-to-service communication, workload identity is preferable to shared static passwords. Certificates, short-lived tokens, or platform identity mechanisms can bind credentials to a service and environment. Mutual TLS provides encrypted and mutually authenticated channels, but application-level authorization remains necessary.

Centralized Policy, Distributed Enforcement

Authentication mechanisms can be standardized, but authorization decisions must reflect business context. Role-based access control assigns permissions to roles; attribute-based access control evaluates attributes such as department, resource owner, location, risk, or transaction value. Relationship-based models express relationships such as “user is a member of project” or “clinician is assigned to patient.”

A practical pattern is centralized policy definition with enforcement close to the protected resource. A policy service or policy-as-code repository can improve consistency, while each service enforces the decision before executing its operation. Authorization should be checked on every sensitive request, not only when a user first opens a screen. The object identifier must be bound to the authorization decision, preventing insecure direct object references.

Input Mediation and Canonicalization

Input mediation places a controlled boundary between external data and internal operations. The boundary should validate type, length, range, encoding, structure, and business constraints. Canonicalization must occur before validation where multiple representations could evade a rule. Output encoding must be appropriate to the destination, such as HTML, SQL parameters, shell arguments, or log records.

Allow-lists are generally preferable to attempting to enumerate every malicious input. Parameterized queries, safe serialization libraries, schema validation, and constrained file-processing services reduce the opportunity for injection. Validation at an API gateway is useful for early rejection, but it cannot replace domain validation inside the service.

Isolation and Least Privilege

Isolation limits what a component can access if it is compromised. Operating-system accounts, containers, virtual networks, database schemas, separate encryption keys, and independent deployment accounts are possible mechanisms. Isolation is meaningful only when permissions are genuinely distinct. Running all services with the same cloud role or connecting them with the same database administrator account provides little containment.

Least privilege should apply to users, services, functions, build pipelines, administrators, and monitoring agents. Privileges should be scoped by action, resource, environment, and time where feasible. Just-in-time elevation and approval workflows are useful for high-impact administrative tasks.

Secrets and Key Management

Secrets include passwords, API keys, signing keys, certificates, and database credentials. They should not be embedded in source code, container images, mobile applications, or ordinary configuration files committed to version control. A managed secrets system can provide access control, encryption, auditing, and rotation. Applications should retrieve secrets through an identity-aware mechanism and avoid exposing them in logs, crash reports, command-line arguments, or diagnostic dumps.

Key management must distinguish encryption keys, signing keys, and authentication credentials. Rotation is not a complete strategy unless old keys can be retired safely and data or tokens can be reprocessed when necessary. Compromise response should include revocation, replacement, investigation, and verification that dependent systems no longer accept the exposed secret.

Tenant Isolation

Multi-tenant systems serve multiple customers using shared infrastructure. Tenant identity must be derived from a trusted authenticated context, not simply from a client-supplied parameter. Every data query, cache key, object-storage path, event, and authorization decision must preserve tenant context.

Options include separate databases, separate schemas, row-level security, or shared tables with mandatory tenant predicates. Stronger physical separation generally increases cost and operational complexity but may be required for sensitive customers or regulatory reasons. Tests should deliberately attempt cross-tenant access, including through exports, search, analytics, background jobs, and support tools.

Resilience, Safe Failure, and Idempotency

Security and availability are linked. Rate limiting, quotas, circuit breakers, bulkheads, timeouts, queue limits, and graceful degradation can reduce denial-of-service impact. A bulkhead prevents failure in one dependency or tenant from consuming all resources. A circuit breaker stops repeated calls to an unhealthy dependency.

The failure mode must be explicit. Authentication and authorization services should generally fail closed for high-impact actions, although emergency recovery procedures may be needed. Idempotency keys prevent retries from creating duplicate orders, payments, or account changes. State transitions should be validated so that an operation cannot be replayed or applied out of sequence.

Tamper-Evident Logging and Traceability

Logging is a security control when it supports detection, investigation, and accountability. Important records include authentication events, authorization failures, administrative changes, configuration changes, sensitive-data access, key events, and unusual volume or geography. Logs should include time, actor, action, target, outcome, request or trace identifier, and relevant tenant context.

Logs are not automatically trustworthy. Access should be restricted, retention should reflect legal and investigative needs, and important records may require append-only or tamper-evident storage. Sensitive values, tokens, passwords, and unnecessary personal data must not be logged. Distributed tracing should connect synchronous and asynchronous operations while preserving privacy and integrity.

Dangerous Anti-Patterns and Design Trade-offs

The implicit-trust anti-pattern assumes that internal networks, internal services, or authenticated users are safe. Modern systems should use zero-trust reasoning: every request is evaluated according to identity, context, policy, and resource sensitivity. The security-through-obscurity anti-pattern treats hidden endpoints or undocumented parameters as authorization. Obscurity may reduce casual discovery but cannot replace enforcement.

The confused deputy problem occurs when a privileged component uses its authority on behalf of a less-privileged caller without checking that caller’s permission. For example, a document service may be allowed to read every customer file, while accepting any file identifier supplied by a user. Capability restrictions, explicit delegation, and resource-level authorization address this problem.

Other common failures include broad administrator credentials, fail-open authorization, shared secrets, excessive service fragmentation, direct database access, unbounded retries, unauthenticated webhooks, and logging sensitive data. Excessive centralization can create a single point of failure and an attractive target; excessive decentralization can create inconsistent policies and weak operational visibility.

Architectural decisions are trade-offs rather than moral choices. Microservices may improve team autonomy but increase operational complexity. Strong isolation may reduce blast radius but increase cost and latency. Central policy management may improve consistency but create availability and governance concerns. A defensible decision records the assumptions, alternatives, risks, compensating controls, and conditions under which the decision should be revisited.

Applied Case: Designing a Secure Multi-Tenant Learning Platform

Background

Consider an illustrative organization developing a cloud-based learning platform for universities. The platform stores student profiles, course materials, assessment submissions, grades, instructor feedback, and billing information. Universities are tenants, and each tenant has administrators, instructors, students, and support personnel.

Situation and Problem

The initial design uses a single web application, a shared database, administrator credentials embedded in deployment scripts, and a background job that exports grades. The product team proposes moving immediately to many microservices to support future growth. A threat review identifies risks of cross-tenant data exposure, excessive support privileges, grade tampering, insecure exports, and duplicate billing caused by retrying payment requests.

Analysis

A complete microservice migration would increase network boundaries before the organization has mature identity, secrets, observability, and incident-response capabilities. A modular monolith with carefully separated domains is therefore selected as an interim architecture. Billing and grade processing are identified as higher-risk domains requiring stronger controls and distinct operational permissions.

The threat model defines the browser, API, database, export worker, payment provider, and support console as separate trust boundaries. Tenant identity is derived from the authenticated session and never accepted solely from a URL parameter. Authorization policies distinguish tenant administration, teaching, grading, support, and billing roles. Support staff receive time-limited, approved access with audit records.

Approach and Solution

The platform adopts a layered modular design. The API validates request schemas and applies rate limits, while domain services enforce ownership, tenant membership, and workflow rules. Database access uses restricted application identities and mandatory tenant scoping. Sensitive grade changes require an explicit state transition and produce an audit event containing the actor, reason, previous value, and new value without exposing unrelated student data.

Secrets are moved to a managed vault, with separate credentials for development, testing, and production. The export worker receives read-only access to the minimum grade data required and writes encrypted files to tenant-specific storage paths. Export requests use idempotency keys and expire after a short period. Payment operations use an idempotency key supplied to the payment provider and record the resulting transaction state before acknowledging completion.

The organization later introduces a separate notification service and event broker. Events contain identifiers and necessary business facts rather than complete student records. Consumers validate schemas and preserve the originating tenant and transaction identifiers. Centralized logging and tracing support investigation, while log redaction prevents tokens and assessment content from entering the observability platform.

Outcome

The design does not eliminate all risk, but it reduces the most consequential risks without creating unnecessary distributed complexity. The organization gains clear boundaries and can extract selected modules later. Automated tests attempt cross-tenant access, unauthorized grade changes, replayed exports, and duplicate payment submissions. Periodic reviews reassess whether the architecture and controls remain appropriate as scale and regulation change.

Learning Points

The case demonstrates that secure architecture is not synonymous with adopting the newest architectural style. A modular monolith can be more defensible than immature microservices. Tenant context must follow every relevant data path, privileged operations need independent controls and auditability, and idempotency is a security property when retries can change financial or academic records.

Governance, Ethics, and Professional Responsibility

Architecture affects privacy, equality, accountability, and access to essential services. Data minimization should influence event schemas, logs, backups, and analytics. Retention periods should be justified rather than indefinite. Automated authorization or risk scoring should be explainable enough for responsible review, and access decisions should not create unlawful discrimination.

Regulatory requirements may impose obligations concerning personal data protection, payment security, breach notification, records retention, accessibility, and sector-specific confidentiality. Compliance is not equivalent to security, but regulatory analysis helps identify assets, duties, and evidence requirements. Architects should maintain decision records, threat models, control mappings, and residual-risk acceptance by an accountable authority.

Supply-chain governance is also architectural. External libraries, cloud services, identity providers, observability platforms, and managed databases may introduce concentration risk or jurisdictional constraints. Contracts should address security responsibilities, incident notification, data location, availability, deletion, and audit rights.

Current Developments and Professional Practice

Policy-as-code is increasingly used to express authorization, infrastructure constraints, deployment rules, and compliance checks in version-controlled form. Software bills of materials and signed build artifacts improve supply-chain visibility. Workload identity, short-lived credentials, confidential computing, and automated attack-surface discovery are developing areas of practice.

Artificial intelligence can assist threat modeling, code review, anomaly detection, and log analysis, but generated recommendations require human verification. AI systems themselves introduce risks involving prompt injection, sensitive training data, tool misuse, and opaque decisions. Their tools and data sources should be governed with the same least-privilege and audit principles applied to other services.

A mature organization integrates architecture security into the development life cycle. Security requirements are defined before implementation, design reviews examine trust boundaries, automated tests verify authorization and tenancy, deployment pipelines enforce policy, and production telemetry feeds improvements. Security architecture is therefore a continuing practice rather than a one-time diagram.

Best-Practice Checklist

A secure architecture should, at minimum:

• identify assets, actors, trust boundaries, abuse cases, and failure modes;
• enforce authorization at the resource and business-operation level;
• use least privilege for users, services, databases, functions, and pipelines;
• isolate high-risk components and avoid shared administrator credentials;
• validate and canonicalize inputs at appropriate boundaries;
• protect secrets through managed storage, rotation, and redaction;
• preserve tenant context across APIs, queries, caches, events, and jobs;
• design retries, timeouts, idempotency, and failure behavior explicitly;
• produce protected, useful, privacy-conscious audit records; and
• document trade-offs, residual risks, ownership, and review conditions.

Chapter Summary

Secure architecture determines how trust, authority, data, and failure move through a software system. Monoliths can simplify control but may create broad internal trust; layered designs help separate concerns only when boundaries are enforced; microservices improve decomposition but multiply identities and network attack surfaces; event-driven and serverless systems introduce asynchronous, provider, replay, and permission concerns; and distributed systems require explicit treatment of partial failure and consistency.

Reusable patterns provide disciplined responses to recurring risks. Strong identity, resource-level authorization, input mediation, isolation, least privilege, managed secrets, tenant boundaries, resilience controls, idempotency, and tamper-evident logging work together as a system of defenses. Anti-patterns such as implicit trust, confused deputy behavior, shared databases, fail-open authorization, and broad credentials undermine those defenses. The best architecture is not the most fashionable one, but the one whose risks, assumptions, controls, costs, and operational capabilities are understood and governed.

Key Terms

Architecture: The significant structures, relationships, and governing decisions of a software system.

Trust boundary: A point where data or control crosses between different levels of trust or authority.

Threat modeling: A structured process for identifying assets, threats, vulnerabilities, and controls.

Monolith: An application deployed as one primary unit, often sharing process and data resources.

Layered architecture: An architecture that separates responsibilities into ordered layers with controlled dependencies.

Microservice: An independently deployable service organized around a focused business capability.

Event-driven architecture: A style in which components communicate through published events and asynchronous reactions.

Serverless: A cloud execution model in which the provider manages much of the underlying infrastructure and applications run through managed functions or services.

Workload identity: An identity assigned to a software service, function, or workload for authentication and authorization.

Least privilege: Granting only the minimum authority required for a task.

Defense in depth: The use of complementary, independent controls so that one failure does not defeat security.

Input mediation: Controlled validation, normalization, and encoding of external data before use.

Tenant isolation: Controls that prevent one customer or organizational tenant from accessing another tenant’s resources.

Idempotency: A property whereby repeating an operation produces the same intended effect as performing it once.

Bulkhead: A resilience control that limits the resources consumed by one component, dependency, or tenant.

Confused deputy: A situation in which a privileged component misuses its authority for a less-privileged caller.

Policy-as-code: Security or governance rules expressed in machine-readable, version-controlled form.

Tamper-evident logging: Logging designed to make unauthorized alteration detectable.

Review Questions

Short Answer Questions

1. Why is a trust boundary important in architectural threat modeling?

2. Distinguish workload identity from human user authentication.

3. What security problem does idempotency address?

4. Why is tenant identity unsafe when taken only from a client-supplied parameter?

5. Explain the difference between authentication and authorization.

Long Answer Questions

1. Compare the security strengths and weaknesses of a modular monolith and a microservice architecture.

2. Explain how event-driven systems should address replay, sensitive data propagation, and accountability.

3. Discuss the design of a secure secrets-management strategy for a distributed application.

4. Explain how layered architecture can improve security and why layers alone do not guarantee isolation.

5. Describe a complete secure design approach for a multi-tenant application, including authorization, data access, logging, and testing.

Analytical / Application Questions

1. A service uses mutual TLS for all internal calls but allows any authenticated service to read any customer record. Identify the architectural weakness and propose a correction.

2. A payment function retries automatically after a timeout and sometimes charges customers twice. Analyze the failure mode and design an appropriate solution.

3. An organization wants to migrate a poorly governed monolith immediately into twenty microservices. Using the trade-offs in this chapter, recommend a strategy and justify it.

22. Multiple Choice Questions with Answers

Question 1

Which architectural condition most directly increases the blast radius of a compromised module in a monolithic application?

A. The application uses typed interfaces between modules

B. All modules share broad database and operating-system privileges

C. The application applies rate limiting at its external API

D. The application records administrative actions

Correct Answer: B. All modules share broad database and operating-system privileges

Question 2

What is the most accurate security interpretation of mutual TLS between services?

A. It proves that the calling service is authorized to access every resource

B. It encrypts traffic but cannot authenticate either endpoint

C. It can authenticate workloads, but application authorization is still required

D. It eliminates the need for input validation

Correct Answer: C. It can authenticate workloads, but application authorization is still required

Question 3

A tenant identifier is supplied in a URL, and the server queries records using that value without comparing it with the authenticated tenant. What is the primary risk?

A. Cross-tenant data access

B. Excessive password hashing cost

C. Eventual consistency

D. Certificate expiration

Correct Answer: A. Cross-tenant data access

Question 4

Which pattern best prevents a retry from creating two payments for one intended transaction?

A. Using a longer session timeout

B. Adding an idempotency key and storing transaction state

C. Moving the payment function into a browser application

D. Allowing the payment service to fail open

Correct Answer: B. Adding an idempotency key and storing transaction state

Question 5

Why can a shared database undermine a microservice security design?

A. It always prevents independent deployment

B. It requires all services to use event-driven communication

C. A service may bypass another service’s authorization and business rules

D. It makes encryption impossible

Correct Answer: C. A service may bypass another service’s authorization and business rules

Question 6

Which statement best describes centralized policy with distributed enforcement?

A. Only one central server performs every authorization check

B. Policies are governed consistently, while services enforce decisions near protected resources

C. Clients are trusted to enforce all access rules

D. Authorization is performed only during login

Correct Answer: B. Policies are governed consistently, while services enforce decisions near protected resources

Question 7

What is the principal security concern with placing complete student records in persistent event messages?

A. Events cannot be consumed asynchronously

B. Persistent brokers and backups may unnecessarily replicate sensitive data

C. Consumers cannot validate event schemas

D. Events automatically disable tenant isolation

Correct Answer: B. Persistent brokers and backups may unnecessarily replicate sensitive data

Question 8

Which design choice is an example of least privilege for a serverless function?

A. Giving every function administrator access to the entire account

B. Allowing a reporting function read-only access to only the required dataset

C. Embedding a permanent cloud administrator key in the function package

D. Using one shared role for all development and production functions

Correct Answer: B. Allowing a reporting function read-only access to only the required dataset

Question 9

A privileged document service retrieves any file whose identifier is supplied by a user. Which security problem is most closely illustrated?

A. Confused deputy behavior

B. Clock drift

C. Excessive canonicalization

D. Circuit breaking

Correct Answer: A. Confused deputy behavior

Question 10

Which architectural decision most directly supports safe degradation during dependency failure?

A. Unbounded retries with no timeout

B. A circuit breaker combined with bounded timeouts and explicit fail-closed behavior for sensitive actions

C. A shared administrator credential for all dependencies

D. Disabling audit logging during outages

Correct Answer: B. A circuit breaker combined with bounded timeouts and explicit fail-closed behavior for sensitive actions