DevOps

Chapter 14
AI-Enabled DevOps, Ethics, and Future Directions

Bachelors Program in Computer Applications
DevOps   •   Bachelor

AI-Enabled DevOps, Ethics, and Future Directions

Introduction

DevOps integrates development, security, quality assurance, and IT operations into a continuous system for delivering reliable software. Artificial intelligence (AI) is changing this system by assisting developers, generating tests, detecting operational anomalies, predicting failures, optimizing infrastructure, and supporting decision-making. The resulting discipline is often described as AI-enabled DevOps or AIOps.

AI does not replace DevOps principles. Fast feedback, automation, collaboration, observability, version control, and incremental improvement remain essential. AI extends these practices by processing volumes of telemetry and code that humans cannot examine manually. However, it also introduces risks: incorrect generated code, opaque recommendations, privacy violations, biased models, excessive automation, cyberattacks against models, and unclear accountability.

This chapter evaluates the technical value and limitations of AI across the software delivery lifecycle. It also examines ethical governance, workforce implications, sustainability, autonomous operations, GreenOps, edge delivery, and intelligent platforms.

Learning Objectives

After studying this chapter, students should be able to:

  1. Explain how AI supports development, testing, deployment, and operations.
  2. Distinguish AI-assisted DevOps from AIOps and conventional automation.
  3. Evaluate predictive analytics using suitable data, metrics, and validation methods.
  4. Design human oversight, privacy, security, and accountability controls.
  5. Analyse the effects of AI on developers, operators, organizations, and society.
  6. Explain GreenOps, edge delivery, autonomous operations, and intelligent platforms.
  7. Recommend a responsible adoption strategy for an AI-enabled DevOps environment.

1. From Automation to AI-Enabled DevOps

Traditional automation executes explicitly specified rules. For example, a pipeline may run tests after a commit and deploy if all gates pass. AI-based systems infer patterns from data and produce predictions, classifications, recommendations, or generated artefacts. The distinction is important:

  • Automation follows known instructions.
  • Machine learning (ML) learns relationships from examples.
  • Generative AI produces new text, code, tests, configurations, or documentation from prompts and context.
  • AIOps applies analytics and machine learning to operational data such as logs, metrics, traces, events, tickets, and topology information.

An AI recommendation is not automatically correct. Its quality depends on training data, current context, measurement design, model drift, and the consequences of error. Therefore, AI should normally be integrated into controlled workflows rather than granted unrestricted authority.

A useful conceptual model is a feedback loop:

AI-enabled DevOps feedback loop Code andconfiguration Build, test,deploy Observe andcollect data AI analysis anddecision support Human review, learning, and controlled improvement
AI-enabled DevOps feedback loop
Figure: AI-enabled DevOps feedback loop

Figure: AI-enabled DevOps as a monitored feedback loop rather than an unsupervised replacement for engineering judgment.

2. AI Across the DevOps Lifecycle

2.1 Requirements and planning

Natural-language systems can summarize tickets, identify duplicates, propose acceptance criteria, and estimate dependencies. They can also retrieve relevant design documents and previous incidents. These capabilities reduce administrative effort, but generated requirements may omit non-functional concerns such as accessibility, security, latency, legal compliance, or data retention. A product owner must therefore validate both the requirement and its source context.

AI can support prioritization by combining customer impact, defect severity, operational risk, and implementation effort. This should be treated as decision support, not an objective ranking. Historical data may reflect unequal attention to different user groups, causing the model to reproduce organizational bias.

2.2 Software design and coding

Coding assistants can explain unfamiliar code, generate boilerplate, suggest refactorings, translate between programming languages, and identify likely defects. They are particularly valuable for repetitive tasks and learning. Developers remain responsible for architecture, correctness, licensing review, security, maintainability, and suitability for the system’s context.

Common failure modes include:

  • syntactically valid but semantically incorrect code;
  • obsolete or insecure API usage;
  • fabricated libraries or functions;
  • insecure handling of authentication, secrets, or input validation;
  • duplicated code and unnecessary complexity;
  • unverified open-source license or provenance concerns.

A robust workflow requires code review, static analysis, dependency scanning, unit tests, secret detection, and reproducible builds. Generated code should be identifiable in the development process so that reviewers can apply appropriate scrutiny.

2.3 AI-assisted testing

AI can generate test cases from source code, requirements, API descriptions, production traces, and previous failures. It can prioritize tests likely to expose defects, classify flaky tests, generate synthetic test data, and compare visual interfaces.

AI-based test generation is not a substitute for a testing strategy. Tests generated from the implementation may merely reproduce its assumptions and fail to challenge incorrect requirements. Human-designed tests remain important for boundary conditions, abuse cases, accessibility, privacy, and domain-specific risks.

Test selection can be viewed as an optimization problem: maximize useful defect detection while respecting time and compute constraints. The objective is not simply to maximize the number of tests. A large suite containing redundant or flaky tests can reduce delivery confidence.

2.4 Deployment and release management

AI can recommend deployment windows, identify risky changes, compare canary groups, and correlate release events with changes in error rates. A release decision should consider service-level objectives (SLOs), rollback readiness, customer impact, and the confidence of the evidence.

A useful distinction is between:

  • advisory automation, which recommends an action;
  • approval automation, which executes after predefined human or policy approval;
  • bounded autonomy, which acts within explicit limits and can be reversed;
  • unbounded autonomy, which is generally inappropriate for high-impact production changes.

Progressive delivery, feature flags, canary releases, automatic rollback, and immutable artefacts reduce the consequences of an incorrect AI recommendation.

2.5 Operations and incident response

Operational AI processes logs, metrics, traces, events, topology, deployment history, and support tickets. It may detect anomalies, correlate alerts, identify probable causes, forecast capacity, recommend remediation, and summarize incidents.

AIOps is most effective when observability data is well structured and contextual. A model cannot reliably diagnose a distributed system if telemetry is incomplete, clocks are inconsistent, service ownership is unknown, or alerts are noisy. Data quality is therefore an engineering responsibility, not merely a machine-learning concern.

AI-generated incident summaries can improve handovers, but operators must verify them against primary evidence. A plausible narrative is not proof of causation.

3. Predictive Analytics for DevOps

Predictive analytics uses historical and current data to estimate future states. Examples include failure prediction, demand forecasting, defect prediction, alert-volume forecasting, and prediction of deployment risk.

A basic forecasting notation is:

ŷt+h = f(yt, yt-1, …, xt, xt-1, …)

Here, yt is the observed value at time t, xt represents explanatory variables such as traffic or deployment activity, h is the forecast horizon, ŷt+h is the predicted value, and f is the fitted model. The relationship is not a law of nature; it is an empirical estimate that depends on representative data and stable enough conditions.

For a regression model, mean absolute error is often useful:

MAE = (1/n) ∑i=1n |yi − ŷi|

Here, n is the number of observations, yi is the actual value, and ŷi is the prediction. MAE has the same units as the predicted quantity, making interpretation straightforward. It treats all absolute errors linearly and can hide whether errors are concentrated in rare but serious incidents.

For classification, such as predicting whether a deployment will cause an incident, a confusion matrix distinguishes true positives, false positives, true negatives, and false negatives. Precision and recall are:

Precision = TP ÷ (TP + FP)
Recall = TP ÷ (TP + FN)

TP denotes true positives, FP false positives, and FN false negatives. Precision matters when unnecessary intervention is costly; recall matters when missed failures are dangerous. The appropriate balance depends on the operational context.

Worked example: deployment-risk classification

Suppose a model flags 40 deployments as risky. Of these, 30 actually cause a defined incident. There are 10 risky deployments that were not flagged but later caused incidents. Precision is 30 ÷ 40 = 0.75, or 75%. Recall is 30 ÷ (30 + 10) = 0.75, or 75%. This does not establish that the model is useful by itself. Engineers must compare it with a baseline, evaluate performance on later data, examine the cost of false alarms, and check whether the definition of “incident” is consistent.

Model drift and feedback loops

Operational environments change. New services, traffic patterns, architectures, teams, and attack methods can make old data less representative. Data drift concerns changes in input distributions; concept drift concerns changes in the relationship between inputs and outcomes. Monitoring should include performance, data quality, missing values, latency, and changes in class frequency.

A dangerous feedback loop occurs when an AI system’s recommendations change the data later used to retrain it. For example, if the system only investigates alerts it considers important, future training data may underrepresent overlooked failures. Human sampling and independent audits help reduce this risk.

4. AIOps Architecture and Engineering Practice

An AIOps platform commonly contains the following layers:

  1. Collection: agents and services gather logs, metrics, traces, events, tickets, topology, and deployment metadata.
  2. Normalization: timestamps, identifiers, units, and schemas are made consistent.
  3. Storage and processing: data is retained, indexed, streamed, and correlated.
  4. Analytics: statistical rules, machine learning, natural-language processing, and graph methods detect patterns.
  5. Decision support: dashboards, summaries, forecasts, probable causes, and recommendations are presented.
  6. Action orchestration: approved actions invoke runbooks, scaling, rollback, ticket creation, or traffic changes.
  7. Governance: access controls, audit trails, model evaluation, policy enforcement, and human escalation operate across all layers.

A mature implementation starts with a narrow, measurable problem, such as reducing duplicate alerts or improving capacity forecasts. It should define a baseline and a success criterion before introducing a model. “AI adoption” is not itself a performance objective.

5. Reliability, Security, and Quality Controls

AI-enabled systems add a new attack surface. Threats include prompt injection, poisoning of training data, extraction of sensitive information, model theft, malicious generated code, supply-chain compromise, and manipulation of telemetry. An attacker who can alter logs may influence an operational model’s diagnosis.

Important controls include:

  • least-privilege access to models, tools, repositories, and production systems;
  • separation between untrusted model output and executable commands;
  • input and output validation;
  • secret redaction and data-loss prevention;
  • signed artefacts and dependency verification;
  • prompt and model versioning;
  • sandboxing of generated code;
  • human approval for high-impact actions;
  • immutable audit logs;
  • rollback and break-glass procedures;
  • regular red-team and adversarial testing.

Reliability engineering also requires measuring the AI component itself. Relevant dimensions include availability, response latency, prediction quality, calibration, explainability, reproducibility, and safe degradation. If an AI service becomes unavailable, the surrounding DevOps process should continue with a safe fallback rather than fail catastrophically.

6. Ethics, Privacy, Bias, and Accountability

Privacy and data governance

Operational data may contain usernames, IP addresses, customer messages, source code, credentials, or personal information. Sending such data to an external model can violate confidentiality, contractual obligations, or data-protection law. Organizations should define data classification, purpose limitation, retention periods, residency requirements, and access policies.

Privacy-preserving techniques may include redaction, pseudonymization, aggregation, access-controlled retrieval, local inference, and synthetic data. Pseudonymization does not make data anonymous if individuals can be reidentified by combining datasets.

Bias and fairness

Bias can enter through historical labels, unrepresentative samples, proxy variables, unequal monitoring, and different error costs. For instance, a defect-prediction model trained on heavily tested components may incorrectly treat lightly tested components as low risk. Fairness cannot be assessed by a single universal metric; the relevant groups, harms, and trade-offs must be specified.

Teams should document data sources, intended use, known limitations, evaluation populations, and out-of-scope decisions. Impact assessments should include affected employees, customers, and communities, not only system owners.

Transparency and accountability

A technically accurate model can still be unacceptable if no person can explain who approved its use or who is responsible when it fails. Accountability requires named owners, decision records, escalation routes, auditability, and clear authority boundaries. “The model made the decision” is not an adequate governance explanation.

Explainability should be proportional to impact. A low-risk suggestion may need a concise rationale; an automated action affecting customer access, employment, safety, or financial loss may require detailed evidence and human review.

Workforce and professional ethics

AI changes job tasks rather than producing a simple division between “replaced” and “unchanged” work. Routine coding, test authoring, and alert triage may decline, while architecture, verification, security, communication, data governance, and incident leadership become more important. Organizations have an ethical responsibility to provide training, avoid opaque employee surveillance, and evaluate performance fairly when tools alter productivity measures.

Professional competence includes knowing when not to trust an AI output. Engineers should preserve independent review and should not claim authorship, testing, or validation that was not actually performed.

7. Sustainability and GreenOps

AI workloads can increase electricity consumption through model training, inference, data movement, and storage. DevOps also affects sustainability through inefficient architectures, overprovisioning, excessive logging, and unnecessary builds.

GreenOps integrates environmental considerations into operational decisions. Practices include right-sizing, autoscaling, workload scheduling, efficient storage retention, carbon-aware region selection, efficient model choice, batching requests, reducing data movement, and extending hardware life. These decisions require trade-offs: a region with lower operational emissions may have higher latency, and aggressive scale-down may harm reliability.

A simple energy relationship is:

E = P × t

Here, E is energy in watt-hours when P is average power in watts and t is time in hours. This equation assumes power is represented by a suitable average over the interval. If power varies substantially, energy is more accurately represented by integrating power over time. Carbon impact can be estimated as:

C = E × I

where C is carbon dioxide equivalent, E is energy, and I is an emissions factor such as grams of CO₂e per watt-hour. The estimate is only as reliable as the boundary, energy measurement, and emissions factor. Teams should avoid presenting a precise number when these inputs are uncertain.

Sustainability should be measured alongside reliability, cost, performance, and security rather than treated as an optional report.

8. Future Directions

Autonomous operations

Autonomous operations aim to detect, diagnose, and remediate faults with minimal human intervention. A safe progression is from recommendations, to approved runbooks, to bounded autonomous actions, and finally to carefully evaluated closed-loop control. The last stage requires constraints, observability, reversible actions, simulation or testing, and escalation when confidence is low.

Autonomy is unsuitable when system state is poorly observed, remediation is irreversible, or the consequences of error are severe. A system that automatically restarts a stateless worker is fundamentally different from one that changes financial transaction rules.

Edge delivery

Edge computing places computation and content closer to users, devices, or data sources. AI at the edge can support low-latency detection, offline operation, privacy, and reduced data transfer. Constraints include limited compute, intermittent connectivity, model update management, heterogeneous hardware, and physical security. Edge DevOps therefore requires fleet inventory, staged updates, signed models, remote observability, and recovery procedures.

Intelligent platforms

Platform engineering provides reusable internal capabilities such as deployment templates, service catalogues, identity, observability, and policy controls. Intelligent platforms may recommend suitable infrastructure, generate pipeline configurations, detect non-compliant resources, and tailor developer portals to team needs.

The platform must not become an opaque gatekeeper. Golden paths should remain understandable, overrideable under controlled conditions, documented, and evaluated using developer experience, reliability, security, and delivery outcomes.

Digital twins and simulation

A digital twin or operational simulator can model services, dependencies, traffic, and failure scenarios. It may allow teams to evaluate scaling policies or remediation before production use. The model is an approximation: inaccurate assumptions can create false confidence. Simulation must therefore be calibrated against observed behaviour and supplemented by controlled production experiments.

Policy-as-code and continuous governance

As AI decisions become more frequent, governance cannot rely only on annual review. Policy-as-code can enforce data handling, deployment approvals, regional restrictions, resource limits, and separation of duties within pipelines. Policies themselves require version control, testing, exception management, and periodic review.

9. Illustrative Case: AI-Assisted Reliability in a Retail Platform

Background

A fictional online retailer operates dozens of services across several cloud regions. Its operations team receives thousands of alerts each week, many of which refer to the same underlying event. Incident response is slow, and a recent traffic surge caused a checkout outage.

Problem

The retailer proposes an AIOps platform to correlate alerts, forecast traffic, identify probable causes, and automatically scale services. The organization must improve reliability without sending customer data to an uncontrolled external model or allowing unsafe automated changes.

Analysis

An initial audit finds inconsistent service names, missing trace identifiers, excessive log retention, and no reliable labels for incident outcomes. These data-quality problems mean that model deployment would be premature. The team defines a baseline: alert volume, median time to acknowledge, mean time to restore, forecast error, and the percentage of recommendations accepted by engineers. It also classifies customer data and prohibits raw payment information from entering the model context.

Approach and solution

The retailer first normalizes telemetry and introduces ownership metadata. It deploys a model to cluster duplicate alerts and summarize evidence, but does not permit direct production changes. Engineers review recommendations through an auditable interface. A separate forecasting model predicts checkout traffic and recommends capacity changes. Scaling actions are limited by policy, tested in a staging environment, and reversible.

The organization creates a model register containing purpose, data sources, owner, version, evaluation results, limitations, and retirement criteria. It tests the system against missing telemetry, deliberately misleading logs, unusual traffic, and regional outages. A privacy review approves redaction and restricted retention. A human incident commander remains accountable for major incidents.

Outcome

After a controlled trial, duplicate alerts decline and incident summaries reduce investigation time. Forecasting is useful during ordinary seasonal demand but less reliable during unprecedented promotions. Consequently, the retailer keeps human approval for large capacity changes and maintains a manual emergency runbook. The project succeeds because it improves specific operational outcomes rather than pursuing autonomy as an end in itself.

Learning points

  1. Data quality and service ownership precede sophisticated analytics.
  2. A baseline is necessary to distinguish improvement from novelty.
  3. Bounded automation is safer than unrestricted automation.
  4. Privacy, auditability, and rollback are design requirements.
  5. Models must be evaluated under both normal and abnormal conditions.

10. Adoption Framework and Best Practices

An organization planning AI-enabled DevOps can follow these stages:

  1. Define the problem: identify a measurable reliability, quality, security, cost, or sustainability issue.
  2. Assess feasibility: examine data availability, quality, sensitivity, ownership, and operational consequences.
  3. Choose the least complex effective method: a rule or statistical baseline may be preferable to a large model.
  4. Run a controlled experiment: compare against current practice using representative data and a defined time period.
  5. Add safeguards: permissions, validation, human review, audit logs, rate limits, fallback procedures, and rollback.
  6. Deploy gradually: begin with advisory output, then use bounded automation only when evidence supports it.
  7. Monitor continuously: track model quality, drift, false alarms, security, cost, energy, and user impact.
  8. Review and retire: update, retrain, replace, or remove the system when assumptions no longer hold.

Technical teams should also preserve engineering fundamentals: version-controlled infrastructure, automated testing, secure software supply chains, observability, incident learning, documentation, and blameless improvement. AI is most valuable when it strengthens these practices rather than concealing their absence.

Challenges and Limitations

AI-enabled DevOps faces several persistent limitations:

  • training and operational data may be incomplete or biased;
  • correlation does not establish causation;
  • rare failures provide few examples for learning;
  • generated content can be confidently wrong;
  • models may drift as architectures and teams change;
  • complex systems make accountability difficult;
  • inference costs and environmental effects may be substantial;
  • vendor dependence can reduce portability and transparency;
  • excessive alerts or recommendations can create automation fatigue;
  • security controls may be bypassed through novel inputs;
  • performance improvements may be difficult to attribute to the AI system.

The correct response is not to reject AI, but to match autonomy and trust to evidence, impact, reversibility, and uncertainty.

Chapter Summary

AI-enabled DevOps applies machine learning, generative AI, and operational analytics to planning, coding, testing, deployment, monitoring, incident response, capacity management, and continuous improvement. Coding assistants and test-generation systems increase productivity but require human review, security analysis, and provenance checks. AIOps correlates telemetry and supports anomaly detection, forecasting, diagnosis, and remediation; its quality depends heavily on observability and data governance.

Predictive models must be evaluated with appropriate metrics, representative data, baselines, and drift monitoring. Precision, recall, and error measures describe particular aspects of performance but do not replace operational judgment. Ethical implementation requires privacy protection, bias assessment, transparency, named accountability, secure model integration, and respect for affected workers and users.

GreenOps addresses energy, emissions, resource efficiency, and sustainable architecture. Future directions include bounded autonomous operations, edge delivery, intelligent platforms, digital twins, and policy-as-code. Responsible adoption begins with a measurable problem, proceeds through controlled experimentation, and maintains human oversight, auditability, safe fallback, and continuous review.

Key Terms

AI-enabled DevOps: Use of AI technologies to assist or automate activities across the software delivery and operations lifecycle.

AIOps: Application of analytics and machine learning to IT operational data and workflows.

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

Bounded autonomy: Automated action restricted by explicit policies, limits, and recovery mechanisms.

Concept drift: Change over time in the relationship between model inputs and outcomes.

Data drift: Change in the distribution or quality of model input data.

Generative AI: AI that produces new content such as code, tests, text, or configurations.

GreenOps: Operational practice that incorporates environmental sustainability into technology decisions.

Human-in-the-loop: Design in which people review, approve, or supervise AI outputs or actions.

Model register: Governance record describing models, owners, data, versions, risks, and evaluation.

Observability: Ability to infer internal system state from logs, metrics, traces, and related evidence.

Precision: Fraction of positive predictions that are true positives.

Predictive analytics: Analysis that estimates future events or states from data.

Recall: Fraction of actual positive cases correctly identified.

Responsible AI: Design and use of AI that addresses safety, fairness, privacy, transparency, and accountability.

Telemetry: Operational data collected from software, infrastructure, and devices.

Concept drift: Change in the statistical relationship between observed variables and the target outcome.

Progressive delivery: Gradual release of changes through methods such as canary deployment and feature flags.

Review Questions

Short Answer Questions

  1. Distinguish conventional automation, machine learning, generative AI, and AIOps.
  2. Why is observability data quality important for AIOps?
  3. Define data drift and concept drift.
  4. State two privacy risks associated with AI-enabled DevOps.
  5. What is bounded autonomy, and why is it safer than unrestricted automation?

Long Answer Questions

  1. Explain how AI can support each major stage of the DevOps lifecycle, and discuss the limitations at each stage.
  2. Describe an AIOps architecture from telemetry collection through governance and action orchestration.
  3. Discuss how precision, recall, and operational cost should influence evaluation of a deployment-risk model.
  4. Analyse the ethical responsibilities of an organization using generative AI for software development.
  5. Explain how GreenOps, edge delivery, and intelligent platforms may shape future DevOps practice.

Analytical / Application Questions

  1. An organization receives many correlated alerts but has inconsistent service names and missing trace identifiers. Should it deploy an autonomous remediation model immediately? Analyse the risks and propose a staged plan.
  2. A model flags 80 deployments as risky; 60 of those cause incidents. Another 20 deployments cause incidents but were not flagged. Calculate precision and recall, then explain whether these values alone justify automation.
  3. Design a governance plan for an AI system that recommends cloud scaling during a retail promotion. Include data protection, evaluation, approval boundaries, monitoring, sustainability, and rollback.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes AIOps from ordinary DevOps automation?

A. AIOps executes only manually written shell scripts.

B. AIOps applies analytics and machine learning to operational data and workflows.

C. AIOps removes the need for observability.

D. AIOps is limited to source-code generation.

Correct Answer: B. AIOps applies analytics and machine learning to operational data and workflows.

Question 2

A coding assistant generates syntactically valid code using an obsolete insecure API. What is the most appropriate control?

A. Deploy it immediately because it compiled.

B. Disable all automated testing.

C. Use code review, security analysis, dependency checks, and tests.

D. Assume the model provider is legally responsible.

Correct Answer: C. Use code review, security analysis, dependency checks, and tests.

Question 3

A model produces 30 true-positive alerts and 10 false-positive alerts. What is its precision?

A. 25%

B. 30%

C. 75%

D. 90%

Correct Answer: C. 75%

Question 4

Which practice most directly supports GreenOps?

A. Retaining every log forever

B. Running all workloads at maximum capacity

C. Right-sizing resources and reducing unnecessary data movement

D. Disabling monitoring to reduce storage costs

Correct Answer: C. Right-sizing resources and reducing unnecessary data movement

Question 5

What is concept drift?

A. A change in the relationship between model inputs and outcomes

B. A failure to encrypt a database

C. A reduction in source-code size

D. A change from one programming language to another

Correct Answer: A. A change in the relationship between model inputs and outcomes

Question 6

Why should generated incident summaries be checked against primary evidence?

A. They are guaranteed to be incomplete by definition.

B. A plausible generated narrative may be inaccurate or confuse correlation with causation.

C. Primary evidence is never useful during incidents.

D. Checking evidence prevents all future incidents.

Correct Answer: B. A plausible generated narrative may be inaccurate or confuse correlation with causation.

Question 7

Which is an example of bounded autonomy?

A. Allowing a model to change any production configuration without approval

B. Allowing an approved runbook to scale a service within policy limits and with rollback

C. Removing all human escalation paths

D. Permitting a model to delete historical telemetry

Correct Answer: B. Allowing an approved runbook to scale a service within policy limits and with rollback

Question 8

Which privacy measure reduces exposure of personal information sent to an AI system?

A. Redaction and purpose-limited data access

B. Increasing the model temperature

C. Disabling version control

D. Duplicating raw customer records

Correct Answer: A. Redaction and purpose-limited data access

Question 9

If actual energy use is 200 watts for 5 hours, what is the energy consumption under the constant-power assumption?

A. 40 Wh

B. 205 Wh

C. 1,000 Wh

D. 10,000 Wh

Correct Answer: C. 1,000 Wh

Question 10

What should an organization do first when adopting AI for DevOps?

A. Grant unrestricted production access to the largest available model

B. Define a measurable problem and establish a baseline

C. Remove existing incident runbooks

D. Replace all observability systems

Correct Answer: B. Define a measurable problem and establish a baseline

DevOps
Chapter 14 of 15