15. AI-Enabled DevOps and Emerging Developments

Introduction and Context

DevOps emerged as a response to the separation between software development and IT operations. Its central promise was not merely faster deployment, but a more reliable flow of value through collaboration, automation, feedback, and shared responsibility. Artificial intelligence is now being added to this environment at several points: it generates code and configuration, detects abnormal behaviour, predicts incidents, recommends remediation, optimises cloud expenditure, evaluates environmental impact, and increasingly participates in delivery decisions.

The term AI-enabled DevOps describes the use of machine learning, generative AI, natural-language interfaces, and intelligent automation to improve software delivery and operation. It does not imply that DevOps becomes fully autonomous. Rather, AI changes how evidence is interpreted, how routine decisions are made, and how human expertise is applied. The resulting opportunity is substantial, but so are the risks. A system that produces code quickly may also reproduce insecure patterns. A predictive model may reduce alert fatigue while hiding a novel failure. An autonomous deployment mechanism may accelerate delivery while amplifying a defective change.

This chapter examines these developments critically. It treats AI as part of a socio-technical system involving people, processes, platforms, data, controls, and organisational incentives. The objective is therefore not to celebrate automation indiscriminately, but to determine where intelligence creates dependable value, where human judgement remains indispensable, and what governance is required for responsible adoption.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the meaning and scope of AIOps and distinguish it from simple monitoring automation.

2. Evaluate generative AI assistants for software development, testing, security, and operations.

3. Apply predictive analytics and intelligent testing to realistic DevOps problems.

4. Analyse FinOps and GreenOps as dimensions of responsible technology delivery.

5. Compare levels of autonomy in continuous delivery and identify suitable human controls.

6. Assess risks involving security, privacy, bias, reliability, intellectual property, and accountability.

7. Propose governance, workforce, and implementation strategies for AI-enabled DevOps.

From Automated Pipelines to Intelligent Delivery Systems

Traditional continuous integration and continuous delivery pipelines execute predefined rules. A commit triggers a build, tests run, an artifact is created, and deployment proceeds when specified conditions are satisfied. This approach is repeatable and auditable, but it is largely deterministic. It does not inherently understand whether a failure is significant, whether a change resembles a previous incident, or whether a deployment is unusually risky.

AI-enabled DevOps adds inference to this pipeline. Models can examine historical deployments, source-code changes, observability data, incident records, dependency graphs, and business indicators. They may classify failures, identify correlations, forecast demand, recommend actions, or generate artefacts. The pipeline consequently becomes more context-aware, although also more dependent on data quality and model behaviour.

A useful distinction is between three levels of automation. Descriptive automation reports what has happened, such as a failed test or elevated latency. Predictive automation estimates what may happen, such as the probability of a deployment causing an incident. Prescriptive automation recommends or executes an action, such as changing capacity or rolling back a release. Each level increases potential value and operational risk. A descriptive alert can be reviewed by an engineer; an autonomous rollback or infrastructure change can affect customers and other systems immediately.

The quality of an AI-enabled system should therefore be assessed through more than model accuracy. Relevant criteria include the timeliness of decisions, false-positive and false-negative costs, explainability, reversibility, auditability, resilience to unusual conditions, and compatibility with organisational controls.

AIOps: Making Sense of Operational Complexity

AIOps refers to the application of artificial intelligence and machine learning to IT operations. It generally combines event management, log analysis, metrics, traces, topology information, incident records, and automation. Its purpose is to reduce the cognitive burden created by large and heterogeneous operational data streams.

A typical AIOps architecture has several layers. Data is collected from applications, infrastructure, networks, cloud services, user-experience monitors, deployment systems, and service-management platforms. A processing layer normalises formats, removes duplicates, enriches events with service and ownership metadata, and establishes time relationships. An intelligence layer performs anomaly detection, event correlation, forecasting, classification, and recommendation. An action layer opens or enriches tickets, notifies responsible teams, changes configuration, initiates remediation, or supplies evidence for human decisions.

Event correlation is one of the most practical AIOps capabilities. A single user-facing outage may generate thousands of symptoms: failed health checks, database timeouts, container restarts, queue growth, and authentication errors. Correlation attempts to group these observations into a probable incident rather than treating every symptom as an independent alert. Topology-aware correlation is stronger than simple time-based grouping because it considers dependencies among services and infrastructure components.

Anomaly detection may use statistical thresholds, seasonality models, clustering, or more complex machine-learning methods. The choice should reflect the operational context. A model trained on stable weekday traffic may perform poorly during a product launch or an unusual public event. For this reason, operations teams should distinguish a statistical anomaly from a confirmed failure. An unusual pattern is evidence for investigation, not automatically proof of causation.

AIOps also supports root-cause analysis, although the term should be used carefully. Most systems rank likely causes using correlations and dependency information; they do not establish causation in the scientific sense. Engineers should be able to inspect the evidence behind a recommendation and test it against system knowledge. A black-box “root cause” that cannot be challenged may increase, rather than reduce, operational risk.

Generative AI Assistants in Development and Operations

Generative AI systems produce text, code, test cases, queries, documentation, infrastructure definitions, and operational explanations in response to prompts or contextual information. In software development, an assistant may explain unfamiliar code, propose an implementation, transform code between languages, generate unit tests, or summarise a pull request. In operations, it may translate a natural-language question into a log query, summarise an incident timeline, draft a runbook, or suggest a safe diagnostic command.

The productivity benefit comes partly from reducing search and composition costs. Engineers can begin with a working hypothesis rather than an empty editor. Yet generated output is probabilistic. It may be syntactically valid but semantically wrong, use obsolete APIs, omit error handling, introduce security weaknesses, or reflect licensing and provenance concerns. The appropriate mental model is therefore “accelerated expert work,” not “automatic correctness.”

A responsible development workflow treats generated code as an untrusted contribution. It should pass the same—or stronger—review, testing, dependency scanning, secret detection, and policy checks as human-written code. Prompts should avoid exposing credentials, personal data, proprietary source code, or confidential incident information to an unapproved service. Organisations should define which models may be used, what data may be submitted, how outputs are logged, and who owns the resulting artefacts.

Operations assistants require additional safeguards because a plausible command can have immediate consequences. Read-only investigation should normally precede modification. High-impact actions should require explicit approval, constrained permissions, dry-run support, and a reliable audit trail. Retrieval-augmented assistants can consult approved runbooks and system documentation, but retrieved content must also be treated as potentially incomplete or outdated. Prompt injection may occur when malicious instructions are embedded in logs, tickets, repositories, or web pages that the assistant reads.

Intelligent Testing and Software Quality

AI can improve testing by selecting tests affected by a code change, generating test cases from requirements, discovering input combinations, clustering failures, predicting defect-prone components, and creating realistic but controlled test data. These techniques are especially useful in large systems where executing every test for every change is expensive.

Test selection models may use dependency graphs, historical failure data, code ownership, and changed files to prioritise relevant suites. This can reduce feedback time, but a model that consistently deprioritises rare integration tests may allow systemic defects to escape. Test optimisation must therefore preserve a periodically executed safety net and monitor escaped defects.

Generative testing can create boundary values and unusual sequences that developers might not anticipate. Property-based testing is particularly valuable because it checks general properties—such as conservation, ordering, or idempotence—across many generated inputs. Fuzzing extends this principle to robustness and security testing. AI-generated tests still require review: a test that merely reproduces the implementation’s assumptions may provide high coverage but little protection.

Mutation testing offers a useful quality signal. Artificial defects are introduced into code, and the test suite is evaluated on whether it detects them. AI-generated tests should be judged by their ability to kill meaningful mutations, not only by line coverage. Quality engineering also requires non-functional testing, including performance, accessibility, resilience, privacy, and security. AI can assist each area, but cannot replace clear acceptance criteria and domain understanding.

Predictive Analytics, Risk Scoring, and Decision Quality

Predictive analytics uses historical and real-time data to estimate future outcomes. In DevOps, applications include deployment-risk scoring, capacity forecasting, incident prediction, build-failure prediction, vulnerability prioritisation, and service-level objective forecasting.

A deployment-risk model might combine the size and location of a code change, service criticality, test results, recent incident history, authorisation patterns, dependency changes, and rollback complexity. Its output should be interpreted as a decision aid. A high-risk score may justify additional review, canary exposure, or a maintenance window; it should not automatically stigmatise a developer or block every release without examining the reasons.

Prediction is affected by data drift. The relationship between indicators and outcomes changes when architecture, teams, traffic patterns, tools, or release practices change. Models require monitoring for calibration, discriminatory effects, deteriorating precision, and changes in the cost of errors. Teams should record not only predictions but also decisions and outcomes, enabling post-deployment evaluation.

A mature organisation combines model outputs with explicit policy. For example, a release may proceed automatically only when the model indicates low risk, required tests pass, security gates are satisfied, the change is reversible, and the service is within an agreed operational budget. This layered approach is safer than relying on a single numerical score.

FinOps and GreenOps: Extending the Meaning of Optimisation

DevOps optimisation traditionally emphasised speed and reliability. At scale, cost and environmental impact become equally important. FinOps is a collaborative operating practice in which engineering, finance, and business teams make informed decisions about cloud expenditure. GreenOps applies a similar discipline to environmental sustainability, including energy use, carbon intensity, hardware utilisation, and resource lifecycle.

AI can support FinOps by forecasting demand, identifying idle resources, detecting unusual spending, recommending rightsizing, and associating expenditure with products or teams. It can support GreenOps by scheduling flexible workloads when lower-carbon energy is available, reducing overprovisioning, selecting efficient architectures, and estimating the impact of storage, data transfer, and computation. These objectives may conflict. A lower-cost region may have a different carbon profile; rapid redundancy may improve resilience while increasing resource consumption.

Useful decision-making requires multi-objective optimisation rather than a single “lowest cost” target. Teams can define service reliability, performance, cost, and carbon constraints, then evaluate trade-offs. Measurement is difficult because carbon estimates depend on provider methodology, location, time, hardware, and workload assumptions. Consequently, sustainability dashboards should communicate uncertainty and avoid false precision.

FinOps and GreenOps are cultural practices as much as dashboards. Cost and sustainability ownership should be integrated into architecture reviews, product planning, incident learning, and platform standards. Engineers need visibility into the consequences of design decisions, while finance and sustainability specialists need sufficient technical context to interpret the measurements.

Toward Autonomous Delivery

Autonomous delivery refers to systems that can evaluate, approve, deploy, observe, and, when necessary, reverse changes with limited human intervention. It exists on a spectrum rather than as a binary condition:

• Human-operated systems require people to perform most decisions and actions.
• Human-assisted systems provide recommendations while people execute them.
• Human-approved systems prepare and validate actions that require explicit approval.
• Policy-governed systems execute low-risk actions automatically within defined boundaries.
• Highly autonomous systems adapt and remediate across a broad operational domain, with humans supervising exceptions and policy.

The appropriate level depends on blast radius, reversibility, observability, regulatory obligations, service criticality, and confidence in the evidence. Automatic scaling of stateless workers may be suitable for policy-governed autonomy. Automatic alteration of financial transactions, identity controls, or safety-critical systems requires far stronger assurance.

Progressive delivery is a practical foundation for autonomy. Feature flags, canary releases, blue-green deployment, automated rollback, health checks, and service-level objectives create mechanisms for limiting exposure. An autonomous system should have a bounded action space, least-privilege access, rate limits, approval thresholds, a kill switch, and independent monitoring. “Self-healing” must not mean that a system repeatedly changes itself without preserving evidence or learning from failure.

An Illustrative Case: Intelligent Release Governance at Meridian Health Services

Background

Meridian Health Services, a fictional regional healthcare provider, operated a cloud-based appointment and patient-notification platform. Its development teams deployed frequently, but production incidents increased as the platform accumulated integrations with laboratories, payment services, and identity providers. Engineers received thousands of alerts during incidents, and cloud expenditure varied substantially between months.

Situation and Problem

Management proposed an AI-enabled release system that would generate test cases, score deployment risk, correlate alerts, recommend remediation, and automatically deploy low-risk changes. The proposal promised shorter lead time and fewer incidents, but the platform processed sensitive information and supported time-critical services. The central question was not whether AI could be introduced, but where autonomy could be justified.

Analysis

An initial data review found inconsistent service ownership labels, incomplete incident records, and monitoring gaps in several integration services. Historical deployments also reflected changing team structures, making naive prediction unreliable. A generative assistant was found to produce useful test scaffolding but occasionally included obsolete library calls. The organisation therefore classified data quality and security controls as prerequisites rather than secondary tasks.

Approach and Strategy

Meridian introduced a staged programme. First, it standardised service metadata, incident taxonomies, deployment records, and access controls. Second, an AIOps capability grouped duplicate alerts and presented dependency-aware incident timelines, while engineers retained responsibility for diagnosis. Third, a release-risk model was used only to recommend canary size, additional review, and test selection. Fourth, an approved assistant generated unit-test drafts and runbook summaries; all outputs entered normal review and scanning workflows.

Autonomous action was limited to reversible changes in non-sensitive components, such as adjusting capacity within predefined limits. Production releases affecting identity, payment, or clinical notification flows required human approval. Every model recommendation included evidence, confidence information, and an explanation of the data used. A governance group reviewed false positives, false negatives, escaped defects, cost changes, and staff feedback each month.

Outcome

The illustrative programme improved the consistency of triage and reduced unnecessary manual investigation, but it did not eliminate incidents. More importantly, it revealed that observability quality and service ownership were stronger predictors of success than the sophistication of the model. The organisation expanded controlled autonomy only after demonstrating reliable rollback, adequate test coverage, and clear accountability.

Learning Points

The case demonstrates five principles. AI adoption should begin with an operational problem rather than a fashionable tool. Data quality is a delivery capability. Generated artefacts need ordinary engineering controls. Autonomy should be proportional to risk and reversibility. Finally, successful AI-enabled DevOps is an organisational redesign involving platform teams, security, finance, operations, and product leadership.

Risks, Governance, and Professional Responsibility

AI introduces familiar DevOps risks in new forms and creates additional ones. Automation bias occurs when people accept a model recommendation because it appears objective or technically sophisticated. Alert amplification occurs when poorly tuned intelligence generates more events than it removes. Model drift reduces performance as systems and usage change. Data leakage may expose secrets or personal information through prompts, training data, logs, or telemetry. Generated code may contain vulnerabilities, insecure defaults, or incompatible licences. Excessive dependence on one provider can create concentration and exit risks.

Governance should be risk-based and integrated with existing software, security, and service-management controls. A practical governance model includes:

• an inventory of AI use cases, models, data sources, owners, and affected systems;
• classification according to impact, sensitivity, autonomy, and reversibility;
• approved data-handling and model-use policies;
• evaluation before deployment and continuous monitoring after deployment;
• human review requirements for consequential actions;
• logging of prompts, inputs, outputs, decisions, approvals, and executed actions where lawful and appropriate;
• security testing, access control, supply-chain review, and incident response;
• periodic retirement or retraining when performance or context changes.

Governance must not be reduced to documentation. Controls should be technically enforceable through identity management, policy-as-code, pipeline gates, environment separation, secrets management, and immutable audit records. At the same time, governance should avoid prohibiting low-risk experimentation so completely that teams adopt unapproved tools in secret.

Legal and ethical questions include ownership of generated code, protection of confidential information, accountability for automated decisions, explainability to affected stakeholders, accessibility, and discrimination. Organisations should also consider whether workforce monitoring data is being repurposed without legitimate justification. Professional responsibility remains with the organisation and authorised practitioners; delegating an action to a model does not delegate accountability.

Workforce and Organisational Implications

AI changes the distribution of work rather than simply removing work. Routine code composition, ticket classification, dashboard navigation, and first-line explanation may require less time. Demand increases for system thinking, architecture, data governance, threat modelling, experimentation, model evaluation, incident leadership, and communication with non-technical stakeholders.

The future DevOps professional needs both technical and critical capabilities: software engineering, cloud and platform knowledge, observability, security, statistical reasoning, prompt and context design, model limitations, and ethical judgement. Teams should establish learning pathways and evaluate productivity claims carefully. Faster code generation can increase review and maintenance burdens if quality controls do not mature at the same pace.

Organisational design also matters. A central AI platform team may provide approved models, retrieval services, evaluation tools, and governance patterns, while product teams retain domain responsibility. Communities of practice can share effective prompts, test strategies, failure cases, and policy interpretations. Performance measurement should reward reliability, learning, and customer outcomes rather than raw volume of generated code or deployments.

Emerging Developments

Several developments are likely to shape AI-enabled DevOps. Multimodal assistants will combine code, diagrams, traces, screenshots, and natural-language descriptions. Smaller specialised models may run within private environments, improving latency and data control. Software supply chains will increasingly include model files, prompts, retrieval indexes, and inference services that require provenance and security review.

Agentic systems will be able to plan multi-step tasks, call tools, inspect results, and revise their actions. Their usefulness will depend on constrained permissions, reliable state management, and evaluation of complete task outcomes rather than individual responses. Digital twins and simulation environments may allow deployment policies to be tested against representative workloads before production exposure.

The most significant development may be the convergence of reliability, security, cost, and sustainability signals. A release decision could consider vulnerability exposure, error budgets, carbon intensity, cloud cost, customer impact, and rollback readiness together. Such convergence is valuable, but it also raises a governance question: who decides how these objectives are prioritised when they conflict? The answer must be explicit, reviewable, and aligned with organisational purpose.

Best-Practice Guidance for Adoption

A disciplined adoption sequence is preferable to indiscriminate automation. Begin with a clearly defined pain point and a measurable baseline. Improve telemetry, metadata, access control, and service ownership before expecting sophisticated predictions. Pilot low-risk, high-volume use cases such as alert deduplication, documentation assistance, test drafting, and cost anomaly detection. Keep generated outputs inside existing review and security workflows.

Define success through outcome measures: mean time to restore, change failure rate, escaped defects, developer cognitive load, cost variance, carbon intensity, customer impact, and trust in recommendations. Measure unintended effects as well as benefits. Use shadow mode before allowing a model to act. Establish rollback and kill-switch mechanisms before increasing autonomy. Evaluate models on representative, adversarial, and rare cases, and reassess them after architectural or organisational change.

Finally, preserve human capability. An organisation that automates every diagnostic step may lose the expertise needed during an unprecedented failure. Runbooks, exercises, post-incident reviews, and manual fallback procedures remain essential even when AI performs routine operations.

Chapter Summary

AI-enabled DevOps extends automated delivery with inference, generation, prediction, and adaptive action. AIOps reduces operational noise through event correlation, anomaly detection, forecasting, and recommendation, but its outputs are probabilistic and dependent on data quality. Generative assistants accelerate coding, testing, documentation, and operations while requiring review, security controls, and provenance management. Intelligent testing improves test selection and generation, yet coverage alone cannot guarantee quality.

Predictive analytics can support deployment-risk assessment and capacity planning when models are monitored for drift and used as decision aids. FinOps and GreenOps broaden optimisation beyond speed to include financial and environmental outcomes. Autonomous delivery is best implemented progressively, with bounded permissions, observability, reversibility, and human oversight. Effective governance addresses privacy, security, bias, intellectual property, accountability, and auditability. The future workforce will require stronger judgement, systems thinking, data literacy, and AI governance capabilities. The central principle is that AI should amplify disciplined DevOps practices, not substitute for them.

Key Terms

AIOps: Application of AI and machine learning to IT operations data and workflows.

Anomaly detection: Identification of observations that differ significantly from expected behaviour.

Automation bias: Tendency to trust an automated recommendation without sufficient critical evaluation.

Autonomous delivery: Software delivery in which systems perform deployment and operational decisions with limited human intervention.

Canary release: Gradual exposure of a change to a small portion of users or infrastructure.

Data drift: Change in the characteristics of data used by a model over time.

Event correlation: Grouping related operational events to identify a common incident or pattern.

FinOps: Collaborative practice for managing and optimising technology expenditure.

Generative AI: AI capable of producing new content such as code, text, tests, or configuration.

GreenOps: Practices that incorporate environmental sustainability into technology operations.

Human-in-the-loop: Arrangement in which a person reviews or approves an AI-supported decision or action.

Model calibration: Agreement between predicted probabilities and the observed frequency of outcomes.

Model governance: Policies and controls for the responsible development, use, monitoring, and retirement of models.

Mutation testing: Evaluation of tests by introducing artificial defects and checking whether tests detect them.

Predictive analytics: Use of data and statistical or machine-learning methods to estimate future outcomes.

Progressive delivery: Gradual, observable release of changes using mechanisms such as canaries and feature flags.

Prompt injection: Manipulation of an AI system through malicious instructions contained in input or retrieved content.

Retrieval-augmented generation: Generation that uses retrieved organisational or external information as contextual input.

Service-level objective: A target level of service performance or reliability.

Test selection: Choosing a subset of tests based on change impact, risk, history, or other evidence.

Review Questions

Short Answer Questions

1. How does AIOps differ from conventional rule-based monitoring?

2. Why should generated code be treated as an untrusted contribution?

3. Define model drift and explain why it matters in DevOps.

4. What is the purpose of a canary release in autonomous delivery?

5. State two objectives of GreenOps.

Long Answer Questions

1. Explain the architecture and principal capabilities of an AIOps platform, including its limitations.

2. Critically evaluate the use of generative AI assistants across software development and operations.

3. Discuss how intelligent testing can improve quality without creating false confidence from coverage metrics.

4. Explain how FinOps and GreenOps alter traditional DevOps optimisation decisions.

5. Develop a governance framework for an organisation introducing AI-supported production changes.

Analytical / Application Questions

1. A deployment-risk model recommends blocking a release because the change is large, although all tests pass and the change is a well-understood database migration with a tested rollback. What evidence should the team examine, and what decision process would be appropriate?

2. An AIOps platform reduces alert volume by 70 percent, but the number of severe incidents discovered by customers increases. Analyse possible causes and propose corrective actions.

3. Design a staged autonomy plan for a cloud service that must balance reliability, cost, carbon impact, and protection of sensitive data. Specify which actions may be automated and which require human approval.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes prescriptive AIOps from predictive AIOps?

A. Prescriptive AIOps reports historical events, while predictive AIOps stores logs.

B. Prescriptive AIOps recommends or executes actions, while predictive AIOps estimates likely future outcomes.

C. Prescriptive AIOps generates source code, while predictive AIOps performs unit testing.

D. Prescriptive AIOps applies only to finance, while predictive AIOps applies only to security.

Correct Answer: B. Prescriptive AIOps recommends or executes actions, while predictive AIOps estimates likely future outcomes.

Question 2

A generative AI assistant proposes syntactically valid infrastructure code that exposes a management port publicly. What is the most appropriate response?

A. Deploy it because syntactic validity indicates operational correctness.

B. Accept it if the assistant has been used successfully on previous tasks.

C. Treat it as untrusted, review it, and apply security and policy checks before use.

D. Disable all automated testing because the assistant generated the code.

Correct Answer: C. Treat it as untrusted, review it, and apply security and policy checks before use.

Question 3

Why can event correlation improve incident response?

A. It guarantees that the first correlated event is the causal root cause.

B. It groups related symptoms so engineers can investigate a probable common incident.

C. It eliminates the need for service topology and ownership information.

D. It prevents new and previously unseen failures from occurring.

Correct Answer: B. It groups related symptoms so engineers can investigate a probable common incident.

Question 4

Which practice most directly reduces the risk of an AI system executing a harmful operational command?

A. Allowing unrestricted administrator privileges for faster remediation.

B. Removing audit logs to reduce storage costs.

C. Using constrained permissions, dry runs, approvals, and reversible actions.

D. Training the model only on successful incidents.

Correct Answer: C. Using constrained permissions, dry runs, approvals, and reversible actions.

Question 5

A test-selection model repeatedly omits an infrequently run integration suite because historical failures are rare. What is the principal danger?

A. The model will necessarily increase unit-test execution time.

B. Rare but important systemic defects may escape detection.

C. The model will prevent all forms of mutation testing.

D. The integration suite will become a form of static analysis.

Correct Answer: B. Rare but important systemic defects may escape detection.

Question 6

Which statement reflects sound interpretation of a deployment-risk score?

A. It is a decision aid whose evidence and error costs should be examined.

B. It is proof that the deployment will fail if the score is high.

C. It should automatically evaluate individual developer performance.

D. It makes rollback and canary mechanisms unnecessary.

Correct Answer: A. It is a decision aid whose evidence and error costs should be examined.

Question 7

What is a central concern when using cloud cost as the sole optimisation objective?

A. Cost is unrelated to architecture and workload decisions.

B. The cheapest choice may conflict with reliability, security, or environmental objectives.

C. FinOps requires that all workloads be moved to one provider.

D. Cost optimisation prevents the use of predictive analytics.

Correct Answer: B. The cheapest choice may conflict with reliability, security, or environmental objectives.

Question 8

Which sequence best represents increasing levels of delivery autonomy?

A. Human-operated, human-assisted, human-approved, policy-governed, highly autonomous.

B. Highly autonomous, human-approved, human-operated, policy-governed, human-assisted.

C. Human-assisted, descriptive, predictive, manual, highly autonomous.

D. Canary, blue-green, rollback, monitoring, human-operated.

Correct Answer: A. Human-operated, human-assisted, human-approved, policy-governed, highly autonomous.

Question 9

An operations assistant reads a malicious instruction embedded in a log file and follows it. Which risk does this illustrate?

A. Mutation testing

B. Prompt injection

C. Carbon intensity

D. Model calibration

Correct Answer: B. Prompt injection

Question 10

Which adoption strategy is most consistent with responsible AI-enabled DevOps?

A. Begin with unrestricted production autonomy and establish controls after incidents.

B. Pilot low-risk use cases, improve data and observability, measure outcomes, and expand autonomy gradually.

C. Replace human review wherever a model produces confident language.

D. Measure success only by the volume of code generated.

Correct Answer: B. Pilot low-risk use cases, improve data and observability, measure outcomes, and expand autonomy gradually.