AI-Enabled DevOps and Future Directions

Introduction

DevOps has always depended on automation, feedback, measurement, and collaboration. Artificial intelligence (AI) extends these capabilities by helping teams generate software, interpret operational data, predict failures, recommend actions, and sometimes execute remediation. However, AI does not remove the need for engineering judgment. It changes where judgment is applied: from manually performing every task toward designing reliable systems, validating machine-generated decisions, managing risk, and defining appropriate boundaries for autonomy.

AI-enabled DevOps therefore means more than adding a chatbot to a software repository. It involves integrating machine-learning models, generative AI, observability data, deployment controls, security policies, and human governance into the software delivery lifecycle. The central question is not whether AI can automate a task, but whether it can perform that task safely, measurably, explainably, and economically.

This chapter examines generative AI for coding and pipelines, AIOps, predictive analytics, autonomous remediation, platform engineering, GitOps, FinOps, and green DevOps. It also evaluates risks, human oversight, digital transformation, and the changing skills required of DevOps professionals.

Learning Objectives

After completing this chapter, students should be able to:

1. Explain how generative AI can support coding, testing, documentation, and CI/CD pipelines.
2. Distinguish AIOps, predictive analytics, autonomous remediation, and traditional automation.
3. Evaluate platform engineering and GitOps as foundations for scalable AI-enabled delivery.
4. Apply FinOps and green DevOps principles to cloud and software-delivery decisions.
5. Analyse the benefits, limitations, security risks, ethical issues, and governance requirements of AI in DevOps.
6. Design a human-supervised approach to AI adoption and identify future DevOps career capabilities.

1. From Automated DevOps to AI-Enabled DevOps

Traditional DevOps automation follows explicit rules. For example, a pipeline may run tests whenever code is committed and deploy to production when an approval condition is satisfied. AI-enabled DevOps adds systems that infer patterns from data, generate content, classify events, predict outcomes, or recommend actions.

The distinction can be expressed as follows:

AI systems are not uniformly intelligent. A large language model (LLM) generates probable sequences of tokens based on training and prompt context. A forecasting model estimates future values from historical data. A clustering algorithm groups similar observations. An autonomous remediation service may combine detection, a policy engine, runbooks, and an execution mechanism. These technologies have different strengths and failure modes.

A useful operating principle is automation with bounded authority. An AI system should receive only the permissions required for its task, operate within explicit policies, produce an auditable record, and escalate uncertain or high-impact decisions to a person.

2. Generative AI Across the Software Delivery Lifecycle

Generative AI can create or transform text, source code, configuration, test cases, diagrams, queries, and documentation. Its usefulness depends heavily on context. A model with access to repository conventions, API contracts, security policies, and test results can produce more relevant output than a model given only a short natural-language request.

2.1 Coding assistance

Common uses include:

• generating function or class templates;
• explaining unfamiliar code;
• translating code between languages or frameworks;
• proposing refactorings;
• identifying likely defects;
• generating unit tests and test data;
• producing API documentation and release notes; and
• helping developers search internal documentation through retrieval-augmented generation (RAG).

Generated code must be treated as an untrusted draft. It may compile while violating business rules, using insecure libraries, mishandling errors, leaking sensitive information, or reproducing licence-restricted material. The appropriate workflow is generation followed by review, static analysis, tests, security scanning, and maintainability assessment.

A practical quality model is to evaluate generated code across multiple dimensions rather than asking whether it “works.” Relevant dimensions include functional correctness, security, performance, readability, accessibility, licence compliance, test coverage, and alignment with architectural standards.

2.2 AI in CI/CD pipelines

AI can assist pipelines by:

• prioritising tests according to changed components;
• detecting flaky tests;
• summarising build failures;
• recommending dependency upgrades;
• generating pipeline configuration;
• identifying unusual deployment behaviour; and
• selecting progressive-delivery actions such as canary expansion or rollback recommendations.

For example, an AI assistant may read a failed build log and identify that a missing environment variable caused the failure. That explanation is useful, but it should not automatically alter production configuration unless the action is authorised by policy and protected by validation.

Pipeline generation introduces supply-chain risks. A model may suggest an untrusted action, an insecure container image, excessive privileges, or a command that deletes data. Pipelines should therefore enforce signed commits where appropriate, dependency and image scanning, secret-management controls, least privilege, branch protection, and review of generated changes.

2.3 Prompting and context engineering

Effective enterprise use depends on more than writing clever prompts. Teams must engineer context: authoritative documentation, repository metadata, coding standards, examples, system boundaries, and current operational state. Prompts should specify the task, constraints, expected format, and verification requirements.

A strong request might ask an assistant to propose a Kubernetes manifest, restrict the output to a stated API version, avoid hard-coded secrets, include resource limits, and explain assumptions. The result still requires validation because detailed instructions reduce but do not eliminate model error.

3. AIOps and Predictive Analytics

AIOps refers to applying machine learning, analytics, and automation to IT operations. An AIOps platform commonly ingests logs, metrics, traces, events, topology information, deployment records, and incident tickets. It may normalise data, correlate related events, detect anomalies, identify probable causes, and recommend or execute actions.

3.1 Observability data as the foundation

Observability asks whether a system’s internal state can be inferred from its outputs. The principal signals are:

• Metrics: numerical time-series measurements such as latency or CPU utilisation.
• Logs: timestamped records of events.
• Traces: records of a request’s path across services.
• Profiles: measurements of where a program spends computational resources.
• Events: discrete changes such as deployments, configuration updates, or alerts.

AI is only as reliable as the data supplied to it. Missing timestamps, inconsistent service names, duplicated events, high-cardinality labels, and changes in instrumentation can produce misleading results. Data governance must therefore include ownership, retention, access control, quality checks, and semantic consistency.

3.2 Anomaly detection

An anomaly is an observation that differs materially from an expected pattern. In a simple statistical model, a time-series observation can be compared with a baseline mean and standard deviation. If observations are approximately normally distributed and independent enough for the use case, a standardised score may be calculated as:

Here, x is the observed value, μ is the baseline mean, and σ is the baseline standard deviation, all in the same units. A large absolute value of z may indicate unusual behaviour. This method is inappropriate when the data is strongly seasonal, non-stationary, heavily skewed, or autocorrelated unless the baseline is adjusted. In practice, robust baselines, seasonal models, quantile thresholds, or learned models may be preferable.

Anomaly detection is not the same as incident detection. A legitimate traffic increase may be statistically unusual but operationally healthy. Conversely, a slow degradation may remain within a broad statistical range while violating a service-level objective (SLO). Detection should therefore combine statistical signals with business and reliability context.

3.3 Predictive analytics

Predictive analytics estimates a future event or value. Examples include forecasting request volume, predicting capacity exhaustion, estimating incident probability, and identifying deployments associated with elevated failure risk.

A model’s predictive quality should be evaluated on data that was not used to train it. Important measures depend on the task. For binary incident prediction, precision and recall are commonly used:

Here, TP represents true positives, FP false positives, and FN false negatives. Precision answers: “Of the alerts raised, how many were correct?” Recall answers: “Of the real incidents, how many were detected?” Increasing one can reduce the other, so the appropriate balance depends on the cost of missed incidents and unnecessary investigations.

A model that performs well during a stable period may fail after an architectural change, a new traffic pattern, or a security attack. This is model drift. Monitoring must therefore include input drift, output quality, false-positive rates, false-negative rates, and operational outcomes.

4. Autonomous Remediation and Human Oversight

Autonomous remediation is the controlled execution of corrective actions in response to detected conditions. Examples include restarting a failed stateless process, scaling a service, clearing a safe temporary cache, or rolling back a deployment that violates a defined health threshold.

A mature remediation loop contains:

1. Detection: identify a symptom or predicted condition.
2. Diagnosis: determine likely causes and confidence.
3. Decision: select an action permitted by policy.
4. Execution: run a version-controlled, idempotent action.
5. Verification: confirm that the condition improved.
6. Escalation: stop and involve a human if confidence is low or impact is high.
7. Learning: record the outcome for later analysis.

Idempotence is important: repeating an action should produce the same intended state rather than accumulating damage. Every action should have a timeout, rollback or recovery plan where feasible, an audit trail, and a clear owner.

A useful autonomy classification is:

Human oversight is not merely a final click. People must define acceptable risk, approve policies, inspect evidence, test runbooks, review exceptions, and retain authority to suspend automation. Excessive reliance on automation can create deskilling and automation bias—the tendency to accept machine recommendations without adequate scrutiny.

5. Platform Engineering and Internal Developer Platforms

Platform engineering treats the developer platform as a product. A platform team provides reusable capabilities such as repositories, build templates, deployment workflows, secrets integration, observability, environments, policy checks, and service catalogues. The goal is to reduce cognitive load while preserving engineering autonomy.

An internal developer platform (IDP) should offer a paved road, not an impenetrable mandatory road. Developers should be able to create a service using safe defaults while retaining an escape path for justified exceptions. Platform teams need user research, product management, documentation, service-level objectives, feedback mechanisms, and lifecycle ownership.

AI can enhance an IDP by generating service scaffolds, explaining platform errors, recommending approved components, and detecting configuration drift. However, an AI assistant should draw from curated internal sources and clearly distinguish authoritative policy from suggestion. Platform APIs and templates must be versioned so that generated outputs remain reproducible.

The platform approach supports scale because common security, reliability, and compliance controls are embedded in reusable workflows. It does not eliminate the need for application teams to understand their service’s business risks and operational responsibilities.

6. GitOps as a Control Model

GitOps uses a version-controlled repository as the authoritative declaration of desired system state. An agent continuously compares the declared state with the actual environment and works to reconcile differences. Pull-based reconciliation reduces the need for deployment systems to hold broad direct access to every target environment.

The central concepts are:

• desired state is declarative and stored in Git;
• changes are proposed through reviewable commits or pull requests;
• automated agents reconcile approved state;
• drift is detected and reported; and
• history provides an audit trail and rollback reference.

GitOps complements AI-enabled DevOps. An AI model may generate a change proposal, but Git remains the review and control boundary. Automated policy checks can reject insecure configurations, and progressive delivery can limit the blast radius of an accepted change.

GitOps is not a guarantee of correctness. A malicious or mistaken commit can still declare a dangerous state. Repository permissions, signing, branch protection, environment separation, secret handling, policy-as-code, and monitoring remain necessary.

7. FinOps and Green DevOps

7.1 FinOps

FinOps is an operating discipline for managing technology cost through shared accountability among engineering, finance, product, and leadership. It is not simply cost cutting. The objective is to obtain appropriate business value from cloud and technology expenditure while preserving reliability, security, and delivery speed.

Useful measures include total service cost, cost per transaction, idle-resource cost, forecast variance, commitment utilisation, and cost associated with environments or teams. A general unit-cost measure is:

The numerator and denominator must cover the same period and scope. “Business units” might mean orders, active users, reports, or transactions, but the definition must be stable and meaningful. A lower unit cost is not automatically better if service quality or availability deteriorates.

AI can forecast demand, identify idle resources, recommend instance changes, allocate shared costs, and explain cost anomalies. Risks include aggressive rightsizing, inaccurate forecasts, opaque recommendations, and optimisation that shifts cost rather than reducing it. Changes should be evaluated against performance and reliability objectives.

7.2 Green DevOps

Green DevOps integrates environmental considerations into software design, delivery, and operation. Relevant practices include efficient algorithms, workload scheduling, autoscaling, hardware utilisation, low-carbon-region selection where appropriate, reducing unnecessary builds, extending hardware life, and measuring energy or emissions.

A simplified emissions estimate can be represented as:

Energy may be measured in kilowatt-hours, and emissions intensity in kilograms of carbon-dioxide equivalent per kilowatt-hour, producing kilograms of carbon-dioxide equivalent. This is an estimate, not a universal physical constant. Actual results depend on provider methodology, location, time-varying electricity sources, embodied emissions, hardware allocation, and workload measurement boundaries.

FinOps and green DevOps can conflict with or reinforce one another. Moving workloads to a cheaper region may increase emissions; reducing compute may harm latency; running jobs when electricity is cleaner may delay delivery. Decisions should consider cost, reliability, security, performance, and environmental impact together.

8. Benefits, Risks, and Governance

8.1 Potential benefits

AI-enabled DevOps can:

• reduce time spent on repetitive coding and documentation;
• shorten diagnosis and recovery time;
• improve consistency through standardised platform workflows;
• identify weak signals before they become incidents;
• make operational knowledge more accessible;
• support developers working across unfamiliar technologies; and
• improve resource efficiency when recommendations are carefully validated.

Benefits should be demonstrated through measurable outcomes such as deployment lead time, change failure rate, mean time to recovery, escaped defects, developer experience, cloud cost per transaction, and energy intensity. Activity measures such as the number of AI-generated lines of code are weak indicators of value.

8.2 Technical and organisational risks

Important risks include:

• Hallucination: generated content is plausible but false.
• Data leakage: confidential code, credentials, customer information, or operational data reaches an unauthorised model or log.
• Prompt injection: untrusted content manipulates an AI system’s instructions.
• Excessive privilege: an agent can perform actions beyond its legitimate scope.
• Model drift: performance declines as systems and workloads change.
• Automation bias: humans accept recommendations without verification.
• Correlated failure: many teams use the same model or generated dependency, creating common vulnerabilities.
• Intellectual-property and licence uncertainty: generated code may create legal or compliance questions.
• Workforce displacement and inequality: routine tasks may decline while opportunities shift toward higher-level engineering and governance.

Security controls should include data classification, approved model policies, private processing where required, secret redaction, access control, prompt and output logging subject to privacy rules, software composition analysis, sandboxing, human approval for high-risk actions, and incident response for AI-specific failures.

Governance should define acceptable uses, prohibited uses, accountability, model owners, evaluation procedures, retention rules, supplier requirements, and review frequency. Regulatory obligations vary by jurisdiction and sector, especially where AI affects personal data, employment, safety, finance, or essential services. Organisations should align practice with applicable data-protection, cybersecurity, software-supply-chain, and AI-governance requirements rather than assuming a general-purpose model is automatically compliant.

9. Illustrative Case: AI-Assisted Reliability in an Online Retailer

Background

Consider “Northstar Retail,” a fictional online retailer operating a modular web platform. It has frequent deployments, thousands of service logs, and seasonal traffic. Developers report that incident diagnosis is slow, cloud costs are unpredictable, and platform configuration differs between teams.

Problem

The company wants AI to improve reliability without permitting an agent to make unrestricted production changes. Previous alerting produced many duplicate notifications, and a proposed automatic scaling system sometimes reacted to short-lived traffic spikes.

Analysis

The reliability team first maps data sources, identifies service ownership, and defines measurable outcomes: fewer duplicate alerts, lower time to recovery, stable response-time SLOs, and improved cost visibility. It discovers inconsistent metric names and missing deployment metadata. The team concludes that data quality must be improved before sophisticated prediction is trusted.

Approach and solution

Northstar implements the following design:

1. Standardised telemetry naming, trace correlation, and deployment annotations.
2. An AIOps correlation service that groups related alerts and presents likely causes.
3. An internal platform with approved service templates, security scanning, observability defaults, and cost labels.
4. GitOps repositories for environment declarations and policy checks.
5. A generative assistant restricted to code explanation, test drafting, incident summarisation, and pull-request proposals.
6. A narrow remediation policy allowing automatic restart of a stateless worker only when health checks fail, the action is idempotent, and the restart budget has not been exceeded.
7. Human approval for database changes, network changes, security-policy changes, and production rollbacks.
8. FinOps dashboards showing cost per completed order and idle-resource trends.

The company evaluates predictions using a holdout period and monitors false positives, false negatives, alert volume, and SLO impact. Every automated action creates an audit record and can be disabled centrally.

Outcome

The principal improvement is not the model alone. Standardised telemetry and platform defaults make operational data more useful and reduce variation. Engineers spend less time grouping alerts and more time addressing recurring causes. The organisation also rejects several proposed AI actions because evidence is insufficient, demonstrating that disciplined non-automation is sometimes the correct result.

Learning points

• AI value depends on reliable data and clear ownership.
• GitOps provides a reviewable boundary for generated changes.
• Low-risk, reversible actions are better candidates for early autonomy.
• Cost and environmental metrics must be connected to business output.
• Human oversight includes designing constraints and evaluating outcomes, not merely approving individual clicks.

10. Future Directions and Career Implications

Future DevOps environments are likely to become more conversational, policy-aware, and autonomous. Engineers may describe an operational goal in natural language, while platforms generate infrastructure, tests, observability configuration, and deployment plans. Multi-agent systems may divide work among planning, coding, testing, security, and operations agents. Digital twins and simulation environments may permit proposed changes to be tested before production.

These developments create both opportunity and uncertainty. Generated systems may become faster to build but harder to understand. Organisations may move from managing servers and pipelines directly to managing platforms, policies, models, data, and trust boundaries. The ability to explain a system’s behaviour will become as important as the ability to deploy it.

Future DevOps professionals should develop:

• software engineering and systems design;
• cloud, networking, containers, and observability;
• statistics and experimental evaluation;
• data governance and model-risk awareness;
• secure software supply-chain practice;
• policy-as-code and infrastructure-as-code;
• FinOps and sustainability literacy;
• communication, incident leadership, and ethical reasoning; and
• the ability to collaborate with AI while independently verifying its output.

The most valuable professionals will not be those who blindly automate the most tasks. They will be those who can identify suitable boundaries, construct reliable feedback loops, measure real outcomes, and preserve human accountability in complex sociotechnical systems.

Best-Practice Checklist

Before adopting an AI capability in DevOps, an organisation should ask:

1. What measurable problem is being solved?
2. What data does the system require, and is that data accurate and authorised?
3. What are the consequences of a wrong recommendation or action?
4. Can the output be tested, reviewed, reversed, and audited?
5. What permissions and environment boundaries are required?
6. How will drift, bias, security incidents, and degraded performance be detected?
7. Which decisions require human approval?
8. How will cost, reliability, security, developer experience, and environmental impact be evaluated together?
9. Who owns the model, platform integration, and operational outcome?
10. What is the process for retiring the capability when it no longer provides value?

Chapter Summary

AI-enabled DevOps applies generative models, machine learning, analytics, and controlled automation to software delivery and operations. Generative AI can assist with coding, tests, documentation, pipeline configuration, and incident summaries, but generated output must be treated as an untrusted draft and validated through engineering controls.

AIOps uses operational data to correlate events, detect anomalies, predict incidents, and recommend actions. Predictive performance must be measured using appropriate metrics such as precision and recall, while data quality, drift, and changing system conditions are actively monitored. Autonomous remediation is safest when actions are narrow, reversible, idempotent, policy-constrained, and auditable.

Platform engineering provides reusable, product-oriented internal developer capabilities. GitOps supplies a declarative, reviewable control model in which AI-generated changes can be inspected before reconciliation. FinOps connects technology expenditure to business value, while green DevOps considers energy and emissions alongside cost, reliability, and performance.

The benefits of AI include reduced repetitive work, faster diagnosis, improved standardisation, and more informed decisions. Risks include hallucination, data leakage, prompt injection, excessive privilege, model drift, automation bias, intellectual-property uncertainty, and workforce disruption. Effective adoption requires human oversight, least privilege, governance, testing, observability, auditability, and clear accountability. Future DevOps careers will combine software and cloud engineering with data literacy, security, sustainability, platform thinking, and ethical judgment.

Key Terms

AIOps: Application of AI and analytics to IT operations and service management.

Anomaly detection: Identification of observations that differ from an expected pattern.

Automation bias: The tendency to trust an automated recommendation without adequate verification.

Autonomous remediation: Controlled automatic execution of corrective operational actions.

Emissions intensity: Environmental emissions associated with a unit of energy or activity.

FinOps: Collaborative discipline for managing technology cost and business value.

GitOps: Declarative operations model using Git as the authoritative source of desired state.

Green DevOps: Integration of environmental efficiency into software delivery and operations.

Hallucination: A plausible but incorrect or unsupported AI-generated output.

Human-in-the-loop: A design in which a person reviews or authorises specified system decisions.

Internal developer platform: A product-oriented platform providing reusable developer and operational capabilities.

Idempotence: Property whereby repeating an operation produces the same intended resulting state.

Large language model: A model trained to predict and generate sequences of language tokens.

Model drift: Decline in model performance as data, systems, or conditions change.

Observability: Ability to infer internal system state from outputs such as metrics, logs, and traces.

Prompt injection: Manipulation of an AI system through untrusted or adversarial instructions.

Progressive delivery: Gradual release of software to limit exposure and evaluate behaviour.

Retrieval-augmented generation: Generation supported by retrieving relevant external or organisational information.

Service-level objective: A target for a service reliability or performance measure.

Policy-as-code: Expressing operational, security, or compliance rules in machine-evaluable form.

Review Questions

5 Short Answer Questions

1. How does AI-enabled DevOps differ from rule-based automation?
2. Why should generated source code be treated as an untrusted draft?
3. What are the principal signals used in observability?
4. Define model drift and explain why it matters in AIOps.
5. Why is idempotence valuable in autonomous remediation?

5 Long Answer Questions

1. Explain how generative AI can support the software delivery lifecycle, and discuss the controls required to use it safely.
2. Describe an AIOps architecture from data ingestion through anomaly detection, diagnosis, recommendation, and remediation.
3. Compare platform engineering and GitOps, and explain how they can work together in an enterprise.
4. Discuss the relationship among FinOps, green DevOps, reliability, and business value.
5. Evaluate the ethical, security, organisational, and workforce implications of AI-enabled DevOps.

3 Analytical / Application Questions

1. Design a human-supervised remediation policy for a service that experiences intermittent failures. Identify permitted actions, escalation conditions, audit requirements, and success measures.
2. An organisation reports excellent predictive accuracy during testing but many false alerts after a major architecture change. Analyse possible causes and propose an evaluation and monitoring plan.
3. A cloud team can reduce cost by moving batch workloads to another region, but that region has higher emissions intensity and longer data-transfer paths. Develop a decision framework that incorporates cost, performance, reliability, security, and environmental impact.

Multiple Choice Questions with Answers

Question 1

Which statement best describes AI-enabled DevOps?

A. It replaces all human decisions in software delivery.

B. It combines automation with learned patterns, generation, prediction, and controlled decision support.

C. It is limited to using chatbots for customer support.

D. It removes the need for testing because models validate their own output.

Correct Answer: B. It combines automation with learned patterns, generation, prediction, and controlled decision support.

Question 2

What is the main reason generated code must be reviewed and tested?

A. Generated code can be plausible while being incorrect or insecure.

B. Generated code can never compile.

C. Generated code is always slower than manually written code.

D. Testing is unnecessary for human-written code but required only for AI code.

Correct Answer: A. Generated code can be plausible while being incorrect or insecure.

Question 3

In the expression z = (x − μ) ÷ σ, what does σ represent?

A. The observed value

B. The baseline mean

C. The baseline standard deviation

D. The prediction error count

Correct Answer: C. The baseline standard deviation

Question 4

Which action is the best candidate for early autonomous remediation?

A. Changing a production database schema without approval

B. Modifying firewall policy across all environments

C. Restarting a failed stateless worker under a narrow, reversible policy

D. Deleting records identified by an AI model as obsolete

Correct Answer: C. Restarting a failed stateless worker under a narrow, reversible policy

Question 5

What is the defining control principle of GitOps?

A. Production state is changed only through manual server access.

B. Git stores the desired declarative state and an agent reconciles the environment.

C. AI directly modifies production without a history of changes.

D. All infrastructure is configured through spreadsheets.

Correct Answer: B. Git stores the desired declarative state and an agent reconciles the environment.

Question 6

What does recall measure in binary incident prediction?

A. The proportion of raised alerts that are correct

B. The proportion of real incidents that are detected

C. The number of deployments completed per day

D. The average time required to train a model

Correct Answer: B. The proportion of real incidents that are detected

Question 7

Which practice is most characteristic of platform engineering?

A. Providing reusable, product-oriented internal developer capabilities

B. Requiring every team to build its own deployment system

C. Eliminating developer feedback from platform design

D. Replacing version control with manual configuration

Correct Answer: A. Providing reusable, product-oriented internal developer capabilities

Question 8

Why should an AI remediation agent have least privilege?

A. To maximise the number of actions it can perform

B. To reduce the consequences of an incorrect or compromised action

C. To prevent audit records from being created

D. To ensure that all changes bypass human review

Correct Answer: B. To reduce the consequences of an incorrect or compromised action

Question 9

What is a key limitation of using a simple z-score anomaly detector?

A. It cannot use numerical data.

B. It is always more accurate than learned models.

C. It may be inappropriate for strongly seasonal, skewed, or non-stationary data without adjustment.

D. It requires no baseline information.

Correct Answer: C. It may be inappropriate for strongly seasonal, skewed, or non-stationary data without adjustment.

Question 10

Which statement best expresses the purpose of FinOps?

A. Minimising cost regardless of reliability or business outcomes

B. Managing technology expenditure collaboratively in relation to business value

C. Measuring only the number of cloud resources deployed

D. Moving every workload to the cheapest available region

Correct Answer: B. Managing technology expenditure collaboratively in relation to business value