Governance, Ethics and Regulatory Compliance

Introduction

Serverless computing and microservices enable organisations to deliver software rapidly through independently deployable services, managed cloud infrastructure, event-driven execution, and elastic scaling. These advantages do not remove governance responsibilities; they redistribute them. In a traditional data centre, an organisation may control servers, networks, operating systems, and physical facilities directly. In a serverless environment, many of these controls are shared with cloud providers, platform operators, software suppliers, and development teams.

Governance therefore becomes a strategic discipline rather than an administrative afterthought. It determines who owns a service, which rules apply to data and algorithms, how evidence is collected, where information may be processed, how accessibility is assured, and how adverse outcomes are detected and corrected. Compliance is one part of governance: compliance demonstrates conformity with applicable laws, regulations, contracts, standards, and internal policies. Ethics extends beyond minimum legal requirements by asking whether a system is fair, explainable, inclusive, safe, and socially responsible.

This chapter examines governance, ethics, and regulatory compliance in serverless and microservices architectures. It focuses on practical controls that can be embedded into architecture, software delivery pipelines, operational monitoring, and organisational accountability.

Learning Objectives

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

1. Explain why serverless and microservices architectures require explicit governance.
2. Establish architectural standards, service ownership, accountability, and auditability.
3. Analyse data residency, privacy, accessibility, and regulatory obligations.
4. Apply ethical principles to automated cloud services and AI-enabled decisions.
5. Design practical controls for identity, logging, retention, change management, and incident response.
6. Evaluate sustainability, third-party risk, and shared-responsibility limitations.
7. Propose a governance approach for a realistic serverless or microservices system.

1. Governance in Distributed Cloud Systems

Governance is the system by which an organisation directs, controls, and reviews technology decisions. It includes decision rights, policies, standards, risk tolerances, evidence requirements, escalation paths, and oversight mechanisms. Governance is not identical to management. Management operates services and delivers projects; governance determines whether those activities are aligned with organisational objectives, legal obligations, ethical commitments, and acceptable risk.

Microservices intensify governance challenges because a single business capability may be divided into dozens or hundreds of services. Each service may have its own repository, deployment pipeline, data store, runtime configuration, and team. Serverless platforms further abstract infrastructure and often introduce managed queues, functions, workflow engines, API gateways, event buses, and identity services. The resulting system is flexible but difficult to understand as a single object.

A useful governance principle is centralise policy, decentralise delivery. The organisation should centrally define non-negotiable controls—such as encryption, identity assurance, data classification, logging, and regulatory retention—while allowing product teams to choose implementation details within approved boundaries. Excessive centralisation slows delivery; excessive decentralisation creates inconsistent controls and unmanaged risk.

1.1 Governance domains

A mature governance model normally addresses the following domains:

Governance should be proportionate to risk. A public weather-information API and an automated credit-decision service should not receive identical scrutiny. Risk depends on factors such as data sensitivity, scale, reversibility of harm, dependence on automation, criticality of the service, and vulnerability of affected people.

2. Architectural Standards and Decision Rights

Architectural standards convert organisational expectations into repeatable technical practices. They should define approved service patterns, naming conventions, identity mechanisms, network boundaries, event schemas, data classifications, logging requirements, deployment methods, and lifecycle rules.

A standard should be precise enough to guide implementation but flexible enough to accommodate legitimate exceptions. For example, an organisation may require all externally exposed APIs to use centrally managed identity and rate limiting. It may permit an exception for a public, unauthenticated information endpoint, provided that abuse controls and monitoring are documented.

2.1 Reference architecture and guardrails

A governance reference architecture may include:

• an approved cloud account or subscription structure;
• separate development, testing, and production environments;
• central identity and privileged-access management;
• infrastructure-as-code with peer review;
• standard API gateways and event contracts;
• encryption using managed key controls;
• centralised, tamper-resistant audit logging;
• policy-as-code checks in delivery pipelines;
• approved observability and alerting patterns; and
• documented backup, recovery, and decommissioning procedures.

Guardrails are automated constraints that prevent or detect unsafe configurations. Examples include denying deployment when a storage resource is public, rejecting an unencrypted data store, preventing use of an unapproved geographic region, or requiring an owner tag on every deployed resource. Preventive guardrails are valuable, but detective controls remain necessary because policies can be misconfigured, bypassed, or rendered ineffective by changes in provider services.

2.2 Architecture decisions

Important architectural decisions should be recorded in an Architecture Decision Record (ADR). An ADR normally states the context, alternatives considered, decision, consequences, security and compliance implications, owner, and review date. This creates institutional memory and supports auditability. A decision to use an event-driven workflow, for example, should discuss delivery guarantees, duplicate events, ordering, data retention, failure handling, and monitoring—not merely performance.

3. Ownership, Accountability, and the Shared-Responsibility Model

Serverless does not mean responsibility-free. Cloud providers generally secure the underlying facilities, hardware, and managed platform components, while customers remain responsible for configuration, identities, application code, data, permissions, and lawful use. The precise division varies by service and provider, so it must be verified from current contractual and technical documentation.

Ownership should exist at several levels:

• Business owner: accountable for the purpose, value, risk appetite, and acceptable service outcomes.
• Product or service owner: accountable for functionality, prioritisation, availability objectives, and lifecycle decisions.
• Technical owner: accountable for architecture, implementation quality, dependencies, and operational readiness.
• Data owner: accountable for classification, permitted use, retention, accuracy, and sharing.
• Security or privacy adviser: provides specialist challenge and assurance, but does not replace the accountable owner.
• Cloud provider: responsible for the managed platform commitments defined in the service agreement.

A RACI matrix can clarify whether parties are Responsible, Accountable, Consulted, or Informed. However, a matrix is useful only if names, escalation routes, and decision authority are current. “The cloud team” is not an adequate accountable owner.

A service catalogue should record each service’s owner, business purpose, repository, deployment pipeline, data classification, dependencies, region, recovery objectives, regulatory category, support contacts, and retirement status. Ownership must transfer explicitly when staff change roles or teams are reorganised.

4. Auditability and Evidence

Auditability is the ability to reconstruct what happened, who or what caused it, which controls operated, and whether the resulting evidence is trustworthy. It is more than application logging. Effective auditability connects business actions to authenticated identities, service versions, configuration states, data access, and deployment events.

A useful audit event generally includes:

• event time, with a defined time standard;
• authenticated actor or workload identity;
• action and target resource;
• source context, such as application, network, or device;
• result, including success or failure;
• request or correlation identifier;
• relevant policy or transaction reference; and
• software version or configuration where appropriate.

Logs should be protected against unauthorised alteration, access, and premature deletion. Sensitive values should not be copied into logs merely for convenience. Passwords, access tokens, full payment-card numbers, and unnecessary personal information should be excluded or masked.

Audit design involves trade-offs. Retaining every event indefinitely increases cost and privacy risk; retaining too little prevents investigation and may violate legal or contractual requirements. A retention schedule should distinguish operational logs, security logs, financial records, consent evidence, and legal-hold material. Retention must be based on applicable law, business need, contractual commitments, and storage risk—not on an arbitrary universal period.

4.1 Traceability in asynchronous systems

Microservices and event-driven systems make traceability difficult because one user action may create many asynchronous events. Correlation identifiers should be propagated across API calls, queues, functions, workflow steps, and downstream services. Distributed tracing can show causal relationships, while immutable audit records preserve evidence of significant business actions.

Observability data should be governed as potentially sensitive data. Traces may contain URLs, identifiers, payload fragments, or behavioural information. Access to observability platforms should therefore follow least privilege, and sampling or redaction should be designed deliberately.

5. Data Governance, Residency, and Privacy

Data governance addresses the quality, ownership, classification, permitted use, retention, sharing, and lifecycle of information. In serverless architectures, data may move through API gateways, functions, queues, logs, caches, backups, analytics platforms, and provider-operated support systems. A data-flow diagram must include these secondary locations rather than focusing only on the primary database.

5.1 Data classification

A practical classification scheme may include public, internal, confidential, and restricted data. Classification should reflect harm from unauthorised disclosure, alteration, loss, or unavailability. It should also identify personal data, special-category or sensitive data, regulated financial information, health information, intellectual property, and data subject to contractual restrictions.

Controls should be linked to classification. Restricted data may require stronger identity assurance, customer-managed keys, regional processing restrictions, tokenisation, shorter access windows, enhanced monitoring, and approval for secondary use.

5.2 Data residency and sovereignty

Data residency refers to the geographic location where data is stored or processed. Data sovereignty concerns the legal authority and jurisdiction that may apply to data because of its location, provider, corporate structure, or access route. These concepts are related but not identical. A database located in a particular country may still be subject to another jurisdiction’s legal demands through the provider or organisation.

Residency analysis should consider:

1. primary storage;
2. replicas and failover regions;
3. backups and snapshots;
4. logs, metrics, and traces;
5. temporary function storage and caches;
6. support and administrative access;
7. subprocessors and managed SaaS integrations; and
8. model-training or analytics destinations.

Region selection alone is not proof of compliance. Contracts, provider terms, transfer mechanisms, encryption, access controls, and verification evidence must also be considered. Organisations should document an approved-region policy and prevent deployments outside approved locations through automated controls.

5.3 Privacy by design

Privacy by design incorporates privacy into architecture rather than adding it after implementation. Relevant principles include purpose limitation, data minimisation, accuracy, storage limitation, confidentiality, transparency, and accountability. The exact legal obligations depend on jurisdiction and context; this chapter does not replace legal advice.

Practical techniques include:

• collect only attributes necessary for the stated purpose;
• separate identity data from operational data where possible;
• tokenise or pseudonymise identifiers;
• encrypt data in transit and at rest;
• restrict production-data access in development;
• define deletion and correction workflows;
• record consent or another lawful basis where required;
• support access, correction, objection, or deletion requests where applicable; and
• conduct a privacy impact assessment for high-risk processing.

Pseudonymisation reduces exposure but does not necessarily make data anonymous. If a person can be reidentified using additional information, privacy obligations may continue to apply.

6. Regulatory Compliance and Control Mapping

Regulatory compliance should be treated as a control-mapping exercise rather than a collection of disconnected certificates. The organisation should identify obligations, translate them into control objectives, assign owners, implement controls, collect evidence, and review effectiveness.

Common sources of obligation include:

• data-protection and privacy legislation;
• electronic communications and records requirements;
• financial-services and payment rules;
• health and safety or health-information requirements;
• accessibility law;
• consumer-protection and algorithmic accountability rules;
• sector contracts and procurement conditions; and
• internal policies and recognised standards.

Frameworks such as ISO/IEC 27001, ISO/IEC 27701, SOC reporting schemes, NIST guidance, and the CIS Controls can provide useful structures. They do not automatically establish legal compliance. A certification or attestation has a defined scope, period, and set of assumptions; it is not a guarantee that every customer workload is compliant.

A compliance register should identify the requirement, affected service, control, owner, evidence, testing frequency, exception status, and remediation date. Control testing should assess both design and operating effectiveness. A policy that requires quarterly access reviews is not effective if reviews are never completed or if evidence cannot be produced.

6.1 Change and supplier governance

Serverless services can change rapidly through code, configuration, provider updates, dependency changes, and event-schema evolution. Change management should distinguish routine, standard, emergency, and high-risk changes. Automated testing and deployment do not eliminate the need for risk assessment; they make controlled change more repeatable.

Third-party governance should assess cloud providers, libraries, observability platforms, identity providers, payment services, AI APIs, and data processors. Due diligence should cover security controls, subprocessor lists, data locations, service continuity, breach notification, exit provisions, vulnerability handling, and audit rights. Software bills of materials can help identify open-source components and vulnerable dependencies.

7. Ethics and Responsible Automation

Law sets minimum requirements, but ethical responsibility asks whether a service causes unjustified harm even when it is technically legal. Ethical analysis is especially important when automated services rank, classify, approve, deny, monitor, or personalise opportunities for people.

Core ethical principles include:

• Respect for autonomy: people should understand significant decisions and retain meaningful choices where feasible.
• Beneficence: systems should produce legitimate benefits.
• Non-maleficence: foreseeable harm should be prevented or reduced.
• Justice and fairness: benefits, burdens, and error rates should not be distributed unjustly.
• Explicability: affected people and responsible staff should receive understandable reasons.
• Accountability: an identifiable organisation and decision-maker must remain answerable.
• Human dignity: people should not be reduced to opaque scores or treated merely as data objects.

7.1 Bias and discrimination

Bias can enter through historical data, incomplete sampling, labels, proxy variables, measurement errors, model design, thresholds, or operational feedback loops. Removing an explicitly protected attribute does not guarantee fairness because correlated variables may act as proxies.

Evaluation should consider relevant groups and intersectional categories, not only overall accuracy. Metrics must be selected according to the decision context. For example, equal false-positive rates may be important in one setting, while equal opportunity or calibration may be more relevant in another. Fairness metrics can conflict mathematically and ethically; there is no universal metric that resolves every normative question.

Testing should occur before deployment and after changes. Monitoring must examine both model outputs and real-world outcomes. Where harm is material, the system should provide human review, appeal, correction, and rollback mechanisms.

7.2 Explainability and human oversight

Explainability does not necessarily require exposing proprietary source code. It requires meaningful information about purpose, relevant factors, limitations, confidence or uncertainty where appropriate, and routes for challenge. A human-in-the-loop process is not genuine oversight if the human merely approves automated recommendations under time pressure. Oversight requires authority, training, adequate information, and the ability to reject or suspend the system.

7.3 Responsible use of generative AI

Generative AI services may introduce confidentiality, intellectual-property, hallucination, bias, prompt-injection, and data-retention risks. Governance should specify approved use cases, prohibited data, provider terms, human review, output verification, records of important prompts or decisions, and incident escalation. Generated code must undergo normal security and quality review. Automation may accelerate insecure design if teams treat generated output as authoritative.

8. Accessibility and Inclusive Service Design

Accessibility is both a legal and ethical responsibility. A serverless service may be inaccessible through its web interface, mobile application, API documentation, authentication method, notification channel, or automated decision process.

Design should address users with visual, auditory, motor, cognitive, and speech-related disabilities. Practical controls include semantic interfaces, keyboard operation, adequate colour contrast, captions and transcripts, screen-reader compatibility, clear error messages, predictable navigation, accessible multi-factor authentication, and alternatives to time-limited interactions.

Accessibility must be tested with automated tools and people with relevant lived experience. Automated tests identify only some defects. Procurement and supplier contracts should require conformance with applicable standards, such as the Web Content Accessibility Guidelines where relevant, while recognising that conformance claims must be verified in the actual service.

Inclusive design also includes language, connectivity, device capability, age, digital literacy, and economic access. A technically compliant system may still exclude users through excessive bandwidth requirements, complex identity procedures, or inaccessible support channels.

9. Sustainability and Cloud Responsibility

Serverless execution can improve resource utilisation because capacity is provisioned dynamically, but it is not automatically sustainable. High-frequency polling, unnecessary data movement, oversized payloads, duplicate processing, excessive logging, and inefficient functions can increase energy use and cost.

Sustainable design practices include event-driven rather than constant polling approaches, right-sized memory and timeout settings, efficient code, batching where latency permits, lifecycle deletion of unnecessary data, regional placement informed by provider energy information, and measurement of workload utilisation. Sustainability must be balanced against resilience, accessibility, privacy, and performance; a shorter execution time is not the only objective.

An organisation should ask providers for relevant environmental information, but provider estimates may use different boundaries and methods. Therefore, comparisons should state assumptions and avoid false precision. Sustainability governance should consider the complete lifecycle: development, testing, production, storage, network transfer, hardware manufacture, and service retirement.

10. A Governance Lifecycle

Governance is strongest when embedded throughout the service lifecycle:

1. Initiation: identify purpose, stakeholders, risk category, data types, legal context, and accountable owner.
2. Design: create architecture and data-flow diagrams, threat models, privacy and ethical assessments, accessibility requirements, and recovery objectives.
3. Build: use approved templates, secure coding practices, dependency controls, infrastructure-as-code, and peer review.
4. Verify: test security, privacy, resilience, accessibility, performance, fairness, and compliance controls.
5. Deploy: apply policy-as-code, approvals proportionate to risk, release provenance, and rollback capability.
6. Operate: monitor service health, access, anomalies, data use, user complaints, and control effectiveness.
7. Review: conduct access recertification, supplier review, risk reassessment, and internal or external audit.
8. Retire: revoke access, export or delete data according to approved rules, archive required records, and document closure.

This lifecycle is continuous. A change in provider region, event schema, model, data source, or processing purpose can create a new governance obligation even when application code appears unchanged.

11. Illustrative Case: Automated Benefits Eligibility Service

Background

A public agency builds a serverless service to receive applications for a benefits programme. API endpoints invoke functions that validate forms, retrieve records from several microservices, calculate eligibility indicators, and place cases into a review queue. A machine-learning component prioritises cases for staff attention.

Problem

After deployment, community organisations report that applicants using mobile devices and assistive technologies cannot complete the form. Privacy reviewers also discover that detailed applicant information appears in debugging logs. Some rural applicants are repeatedly classified as high-risk because the training data reflects historical service-access patterns. The agency cannot reliably explain why individual cases were prioritised.

Analysis

The service has high social impact, processes sensitive personal data, and influences access to essential support. Its governance category should therefore require stronger privacy, accessibility, auditability, and human-oversight controls than a low-risk information service. The problem is not simply a model-accuracy issue. It involves design, data governance, procurement, operational logging, and accountability.

Approach and solution

The agency establishes a named business owner and a multidisciplinary review group including service designers, privacy specialists, accessibility experts, case workers, security staff, and community representatives. It performs a data-flow and privacy impact assessment, removes unnecessary personal fields from logs, encrypts sensitive stores, and restricts production-data access.

The application is redesigned using accessible form controls, keyboard navigation, plain language, flexible time limits, and alternative assisted channels. Tests combine automated checks with user testing involving people with disabilities and low-connectivity users.

The prioritisation model is limited to triage support and cannot automatically deny benefits. Staff receive reason codes, uncertainty information, and training on model limitations. Applicants can request human reconsideration. The agency evaluates error patterns across relevant groups, monitors drift, records model versions, and suspends the model if thresholds are exceeded.

Deployment pipelines enforce approved regions, mandatory resource tags, encryption, dependency scanning, and log-redaction tests. The service catalogue records owners, data categories, retention rules, dependencies, and incident contacts. A quarterly governance review examines complaints, access failures, fairness indicators, security events, and changes in law or provider arrangements.

Outcome

The revised system improves completion rates, reduces unnecessary exposure of personal data, and gives staff and applicants a clearer route to challenge prioritisation. The model remains a decision-support tool rather than an unaccountable decision-maker. The agency also gains evidence that can be presented to auditors and oversight bodies.

Learning points

1. Governance must be designed around the consequences of the service, not merely its technology.
2. Accessibility and privacy defects often arise in interfaces, logs, and operational tooling rather than core business code.
3. Human oversight requires authority and practical alternatives, not symbolic approval.
4. Fairness monitoring must continue after deployment.
5. Clear ownership and evidence make accountability operational.

12. Challenges and Limitations

Governance can become bureaucratic when every system receives identical approval requirements. Proportionality, reusable templates, automated checks, and risk-based exception paths help avoid this problem. Conversely, excessive reliance on automation can create false assurance: a green pipeline does not prove that a business purpose is lawful or ethical.

Cloud abstraction can obscure dependencies and jurisdictional exposure. Provider documentation may change, managed services may fail in unexpected ways, and contractual assurances may not match technical reality. Multi-cloud strategies can reduce concentration risk but increase complexity, inconsistent controls, and skills requirements.

Ethical evaluation also has limits. Fairness metrics cannot determine what society ought to value, and impact assessments can be superficial if affected communities are not involved. Accessibility conformance does not guarantee usability for every person. Sustainability estimates are often incomplete. These limitations require professional judgement, stakeholder engagement, transparent assumptions, and continuous review.

Best-Practice Checklist

Before approving a serverless or microservices service, verify that:

• a named accountable owner and operational owner exist;
• the service is recorded in a current catalogue;
• data flows, classifications, residency, retention, and deletion are documented;
• applicable legal, contractual, and sector obligations are mapped to controls;
• identity, encryption, secrets, logging, and privileged access are addressed;
• audit events are protected, minimised, and traceable across asynchronous components;
• architecture decisions and exceptions are documented with review dates;
• accessibility is tested with both tools and representative users;
• automated decisions have impact assessment, monitoring, explanation, appeal, and human override;
• provider and subprocessor risks are assessed;
• recovery, incident response, and service exit are tested;
• sustainability impacts are considered; and
• retirement procedures address data, credentials, dependencies, and evidence.

Chapter Summary

Governance in serverless and microservices environments establishes decision rights, standards, ownership, evidence, and risk controls across distributed services. Architectural guardrails, service catalogues, ADRs, policy-as-code, and lifecycle reviews create consistency without eliminating team autonomy. The shared-responsibility model means that cloud providers manage parts of the platform, but customers remain accountable for configuration, code, identities, data, and lawful use.

Auditability requires protected, minimised, and correlated evidence across synchronous and asynchronous components. Data governance must address classification, residency, sovereignty, replicas, backups, logs, subprocessors, retention, and privacy rights. Compliance is best managed by mapping obligations to owned controls and testing their effectiveness rather than relying only on certificates.

Ethical governance extends beyond legal compliance. Fairness, explainability, human oversight, accessibility, dignity, and responsible AI use are essential when automated services affect people. Sustainability requires attention to efficient execution, data movement, storage, and the full service lifecycle. Finally, governance must remain proportionate, evidence-based, inclusive, and continuous because technical, legal, organisational, and social conditions change.

Key Terms

Governance: The system of direction, control, oversight, and accountability used to achieve organisational objectives.

Compliance: Demonstrated conformity with applicable laws, regulations, contracts, standards, and policies.

Shared-responsibility model: A division of security and operational duties between a cloud provider and its customer.

Guardrail: A preventive or detective control that restricts or identifies unsafe actions or configurations.

Architecture Decision Record: A documented record of an important architectural decision, its context, alternatives, and consequences.

Service catalogue: An authoritative inventory of services, owners, dependencies, data, and operational information.

Accountability: The obligation of an identifiable person or organisation to answer for decisions and outcomes.

Auditability: The capability to reconstruct events and demonstrate that controls operated effectively.

Correlation identifier: A value propagated across distributed operations to connect related requests and events.

Data residency: The geographic location in which data is stored or processed.

Data sovereignty: The legal authority and jurisdiction that may apply to data or its processing.

Data minimisation: Collecting and retaining only the information necessary for a legitimate purpose.

Pseudonymisation: Replacing identifying information with substitutes while retaining a possibility of reidentification.

Privacy by design: Integrating privacy protections into system design and lifecycle processes.

Impact assessment: A structured evaluation of potential effects, risks, controls, and affected stakeholders.

Human oversight: Meaningful human authority to understand, challenge, alter, or stop an automated process.

Fairness: The ethical and contextual requirement that systems do not produce unjustifiable discriminatory outcomes.

Accessibility: Designing services so that people with diverse abilities can perceive, operate, understand, and use them.

Policy-as-code: Expressing governance or security rules in machine-evaluable form for automated enforcement or testing.

Sustainability: Managing environmental, social, and economic impacts across a service’s lifecycle.

Review Questions

Short Answer Questions

1. Why does serverless computing redistribute rather than eliminate governance responsibility?
2. What information should a service catalogue contain?
3. Distinguish data residency from data sovereignty.
4. Why should sensitive data be excluded or masked in operational logs?
5. What makes human oversight of an automated service meaningful?

Long Answer Questions

1. Explain how architectural standards and policy-as-code can support decentralised microservices delivery while maintaining organisational control.
2. Discuss the shared-responsibility model and analyse its implications for security, privacy, and compliance in a serverless application.
3. Describe a complete auditability strategy for an event-driven microservices system.
4. Explain how privacy by design, data minimisation, retention, and residency controls should be incorporated into a cloud service lifecycle.
5. Critically evaluate the relationship between legal compliance and ethical responsibility in automated decision systems.

Analytical / Application Questions

1. A serverless application stores customer data in one region, backs it up in another, sends traces to a third-party observability platform, and uses an overseas support team. Develop a data-governance investigation and identify the evidence required before approving the design.
2. A benefits-triage model has equal overall accuracy across two demographic groups but a substantially higher false-negative rate for one group. Analyse why overall accuracy is insufficient and propose governance, technical, and human controls.
3. Design a proportionate governance plan for a microservices platform containing a public catalogue API, an internal payroll service, and an automated loan-assessment service. Explain how ownership, review depth, privacy, accessibility, auditability, and ethical controls should differ among the three services.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the shared-responsibility model in cloud computing?

A. The provider is responsible for every aspect of the customer’s application.

B. The customer is responsible for the physical data-centre hardware.

C. Provider and customer responsibilities are divided according to the service and contract.

D. Responsibility is transferred entirely to the software development team.

Correct Answer: C. Provider and customer responsibilities are divided according to the service and contract.

Question 2

Which control most directly prevents deployment of a storage resource with public access when that configuration is prohibited?

A. A policy-as-code deployment guardrail

B. A quarterly user-satisfaction survey

C. A business continuity presentation

D. A post-retirement archive

Correct Answer: A. A policy-as-code deployment guardrail

Question 3

Why should correlation identifiers be propagated across asynchronous microservices?

A. To increase the physical memory of functions

B. To connect related requests and events for traceability

C. To remove the need for authentication

D. To guarantee that every event is processed exactly once

Correct Answer: B. To connect related requests and events for traceability

Question 4

Which statement about pseudonymisation is correct?

A. It always makes data anonymous and outside privacy regulation.

B. It replaces identifiers while reidentification may remain possible.

C. It prevents all unauthorised access to the original data.

D. It eliminates the need for data-retention rules.

Correct Answer: B. It replaces identifiers while reidentification may remain possible.

Question 5

Which item should normally be considered when assessing data residency?

A. Only the primary database location

B. Only the location of the development team

C. Backups, logs, replicas, subprocessors, and support access

D. Only the location stated in the application name

Correct Answer: C. Backups, logs, replicas, subprocessors, and support access

Question 6

What is the primary purpose of an Architecture Decision Record?

A. To replace all software testing

B. To document the context, decision, alternatives, and consequences of an architectural choice

C. To store confidential customer passwords

D. To guarantee that a provider will never change its service

Correct Answer: B. To document the context, decision, alternatives, and consequences of an architectural choice

Question 7

Which practice best represents meaningful human oversight of an automated decision?

A. Requiring a person to approve every output without time or authority to investigate

B. Allowing authorised staff to understand, challenge, and override the system

C. Hiding the model’s limitations from operators

D. Removing all records of automated recommendations

Correct Answer: B. Allowing authorised staff to understand, challenge, and override the system

Question 8

Why is accessibility testing with real users valuable in addition to automated testing?

A. Automated tools identify every possible accessibility barrier.

B. Real users can reveal practical barriers that automated checks may miss.

C. User testing removes the need for accessibility standards.

D. Accessibility applies only to visual design.

Correct Answer: B. Real users can reveal practical barriers that automated checks may miss.

Question 9

Which approach is most appropriate for compliance management?

A. Rely exclusively on a cloud provider’s certification.

B. Map obligations to owned controls and collect evidence of operating effectiveness.

C. Avoid documenting exceptions to preserve flexibility.

D. Apply identical controls to every service regardless of risk.

Correct Answer: B. Map obligations to owned controls and collect evidence of operating effectiveness.

Question 10

Which design choice can support sustainability in an event-driven serverless system?

A. Continuous polling at the shortest possible interval for every service

B. Unnecessary duplication of large payloads across logs and queues

C. Efficient functions, appropriate batching, and deletion of unnecessary data

D. Indefinite retention of all traces and test data

Correct Answer: C. Efficient functions, appropriate batching, and deletion of unnecessary data