Governance, Management, and Responsible Delivery

Introduction

Continuous integration and continuous delivery (CI/CD) improve the speed and reliability of software delivery, but automation does not remove the need for governance. A pipeline can deploy an insecure change rapidly, expose personal data, or make an unauthorised production alteration just as efficiently as it can deliver a valuable feature. Responsible delivery therefore combines technical automation with clearly assigned authority, evidence-based controls, ethical judgement, and accountability.

Governance in CI/CD is the system by which an organisation directs, controls, and reviews software delivery. Management translates governance into priorities, resources, risk decisions, and operational responsibilities. Responsible delivery extends both ideas by asking whether a change is lawful, secure, inclusive, sustainable, and appropriate for the people affected by it.

This chapter examines practical controls for certificate-level DevOps practitioners. It focuses on role-based access control, separation of duties, approvals, auditability, compliance, policy as code, documentation, ownership, ethical data handling, accessibility, sustainability, and risk-based release decisions. The central principle is that delivery should be both efficient and defensible: an organisation should be able to explain who made a change, why it was made, what evidence supported it, how risks were assessed, and how harm will be detected and corrected.

Learning Objectives

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

• explain the purpose of governance in CI/CD;
• apply role-based access control and separation of duties;
• design approval and audit-trail practices for delivery pipelines;
• distinguish compliance obligations from useful engineering controls;
• describe how policy as code supports consistent enforcement;
• assign ownership and produce effective delivery documentation;
• identify ethical risks in data use, accessibility, and automated decision-making;
• recognise sustainability considerations in software delivery; and
• make a risk-based release decision using evidence, controls, and residual risk.

1. Governance as an Enabler of Delivery

Governance is sometimes misunderstood as bureaucracy that slows engineering. Effective governance has a different purpose. It establishes boundaries within which teams can work quickly and safely. It answers questions such as:

• Who may change source code, pipeline definitions, environments, and production data?
• What evidence is required before release?
• Which risks can a team accept, and which require escalation?
• How are emergency changes controlled?
• How can an organisation demonstrate compliance after the event?

A mature governance system is proportional. A low-risk documentation change should not require the same process as a database migration affecting financial records. Excessively strict controls encourage workarounds; insufficient controls create avoidable incidents. The objective is controlled flow rather than maximum restriction.

A useful governance model has four connected elements:

1. Direction: policies, objectives, standards, and risk appetite.
2. Control: permissions, approvals, automated checks, and technical safeguards.
3. Evidence: logs, test results, deployment records, decisions, and exceptions.
4. Learning: reviews, incident findings, metrics, and improvement actions.

Governance operates at several levels. Enterprise governance establishes legal, strategic, and risk requirements. Product governance determines acceptable behaviour for a particular service. Delivery governance controls changes, environments, and operational readiness. Technical governance addresses architecture, security, reliability, and maintainability.

Governance should not be confused with a single framework or certification. Frameworks such as ISO 27001, NIST guidance, COBIT, SOC 2 control practices, and sector-specific regulations can provide useful reference points, but an organisation must interpret them in context. A certificate or audit report does not guarantee that every deployment is safe. Compliance is evidence that specified requirements have been addressed; responsible engineering also considers harms and risks not explicitly stated in a regulation.

2. Roles, Responsibilities, and Ownership

CI/CD involves multiple kinds of authority. A person may write code, approve a change, operate a service, manage an account, or own a business outcome. These responsibilities should be explicit rather than inferred from job titles.

Typical roles include:

Ownership means more than being listed in a directory. An owner must have authority, resources, and a realistic obligation to keep the service safe and useful. Each production service should have a named business owner and a technical owner, with deputies or escalation routes. Ownership records should be reviewed because services, teams, and organisational structures change.

A responsibility assignment matrix can clarify work. In a simple RACI model, Responsible identifies who performs an activity, Accountable identifies who owns the result, Consulted identifies those whose expertise is needed, and Informed identifies those who need notification. RACI is useful for identifying gaps, but it should not be used to assign accountability to a person who lacks decision rights.

3. Role-Based Access Control and Least Privilege

Role-based access control (RBAC) grants permissions to roles and assigns users or service identities to those roles. Instead of granting an individual a collection of unrelated permissions, an organisation defines roles such as developer, release approver, production operator, and auditor.

The principle of least privilege states that an identity should receive only the access necessary for its current responsibilities. Access should be limited by scope, action, resource, and time where practical. For example, a deployment identity might be allowed to update one service in one production cluster, but not to read customer records or modify identity-management settings.

Important RBAC practices include:

• use individual accounts rather than shared human accounts;
• require strong authentication, especially for privileged access;
• separate human identities from service identities;
• grant permissions through managed roles rather than ad hoc exceptions;
• use temporary or just-in-time privilege for exceptional work;
• review access regularly and after role changes;
• remove access promptly when employment or assignment ends; and
• protect credentials in a secrets manager rather than source code or pipeline logs.

RBAC can become unsafe when roles are too broad, permissions accumulate, or membership is never reviewed. A role called “administrator” may be convenient but makes it difficult to prove necessity and separation. Access reviews should ask whether each permission is still required, not merely whether the account is still active.

A related concept is attribute-based access control, in which decisions also depend on attributes such as environment, data classification, location, device posture, or time. RBAC is often easier to understand and administer, while attribute-based rules can provide finer control. The two approaches can be combined.

4. Separation of Duties and Approval Design

Separation of duties reduces the possibility that one person can introduce and conceal an unauthorised or harmful change. In CI/CD, this does not mean that every deployment requires a committee. It means that high-impact activities should have an appropriate independent check.

A common control is to separate code authoring from production approval. A developer may create a pull request and provide evidence, while another qualified person reviews it. For particularly sensitive systems, the service owner or security specialist may approve deployment after reviewing risk and test evidence.

Controls should distinguish independence from mere duplication. Two approvals from people who share the same unchecked assumptions may provide little additional assurance. Independence can involve different responsibilities, teams, or expertise, depending on the risk.

Approval gates should be meaningful. An approver should be able to see:

• the change description and affected components;
• test, security-scan, and quality results;
• deployment and rollback plans;
• known limitations and unresolved defects;
• data, privacy, and accessibility impacts;
• monitoring and support readiness; and
• the identity and timing of earlier approvals.

A manual approval is weak if it is only a button that confirms a deployment without presenting evidence. Conversely, fully automatic deployment can be appropriate for low-risk changes when automated controls are strong and the service has effective monitoring and rollback capability.

Emergency changes require a distinct process. An emergency may justify expedited approval, but it should not eliminate logging, authorisation, testing appropriate to the circumstances, or retrospective review. The record should state why normal controls were bypassed, who authorised the decision, what temporary risks were accepted, and what follow-up action is required.

5. Audit Trails and Evidence

An audit trail is a chronological record that supports reconstruction of an activity. In delivery, it should answer who, what, when, where, why, and with what result. Relevant evidence may include:

• source-control commits and pull-request discussions;
• pipeline execution records;
• identity and access events;
• test and scan reports;
• approval decisions;
• deployment identifiers and environment details;
• configuration changes;
• incident and rollback records; and
• exception and risk-acceptance records.

Logs are useful only when they are trustworthy and usable. They should have reliable timestamps, controlled access, appropriate retention, and protection against unauthorised alteration. Clock synchronisation supports correlation between systems. Sensitive values, such as passwords, access tokens, and unnecessary personal data, must not be written to logs.

Auditability is not the same as surveillance. Organisations should collect evidence proportionately and explain how it will be used. Excessive collection of employee activity can create privacy and trust concerns without improving control effectiveness.

Evidence should be linked to a specific release or change identifier. This enables an investigator to move from a production deployment to the relevant commit, review, pipeline run, test evidence, approval, and rollback decision. Immutable or tamper-evident storage can strengthen confidence, but it does not correct inaccurate or incomplete records.

6. Compliance Controls and Policy as Code

Compliance requirements may arise from legislation, contracts, industry standards, internal policies, or customer commitments. A practical control translates a requirement into an observable condition. For example, a policy may require that production deployments originate from a protected branch, use approved artefacts, and retain approval evidence.

Controls are commonly classified as:

• Preventive: stop an unauthorised action, such as denying deployment from an unprotected branch;
• Detective: identify a condition, such as scanning for exposed secrets;
• Corrective: restore or remediate, such as automatically revoking a leaked credential; and
• Directive: guide behaviour, such as documented secure-development standards.

Policy as code expresses selected policies in machine-readable rules that can be evaluated consistently. Examples include rules requiring encrypted storage, approved container images, mandatory metadata, or restricted network exposure. Policy checks may run during pull requests, image creation, infrastructure planning, deployment, or continuous monitoring.

Policy as code offers consistency, repeatability, rapid feedback, and a versioned history of policy changes. However, it has limitations. A rule can be technically correct but conceptually incomplete. A system may pass a configuration check while still creating unfair outcomes, exposing sensitive inferences, or failing under real operational conditions. Policies must therefore be reviewed by people with relevant technical, legal, privacy, security, and domain expertise.

Good policy-as-code practice includes:

1. state the policy purpose and owner;
2. define the scope and exceptions;
3. implement a testable rule;
4. test both compliant and non-compliant examples;
5. choose whether violations warn, block, or escalate;
6. version and review policy changes;
7. monitor false positives and false negatives; and
8. document the process for temporary exceptions.

A “fail open” approach may allow delivery when a policy service is unavailable; a “fail closed” approach may block delivery. The choice should reflect risk. Blocking every release because a low-risk metadata service is temporarily unavailable can encourage bypassing the control, while failing open for a critical security requirement may be unacceptable.

7. Documentation and Traceability

Documentation is an operational control, not merely an administrative output. Useful documentation helps people understand system purpose, dependencies, constraints, recovery actions, and decision history.

A service should normally have:

• a concise service description and owner;
• architecture and dependency information;
• data-flow and data-classification records;
• deployment and rollback procedures;
• configuration and secret-management guidance;
• monitoring, alerting, and support information;
• known risks, limitations, and technical debt;
• accessibility and user-impact considerations; and
• links to relevant policies, tests, and approvals.

Documentation should be maintained close to the system where possible, such as in version control, while sensitive operational details should be protected. “Documentation as code” enables review, change history, and automated validation. Yet not all information can be safely automated: judgement, rationale, and stakeholder impact often require human explanation.

Traceability connects requirements to implementation and evidence. A requirement may link to a work item, code change, test, approval, deployment, and monitoring outcome. Traceability is especially important for regulated features, safety-sensitive functions, and changes affecting personal or financial data.

8. Ethical Data Handling and Responsible Automation

Responsible delivery requires attention to people affected by software, including people who are not direct customers. Data should be collected and used for legitimate, clearly explained purposes. Teams should minimise collection, restrict access, define retention, and securely dispose of data when it is no longer needed.

Important data-handling principles include:

• Purpose limitation: use data for specified legitimate purposes.
• Data minimisation: collect only what is reasonably necessary.
• Accuracy: provide methods to correct important errors.
• Security: protect confidentiality, integrity, and availability.
• Transparency: explain relevant processing in understandable language.
• Accountability: assign responsibility and retain evidence of decisions.

Non-production environments create particular risks. Production data should not be copied into development or test environments merely because it is convenient. Synthetic or properly de-identified data is preferable. De-identification is not automatically irreversible; combinations of apparently harmless fields may permit re-identification.

Automated systems can reproduce historical bias, use unsuitable proxies, or make decisions that people cannot challenge. A CI/CD process should therefore consider dataset provenance, representativeness, model or rule limitations, human oversight, explainability appropriate to the context, and monitoring for harmful outcomes. AI-generated code and configuration require review because generated output may contain insecure patterns, licensing concerns, fabricated dependencies, or hidden data exposure.

Ethical review should be proportionate but real. A feature that changes the colour of a dashboard has different social risks from a system that ranks applicants, denies benefits, monitors workers, or recommends medical action. Risk assessments should consider affected groups, foreseeable misuse, power imbalances, and available remedies.

9. Accessibility and Inclusive Delivery

Accessibility means that people with different abilities can perceive, operate, understand, and interact with a service. It should be considered during design, implementation, testing, and release rather than treated as a final cosmetic check.

Teams should consider keyboard operation, screen-reader compatibility, meaningful labels, colour contrast, captions, readable language, error recovery, timing, focus order, and responsive behaviour. Automated accessibility tools can identify some issues, but they cannot replace testing with assistive technologies and users with varied needs.

Accessibility acceptance criteria should be included in work items and release evidence. Breaking an essential keyboard path or removing an accessible label may be a high-priority regression even if functional tests pass. Accessibility also includes internal delivery tools: inaccessible dashboards, approval systems, or incident platforms can prevent colleagues from participating effectively in governance.

Inclusive delivery is broader than compliance with a checklist. Teams should engage representative users, avoid assumptions about ability and context, and provide alternative ways to complete important tasks.

10. Sustainability in CI/CD

Software delivery has environmental and organisational costs. Builds, tests, container registries, cloud environments, data transfer, and always-on resources consume energy and infrastructure. Sustainability does not mean avoiding testing or reliability work; it means achieving necessary assurance efficiently.

Practical measures include:

• remove unused environments and storage;
• schedule non-production resources when they are not needed;
• cache dependencies responsibly to reduce repeated work;
• run targeted tests on every change and broader suites at appropriate stages;
• use efficient build images and avoid unnecessary data transfer;
• measure build duration and resource consumption;
• select infrastructure with suitable efficiency and transparency; and
• design software to reduce unnecessary computation and retention.

Sustainability includes social and economic dimensions. A fragile pipeline that requires frequent manual intervention consumes staff time and increases burnout. A costly platform may be technically impressive but unsuitable for an organisation’s resources. Sustainable governance considers lifecycle cost, maintainability, supplier dependency, and skills availability.

Metrics should be interpreted carefully. A shorter build is not automatically better if it removes essential assurance. The relevant question is whether the pipeline provides adequate risk control for the resources consumed.

11. Risk-Based Release Decisions

A release decision should consider evidence, impact, uncertainty, and available controls. Risk is often described conceptually as a combination of the likelihood of an adverse event and its consequence. This expression is useful for reasoning, but it is not a universally precise calculation. Ratings such as low, medium, and high depend on defined criteria and organisational context.

A practical release assessment asks:

1. What is changing, and which users, data, and dependencies are affected?
2. What could go wrong, including security, privacy, accessibility, reliability, and ethical harms?
3. How severe would the consequences be?
4. What evidence shows that the change works as intended?
5. What controls reduce the likelihood or impact of failure?
6. How detectable and reversible is a failure?
7. Who has authority to accept the remaining risk?

Risk is reduced by controls such as testing, staged rollout, feature flags, backups, rate limits, monitoring, peer review, and rollback plans. A control is not equivalent to a guarantee. For example, rollback may be difficult after an irreversible data migration. In such a case, the release plan should include migration validation, backups, forward-fix procedures, and explicit approval.

Progressive delivery exposes a change to a limited audience or traffic percentage before broader release. It can reveal performance, usability, and unexpected behaviour while limiting impact. The decision to expand, pause, or roll back should be based on predefined signals rather than optimism or schedule pressure.

Worked Application: A Risk-Based Release Gate

Suppose a team is releasing a payment-service change. The change affects transaction validation and has a potentially high business impact. Evidence includes successful automated tests, peer review, security scanning, a database backup, a tested rollback procedure, and a staged deployment plan. However, accessibility testing is incomplete and a monitoring alert for declined transactions has not been validated.

A responsible decision is not simply “tests passed.” The unresolved monitoring and accessibility gaps affect the ability to detect harm and ensure equitable use. The release should be paused, or its scope reduced to a controlled test group, until the gaps are addressed or an authorised decision-maker explicitly accepts the residual risk with a time-bound remediation plan. This illustrates that release governance evaluates evidence quality and consequences, not only the number of successful pipeline stages.

12. Illustrative Case: Northstar Benefits Platform

Background

Northstar Services operates an online benefits platform used by employees to select health and financial benefits. The organisation adopts CI/CD to reduce a monthly release cycle to several deployments per week. The platform handles personal and financial information and is used by people with varied digital and accessibility needs.

Problem

An engineering team proposes a rapid release that changes eligibility calculations and introduces a new deployment pipeline. The initial design gives developers production administrator access, copies production records into a test environment, and relies on an informal message from a manager as approval. Pipeline logs contain request payloads, including personal data. No service owner is recorded, and there is no documented rollback procedure.

Analysis

The delivery process has multiple governance weaknesses. Broad access violates least privilege and makes separation of duties difficult. Production data in testing creates privacy and security exposure. Informal approval is difficult to verify later. Logging personal data increases the consequences of log compromise and complicates retention. The lack of ownership and rollback preparation means that technical and business decisions are disconnected.

The eligibility change also presents ethical and accessibility concerns. A calculation error could deny a benefit. A form change could make the service unusable with a screen reader. A fast pipeline does not compensate for these risks.

Approach and Solution

Northstar assigns a product owner and technical service owner. Developers can submit code and run non-production pipelines, but production deployment requires a separate release role. Privileged access is temporary, individually authenticated, and reviewed. A security adviser is consulted for data and access changes.

The team replaces copied production records with synthetic test data and removes sensitive payloads from logs. Pipeline evidence is linked to the release identifier. Policy checks require approved build artefacts, protected branches, successful tests, and mandatory metadata. The approval screen displays test results, data impact, accessibility evidence, monitoring readiness, and rollback instructions.

The release is first deployed to an internal pilot group using a feature flag. Monitoring checks calculation errors, failed submissions, response time, and support contacts. An accessibility review identifies a missing form label, which is corrected before wider release. The change record documents the decision, evidence, owner, and follow-up review.

Outcome

Northstar achieves frequent delivery without treating speed as the only objective. The organisation can demonstrate who approved the release, what controls were applied, and how personal data was protected. The pilot exposes a usability defect before broad deployment. The process also creates reusable controls for future changes.

Learning Points

• Governance should be designed into the pipeline rather than added after incidents.
• Sensitive data requires protection in development, testing, logging, and retention.
• Approval is meaningful only when the approver receives relevant evidence.
• Ownership must include authority and operational responsibility.
• Progressive delivery and accessibility testing reduce risks that ordinary unit tests may miss.

13. Challenges and Limitations

Governance controls involve trade-offs. Excessive approvals can delay urgent fixes and encourage shadow deployment. Excessive automation can create false confidence when checks measure the wrong thing. Strict separation may be difficult in a small team with limited staff. In such cases, compensating controls might include external review, stronger logging, temporary privilege, pair work, or retrospective independent review.

Risk assessments can also suffer from inconsistent scoring, optimism bias, and pressure to meet deadlines. A numerical risk score may create an appearance of precision without reliable data. Teams should document assumptions and focus on practical questions: what can happen, who is affected, how quickly can harm be detected, and how can the system recover?

Compliance controls may become obsolete as systems change. Policies therefore require owners, review dates, exception management, and feedback from incidents. No framework eliminates the need for professional judgement. Responsible delivery is a continuous organisational capability, not a one-time pipeline configuration.

14. Contemporary Developments and Best Practices

Modern delivery increasingly combines infrastructure as code, policy as code, software supply-chain controls, identity-aware platforms, progressive delivery, and automated evidence collection. Software bills of materials can improve visibility of dependencies. Signed artefacts and provenance records can help establish where software came from and how it was built. Automated compliance evidence can reduce manual audit effort.

These capabilities should be adopted according to risk and organisational maturity. Teams should begin with clear ownership, protected source control, least privilege, reliable testing, useful logs, and documented recovery. Advanced tooling cannot compensate for unclear accountability.

A practical responsible-delivery checklist is:

• Is the change owner identified?
• Are permissions limited and reviewed?
• Is there appropriate independent review?
• Are tests and scans relevant to the change?
• Is sensitive data protected in all environments and logs?
• Are accessibility and user impacts considered?
• Are policy exceptions documented and time-bound?
• Can the change be monitored, paused, and reversed?
• Is the evidence sufficient for an informed decision?
• Has the remaining risk been accepted by an authorised person?

Chapter Summary

Governance, management, and responsible delivery make CI/CD trustworthy and sustainable. Governance provides direction, controls, evidence, and learning. RBAC and least privilege restrict access to what identities need, while separation of duties creates appropriate independent checks. Approval gates should present meaningful evidence, and emergency procedures should remain auditable.

Audit trails connect people, changes, tests, approvals, and deployments. Compliance controls become more consistent when suitable requirements are expressed as policy as code, although human judgement remains essential. Documentation, traceability, and explicit ownership support reliable operations and accountability.

Responsible delivery protects personal data, considers ethical impacts, supports accessibility, and manages environmental and organisational costs. Risk-based decisions evaluate impact, evidence, uncertainty, detectability, reversibility, and authority to accept residual risk. The goal is not to eliminate all risk or prevent rapid delivery; it is to make delivery controlled, explainable, inclusive, and capable of learning from failure.

Key Terms

Audit trail: A chronological record that supports reconstruction of actions and decisions.

Accountability: The obligation and authority to answer for an outcome.

Approval gate: A condition requiring an authorised decision before a delivery stage proceeds.

Attribute-based access control: Access control using identity, resource, environment, or contextual attributes.

Compliance control: A measure designed to satisfy and demonstrate a legal, contractual, regulatory, or internal requirement.

Data minimisation: Collecting and retaining only data reasonably necessary for a legitimate purpose.

Ethical data handling: Responsible collection, use, protection, explanation, and disposal of data.

Exception: An authorised, documented deviation from a policy or standard.

Least privilege: Granting only the access necessary for an identity’s current duties.

Ownership: Clearly assigned responsibility, authority, and operational accountability for a service or outcome.

Policy as code: Machine-readable rules that automatically evaluate technical or delivery conditions.

Progressive delivery: Releasing a change gradually to limit exposure and gather evidence.

RBAC: Role-based access control, in which permissions are assigned to roles and roles to identities.

Residual risk: Risk remaining after controls have been applied.

Responsible delivery: Software delivery that considers security, legality, ethics, inclusion, sustainability, and operational consequences.

Separation of duties: Dividing critical responsibilities so that one person cannot independently perform and conceal a sensitive action.

Service owner: The person accountable for the ongoing technical or business performance of a service.

Synthetic data: Artificially generated data designed for testing without reproducing identifiable production records.

Review Questions

Short Answer Questions

1. What is the purpose of governance in a CI/CD process?
2. Define least privilege and give one pipeline-related example.
3. Why should production data generally not be copied into test environments?
4. What information should an approval gate present to a release approver?
5. What is policy as code, and what is one of its limitations?

Long Answer Questions

1. Explain how RBAC, separation of duties, and audit trails work together to reduce delivery risk.
2. Discuss the difference between compliance and responsible delivery.
3. Describe how an organisation could design an effective emergency-change process.
4. Explain why accessibility and ethical data handling should be included in CI/CD governance.
5. Evaluate the benefits and limitations of progressive delivery for a high-impact service.

Analytical / Application Questions

1. A small team wants every developer to have production administrator access because there is no operations team. Analyse the risks and propose compensating controls.
2. A deployment passes all automated tests but introduces a change to a benefits-calculation algorithm. Monitoring is incomplete and the rollback involves an irreversible data migration. Should the release proceed? Justify your decision.
3. Design a policy-as-code rule for production deployments. State its purpose, scope, blocking conditions, exception process, and evidence that should be retained.

Multiple Choice Questions with Answers

Question 1

Which control most directly supports least privilege in a CI/CD platform?

A. Giving all developers permanent production administrator access

B. Granting a deployment identity only the permissions required for one service

C. Using a shared administrator account for emergency work

D. Allowing permissions to accumulate until an annual audit

Correct Answer: B. Granting a deployment identity only the permissions required for one service

Question 2

What is the main purpose of separation of duties?

A. To ensure that every task is performed by a committee

B. To prevent any individual from introducing and concealing a sensitive change alone

C. To eliminate the need for automated testing

D. To make all deployments occur manually

Correct Answer: B. To prevent any individual from introducing and concealing a sensitive change alone

Question 3

Which item is strongest evidence in an audit trail?

A. An undocumented verbal instruction

B. A deployment record linked to a commit, test results, approval, and release identifier

C. A general statement that the team follows best practice

D. A screenshot with no timestamp or system context

Correct Answer: B. A deployment record linked to a commit, test results, approval, and release identifier

Question 4

Which statement about policy as code is correct?

A. It eliminates the need for human judgement

B. It applies machine-readable rules consistently and can be version controlled

C. It is used only for user-interface design

D. It guarantees that a system is ethically acceptable

Correct Answer: B. It applies machine-readable rules consistently and can be version controlled

Question 5

Which practice best protects personal data in non-production environments?

A. Copying the entire production database into development

B. Including customer records in pipeline logs

C. Using synthetic data or appropriately protected test data

D. Sharing production credentials with testers

Correct Answer: C. Using synthetic data or appropriately protected test data

Question 6

Why is a manual approval gate potentially weak?

A. Manual approvals are always prohibited

B. An approver may confirm a deployment without receiving relevant evidence

C. Approvals cannot be recorded electronically

D. Manual approvals prevent all automation

Correct Answer: B. An approver may confirm a deployment without receiving relevant evidence

Question 7

Which activity is most directly related to accessibility governance?

A. Testing keyboard operation and screen-reader labels

B. Increasing administrator privileges

C. Deleting deployment records

D. Disabling monitoring alerts

Correct Answer: A. Testing keyboard operation and screen-reader labels

Question 8

What is a suitable response when an emergency change bypasses normal approval?

A. Delete the pipeline record after deployment

B. Avoid documenting the change to reduce attention

C. Record the reason, authorisation, risks, and retrospective review

D. Permit all future changes to bypass approval

Correct Answer: C. Record the reason, authorisation, risks, and retrospective review

Question 9

Which release characteristic generally supports a risk-based decision?

A. High impact, poor monitoring, and irreversible rollback

B. Limited exposure, tested rollback, relevant tests, and clear monitoring

C. Unassigned ownership and undocumented exceptions

D. Production data used freely in every test environment

Correct Answer: B. Limited exposure, tested rollback, relevant tests, and clear monitoring

Question 10

Which action can improve sustainability without removing necessary assurance?

A. Disable all tests

B. Remove unused environments and use targeted tests appropriate to change risk

C. Retain every build and environment indefinitely

D. Run every possible test for every documentation change

Correct Answer: B. Remove unused environments and use targeted tests appropriate to change risk