Cloud Economics, FinOps and Sustainability

Introduction and Context

Cloud computing changes the economics of artificial intelligence and machine learning (AI/ML). Instead of purchasing servers, organizations obtain computing, storage, networking, and managed services on demand. This flexibility can reduce capital expenditure and accelerate experimentation, but it can also create unpredictable operating expenditure. AI workloads are especially sensitive to economic decisions because model training may require large accelerator clusters, while inference may run continuously at high request volumes.

Cloud economics is therefore more than comparing hourly prices. It involves understanding total cost of ownership (TCO), pricing models, utilization, performance, reliability, data movement, labor, governance, and business value. FinOps is the organizational and operational discipline that connects engineering, finance, procurement, and business teams so that cloud spending produces measurable value. Sustainability extends this analysis by considering energy use, carbon emissions, hardware lifecycles, and environmental trade-offs.

A sound economic decision does not necessarily select the cheapest virtual machine. It selects an architecture and operating model that meet performance, reliability, security, and regulatory requirements at an acceptable financial and environmental cost.

Learning Objectives

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

1. Explain cloud cost structures and major pricing models.

2. Estimate TCO for cloud and on-premises AI/ML alternatives.

3. Calculate utilization, unit economics, budgets, and cost variance.

4. Analyze compute, accelerator, storage, and data-transfer costs.

5. Apply FinOps practices to allocation, forecasting, optimization, and governance.

6. Compare cloud vendors using economic and non-economic criteria.

7. Explain carbon-aware computing and sustainability metrics.

8. Evaluate trade-offs among cost, performance, reliability, and environmental impact.

1. The Economics of Cloud AI/ML

1.1 Cost categories

A cloud AI/ML system usually has the following cost categories:

• Compute: virtual machines, containers, serverless execution, CPUs, GPUs, TPUs, and other accelerators.
• Storage: object storage, block storage, file systems, snapshots, backups, and database storage.
• Data transfer: traffic between regions, availability zones, the public internet, and external systems.
• Managed services: databases, data warehouses, orchestration, monitoring, model hosting, and security services.
• Software and licenses: commercial development tools, operating systems, model-serving platforms, and support plans.
• Labor: engineers, data scientists, platform teams, security specialists, and FinOps practitioners.
• Risk and compliance: security controls, audit requirements, disaster recovery, and regulatory obligations.
• Opportunity cost: delays caused by scarce accelerators, migration effort, or engineering complexity.

Cloud invoices commonly show direct consumption but do not automatically reveal all associated costs. For example, a training job may use inexpensive object storage but incur substantial data-transfer charges, logging costs, orchestration costs, and staff time.

1.2 Capital expenditure and operating expenditure

Traditional infrastructure is dominated by capital expenditure (CapEx): hardware is purchased in advance and depreciated over time. Cloud infrastructure is primarily operating expenditure (OpEx): resources are paid for as services are consumed. This distinction affects cash flow, accounting, procurement, and risk.

Cloud does not eliminate fixed costs. Reserved capacity commitments, minimum contractual spending, support plans, dedicated connectivity, and platform engineering teams may behave like fixed or semi-fixed costs. Conversely, on-premises infrastructure also includes variable costs such as electricity, replacement parts, and staffing. A meaningful comparison must therefore examine the full service cost rather than only the server purchase price.

2. Total Cost of Ownership

2.1 A practical TCO model

For a defined period, a general TCO model is:

\[

TCO = C_{compute}+C_{storage}+C_{network}+C_{services}+C_{licenses}+C_{labor}+C_{facilities}+C_{risk}

\]

where each term represents the cost incurred during the analysis period. Costs should use the same currency, time period, and scope. For example, a monthly cloud TCO should not be compared with an annual on-premises hardware price unless the hardware price is annualized.

For on-premises infrastructure, annualized hardware cost can be estimated as:

\[

Annualized\ hardware\ cost = \frac{Purchase\ price - Residual\ value}{Useful\ life\ in\ years}

\]

This straight-line estimate assumes uniform economic consumption and ignores financing costs. A more detailed accounting analysis may use an organization’s approved depreciation method.

A cloud TCO estimate may be expressed as:

\[

C_{cloud}=H r + S p_s + D p_d + M + L

\]

where:

• \(H\) is billable compute-unit time, such as instance-hours;
• \(r\) is the applicable compute price per unit;
• \(S\) is storage quantity multiplied by time;
• \(p_s\) is the storage price;
• \(D\) is billable data transfer;
• \(p_d\) is the transfer price;
• \(M\) is managed-service cost; and
• \(L\) is labor and other allocated costs.

This is an estimation model, not a universal billing formula. Actual pricing may include tiered rates, minimums, discounts, regional differences, taxes, free tiers, and separate charges for operations or requests.

2.2 Worked TCO example

Consider an illustrative six-month AI training project. It uses 8 accelerator instances for 240 hours per month at $3.20 per instance-hour. Storage averages 20 TB at $0.023 per GB-month, using decimal conversion of 1 TB = 1,000 GB for this estimate. Data transfer is 5 TB per month at $0.09 per GB. Managed services cost $450 per month, and allocated engineering labor costs $6,000 per month.

Monthly compute cost:

\[

8 \times 240 \times 3.20 = \$6,144

\]

Monthly storage cost:

\[

20 \times 1,000 \times 0.023 = \$460

\]

Monthly transfer cost:

\[

5 \times 1,000 \times 0.09 = \$450

\]

Monthly total:

\[

6,144+460+450+450+6,000=\$13,504

\]

Six-month TCO:

\[

6 \times 13,504 = \$81,024

\]

The result depends on the assumptions. If the provider uses binary units, if transfer is priced differently by destination, or if instances are interrupted, the estimate changes. A professional estimate should document assumptions and include a sensitivity analysis.

2.3 TCO versus total economic impact

TCO measures cost, but decision makers may also need to estimate value. Useful measures include time to deploy, model quality, revenue, avoided labor, service reliability, and time saved by researchers. A low-cost system that takes three months longer to deliver may have lower TCO but lower business value. Economic analysis should therefore distinguish:

• Cost efficiency: resources used per unit of output.
• Cost effectiveness: cost relative to achieving a required outcome.
• Return on investment: value gained relative to investment, using the organization’s chosen financial definition.

These measures should not be conflated. A system can be cost-efficient but ineffective if it produces poor predictions.

3. Cloud Pricing and Billing Models

3.1 On-demand pricing

On-demand resources are paid for without a long-term commitment. They provide flexibility and are appropriate for uncertain workloads, prototypes, burst demand, and early experiments. Their disadvantages are higher unit prices and exposure to price variation or capacity shortages.

3.2 Commitment-based discounts

Reserved instances, savings plans, committed-use contracts, and enterprise agreements reduce prices in exchange for a usage or spending commitment. Their economic benefit depends on utilization. A commitment is appropriate when demand is sufficiently predictable and the organization can tolerate underutilization.

A simple break-even analysis compares discounted and on-demand cost. If a commitment costs \(C_c\) for a period and on-demand usage would cost \(C_o\), the nominal saving is:

\[

Saving = C_o-C_c

\]

The analysis must also include unused commitment, flexibility restrictions, cancellation terms, and alternative uses of the capital or contract capacity.

3.3 Spot, preemptible, and interruptible capacity

Interruptible capacity is offered at a discount but may be stopped by the provider. It is often suitable for checkpointed training, batch feature generation, hyperparameter searches, and fault-tolerant data processing. It is less suitable for latency-sensitive inference or jobs that cannot resume safely.

The engineering requirement is not merely selecting a cheaper instance. The workload must support checkpointing, retry logic, idempotence, state recovery, and graceful termination. The effective cost includes interruption-related delays and engineering effort.

3.4 Serverless and managed pricing

Serverless platforms may charge per request, execution duration, memory allocation, provisioned capacity, or a combination. Managed AI services may charge per prediction, token, training job, endpoint hour, or data volume. They reduce operational labor but can create less visibility into underlying resource use. A managed service should be evaluated on total delivered cost, portability, service quality, and lock-in risk.

3.5 Billing dimensions and cost allocation

Cloud bills may contain dimensions such as account, project, subscription, region, service, resource, operation, usage type, and tag. Allocation requires consistent metadata. Useful tags include owner, application, environment, cost center, model, customer, and data classification.

Shared resources require allocation rules. A GPU cluster, data platform, or observability system may be allocated by actual usage, reserved capacity, headcount, revenue, or an agreed hybrid method. The rule should be transparent and stable enough to influence behavior without creating false precision.

4. Utilization and AI/ML Unit Economics

4.1 Resource utilization

Utilization is the proportion of available capacity that performs useful work. A basic measure is:

\[

Utilization = \frac{Useful\ busy\ time}{Available\ capacity\ time}

\]

The result is dimensionless and often reported as a percentage. GPU utilization reported by a monitoring tool may measure hardware activity, but high utilization does not guarantee useful throughput. Memory bottlenecks, input pipeline delays, synchronization, and inefficient kernels can reduce useful work.

For an accelerator, distinguish:

• Allocated utilization: time the accelerator is assigned to a job.
• Hardware utilization: time computational units are active.
• Effective utilization: useful completed work divided by available capacity.

4.2 Cost per training run and cost per experiment

Suppose a training cluster costs $12 per accelerator-hour, uses 4 accelerators for 10 hours, and has $80 of associated storage and orchestration cost:

\[

Training\ run\ cost = 12 \times 4 \times 10 + 80 = \$560

\]

If only one of five runs produces a model suitable for evaluation, the cost per successful candidate is not necessarily $560; under an equal-cost assumption it is:

\[

\frac{5 \times 560}{1}=\$2,800

\]

This illustrates why experiment tracking matters. Cost per run can encourage cheap experiments, while cost per successful result better reflects research productivity.

4.3 Inference unit economics

For an inference service, a useful metric is cost per 1,000 requests:

\[

Cost\ per\ 1,000\ requests = \frac{Total\ inference\ cost}{Number\ of\ requests}\times 1,000

\]

Assume an endpoint costs $720 per month and serves 2,400,000 requests. Then:

\[

\frac{720}{2,400,000}\times 1,000 = \$0.30

\]

This calculation must state whether it includes only endpoint compute or also networking, storage, monitoring, preprocessing, and engineering. For generative AI, organizations may use cost per 1,000 tokens, but token counts, model versions, input-output ratios, caching, and provider pricing must be specified.

4.4 Optimization levers

Important optimization techniques include:

• right-sizing CPU, memory, and accelerator types;
• increasing batch size where latency permits;
• using mixed-precision arithmetic when accuracy remains acceptable;
• improving data-loader and storage throughput;
• batching or dynamically batching inference requests;
• autoscaling based on demand and queue depth;
• shutting down idle development endpoints;
• using model quantization, pruning, distillation, or smaller architectures;
• using caching for repeated results;
• selecting regions and services with appropriate transfer costs; and
• scheduling flexible workloads during lower-cost or lower-carbon periods.

Optimization must be measured against quality, latency, reliability, and safety. Reducing model size may lower cost but worsen fairness or accuracy for underrepresented cases.

5. FinOps as an Operating Model

FinOps is a continuous management practice rather than a one-time cost-cutting project. It generally connects three perspectives:

• Engineering: understands architecture, workload behavior, and technical trade-offs.
• Finance: manages budgets, accounting treatment, forecasts, and financial controls.
• Business: defines value, customer outcomes, priorities, and acceptable service levels.

A useful FinOps lifecycle has three recurring activities:

1. Inform: provide visibility, allocation, budgets, forecasts, unit metrics, and accountability.

2. Optimize: improve rates, resource efficiency, architecture, and workload scheduling.

3. Operate: establish policies, targets, governance, decision rights, and continuous review.

5.1 Budgets and forecasting

A budget is a planned financial limit; a forecast is the current estimate of future spending. A simple forecast may be:

\[

Forecast = Actual\ to\ date + Expected\ remaining\ spend

\]

If an organization has spent $42,000 in the first two months of a quarter and expects $25,000 in the remaining month, the forecast is $67,000. This is a basic estimate and assumes the remaining-spend assumption is credible.

Variance is:

\[

Variance = Actual - Budget

\]

A positive variance may mean overspending, although organizations sometimes define favorable and unfavorable signs differently. Reports must state the convention. Variance analysis should investigate causes such as new experiments, traffic growth, idle resources, pricing changes, or incorrect allocation.

5.2 Showback and chargeback

Showback reports costs to teams without directly charging their budgets. It builds awareness and is often suitable during FinOps maturity development. Chargeback transfers costs to the responsible business unit. It can increase accountability but may encourage harmful behavior if allocation is inaccurate or teams avoid necessary reliability and security spending.

5.3 Governance controls

Practical controls include spending alerts, quota limits, approval workflows for expensive accelerators, automatic expiration of temporary resources, policy-as-code, anomaly detection, and mandatory ownership metadata. Controls should be proportional to risk. A research environment needs flexibility, while a production environment may require stricter approval and segregation of duties.

6. Vendor Evaluation and Economic Trade-offs

Vendor comparison should use a workload-specific scorecard rather than a single hourly price. Relevant criteria include:

• sustained and burst performance;
• accelerator availability and regional capacity;
• on-demand, committed, and interruptible pricing;
• storage and data-transfer costs;
• managed-service capabilities;
• security, identity, privacy, and compliance;
• service-level agreements and support;
• ecosystem and staff skills;
• interoperability and portability;
• contractual terms and exit costs; and
• energy and carbon transparency.

A multi-cloud strategy may improve bargaining power or resilience, but it can also duplicate skills, monitoring, security controls, and data pipelines. Portability is not free. Abstraction layers may reduce lock-in but can prevent use of specialized hardware or provider-specific optimization.

A fair benchmark controls for model version, dataset, accuracy target, batch size, precision, latency, failure rate, and software stack. Comparing two providers using different batch sizes or different quality targets produces misleading results.

7. Sustainability and Carbon-Aware Computing

7.1 Environmental dimensions

Sustainability includes more than electricity. Important dimensions are:

• operational carbon emissions from electricity use;
• embodied carbon from manufacturing and disposing of hardware;
• water consumption associated with energy generation and cooling;
• hardware utilization and life extension;
• electronic waste; and
• indirect impacts of data-center construction and supply chains.

Cloud providers may publish carbon estimates, but methodologies and boundaries differ. Results should therefore be treated as estimates rather than perfectly comparable measurements.

7.2 Energy and emissions estimation

A simplified operational-emissions estimate is:

\[

Emissions\ (kgCO_2e)=Energy\ (kWh)\times Emissions\ factor\ (kgCO_2e/kWh)

\]

If a workload consumes 1,200 kWh and the applicable emissions factor is 0.35 kgCO₂e/kWh:

\[

1,200\times0.35=420\ kgCO_2e

\]

This estimate assumes the energy and emissions factor are measured over compatible geographic and time boundaries. It may exclude embodied emissions and upstream impacts. Power usage effectiveness (PUE) can be incorporated when only IT energy is known:

\[

Facility\ energy = IT\ energy \times PUE

\]

If IT energy is 1,000 kWh and PUE is 1.2, estimated facility energy is 1,200 kWh. PUE does not itself measure carbon intensity or water use.

7.3 Carbon-aware strategies

Carbon-aware computing uses information about electricity carbon intensity to choose when or where flexible workloads run. Suitable strategies include moving batch training to a lower-carbon region, scheduling non-urgent jobs during cleaner periods, improving utilization, and reducing unnecessary retraining. However, geographic movement can increase latency, data-transfer cost, sovereignty risk, or water consumption. Carbon optimization must be evaluated together with service requirements and legal constraints.

A carbon-aware policy should define workload flexibility, maximum delay, approved regions, data restrictions, and fallback behavior when low-carbon capacity is unavailable.

8. Illustrative Case: A University Medical-Imaging Platform

Background

A fictional university research center develops a chest-imaging classifier. Researchers train models intermittently, while a clinical research portal provides continuous inference. The center initially runs eight GPU instances continuously because a development team fears losing capacity.

Problem

Monthly cloud spending reaches $31,000. Monitoring shows that GPUs are actively computing only 28% of allocated time. Storage contains duplicate datasets, development endpoints remain online overnight, and every experiment is charged to one general project. The center also has a sustainability target but no workload-level emissions estimate.

Analysis

The FinOps team separates costs into training, inference, storage, networking, and shared platform services. It adds tags for laboratory, model, environment, and grant. Training logs are connected to experiment identifiers. Measurements show that training is flexible, whereas inference requires predictable latency. The team also discovers that some experiments use CPU-based preprocessing that starves the GPUs.

Approach and solution

The center applies the following changes:

1. Development endpoints automatically stop after two hours of inactivity.

2. Training jobs use checkpointing and interruptible capacity where appropriate.

3. A queue schedules flexible experiments and limits simultaneous jobs.

4. Data deduplication and lifecycle policies move old datasets to lower-cost storage.

5. The input pipeline is optimized so accelerators receive data continuously.

6. Inference is separated from training and scaled according to request volume.

7. Monthly reports show cost per training run, cost per successful model candidate, and inference cost per 1,000 requests.

8. A regional scheduling policy considers carbon intensity, data residency, and transfer cost.

9. A budget alert is triggered when forecast spending exceeds 90% of the grant allocation.

Outcome

In this illustrative case, the center reduces monthly spending to $21,500 while maintaining the required inference latency and model-quality threshold. Effective accelerator utilization rises from 28% to 61%. The center does not claim that all savings are permanent: increased research demand could raise total spending. Instead, it establishes unit metrics and capacity governance so that additional spending can be linked to additional research output.

Learning points

The case demonstrates that economic improvement comes from measurement, architecture, scheduling, and accountability together. A cheaper accelerator would not have solved idle development endpoints or inefficient data loading. It also shows that sustainability and cost may align through better utilization, but they can conflict when a lower-carbon region has higher transfer charges or weaker service performance.

9. Challenges, Ethics, and Governance

Cloud cost optimization can create ethical and operational risks. Automated shutdown policies may interrupt accessibility research or erase temporary data. Aggressive model compression may reduce performance for minority populations. Cost-based regional placement may conflict with privacy, sovereignty, or equitable access. Carbon accounting may encourage misleading claims if boundaries and assumptions are hidden.

Governance should address:

• data residency and cross-border transfer;
• privacy and sector-specific regulation;
• procurement and contractual accountability;
• auditability of billing and emissions estimates;
• accessibility and fairness impacts of optimization;
• retention and deletion of datasets and logs;
• security consequences of multi-tenant or interruptible resources; and
• human approval for high-impact cost or model-quality changes.

Financial controls must not override safety controls. Production systems should preserve required availability, monitoring, backup, and security even when budgets are constrained.

10. Contemporary Developments and Best Practices

AI economics is evolving rapidly. Foundation-model training and inference have made accelerator supply, token pricing, energy demand, and model efficiency strategic concerns. Techniques such as parameter-efficient fine-tuning, retrieval-augmented generation, quantization, speculative decoding, model routing, and specialized inference hardware can change cost and performance. Their benefits depend on workload characteristics and should be validated experimentally.

Best practices include:

1. Define the business or research unit of value before optimizing.

2. Establish ownership metadata for every significant resource.

3. Separate training, development, and production environments.

4. Measure useful throughput, not merely allocated capacity.

5. Use commitments only for predictable baseline demand.

6. Design interruptible jobs with checkpointing and retry logic.

7. Include labor, networking, monitoring, and data lifecycle costs in TCO.

8. Use budgets and forecasts as decision tools rather than punishment mechanisms.

9. Benchmark vendors using identical quality and performance conditions.

10. Report sustainability boundaries, assumptions, and uncertainty.

11. Review optimization effects on accuracy, fairness, reliability, privacy, and security.

12. Revisit economic assumptions when models, traffic, prices, or regulations change.

Chapter Summary

Cloud economics for AI/ML requires a complete view of compute, accelerators, storage, networking, managed services, labor, risk, and value. TCO analysis must use consistent periods, units, assumptions, and scope. Pricing models—including on-demand, commitments, and interruptible capacity—create different trade-offs among flexibility, discount, and utilization.

FinOps provides an operating model in which engineering, finance, and business teams inform, optimize, and operate cloud resources together. Budgets, forecasts, allocation, unit economics, anomaly detection, and governance make spending visible and actionable. AI-specific measures include cost per experiment, cost per successful model candidate, accelerator utilization, and inference cost per request or token.

Sustainability analysis extends economic reasoning to energy, carbon, water, hardware, and lifecycle impacts. Carbon estimates require clear boundaries and emissions factors. Carbon-aware scheduling can reduce impact for flexible workloads, but must be balanced against latency, transfer cost, data sovereignty, reliability, and water use.

The central professional principle is optimization under constraints: the best cloud design is not simply the cheapest or lowest-carbon design, but the one that delivers required outcomes responsibly, efficiently, transparently, and sustainably.

Key Terms

Cloud economics: Study of the costs, incentives, and value associated with cloud-based resources and services.

FinOps: Collaborative discipline connecting engineering, finance, and business management of cloud costs.

Total cost of ownership (TCO): Complete cost of acquiring, operating, supporting, and retiring a system over a defined period.

Capital expenditure (CapEx): Spending on assets acquired for long-term use.

Operating expenditure (OpEx): Ongoing spending for operational goods and services.

On-demand pricing: Consumption pricing without a long-term capacity commitment.

Commitment discount: Reduced price obtained by agreeing to a specified usage or spending level.

Interruptible capacity: Discounted capacity that the provider may stop or reclaim.

Utilization: Proportion of available capacity used for useful work.

Unit economics: Cost and value measured per operational unit, such as request, token, or training run.

Showback: Reporting costs to teams without directly charging their budgets.

Chargeback: Assigning costs directly to responsible teams or business units.

Forecast: Current estimate of future spending based on actuals and expected usage.

Power usage effectiveness (PUE): Ratio of total data-center energy to IT equipment energy.

Operational carbon: Emissions associated with energy consumed during system operation.

Embodied carbon: Emissions associated with manufacturing, transporting, and disposing of equipment.

Carbon intensity: Emissions associated with a unit of electricity, commonly kgCO₂e/kWh.

Carbon-aware computing: Scheduling or locating workloads using information about electricity carbon intensity.

Right-sizing: Matching resource capacity to actual workload requirements.

Vendor lock-in: Difficulty or cost of moving workloads, data, or services to another provider.

Review Questions

Short Answer Questions

1. What cost categories should be included in an AI/ML cloud TCO estimate?

2. Distinguish on-demand, committed, and interruptible cloud pricing.

3. Why is allocated accelerator time different from effective utilization?

4. What are showback and chargeback?

5. Define operational carbon and embodied carbon.

Long Answer Questions

1. Explain how an organization can establish a FinOps operating model for AI/ML workloads.

2. Discuss the factors that should be included when comparing two cloud vendors for model training.

3. Explain why cloud cost optimization must consider performance, reliability, security, and model quality.

4. Describe how budgets, forecasts, allocation metadata, and anomaly detection support cloud governance.

5. Discuss the opportunities and limitations of carbon-aware computing.

Analytical / Application Questions

1. A training job uses six accelerators for 18 hours at $2.50 per accelerator-hour and incurs $110 of storage and orchestration cost. Calculate the total job cost. If four equally costly jobs are required to obtain one acceptable model, calculate the cost per acceptable model.

2. A service costs $1,050 per month and serves 3,500,000 requests. Calculate its cost per 1,000 requests. State two additional costs that should be investigated before using this as a complete unit-economic measure.

3. A workload consumes 900 kWh in a region with an emissions factor of 0.42 kgCO₂e/kWh. Estimate operational emissions and recommend two actions that could reduce emissions without violating data-residency requirements.

Multiple Choice Questions with Answers

Question 1

Which item is most directly included in a comprehensive cloud TCO estimate?

A. Only virtual-machine hourly charges

B. Compute, storage, networking, services, labor, and relevant risk costs

C. Only the initial hardware purchase price

D. Only the provider’s advertised discount

Correct Answer: B. Compute, storage, networking, services, labor, and relevant risk costs

Question 2

A workload uses 4 accelerators for 10 hours at $12 per accelerator-hour and incurs $80 of other costs. What is the total cost?

A. $480

B. $560

C. $620

D. $1,280

Correct Answer: B. $560

Question 3

Which workload is generally most suitable for interruptible capacity?

A. A latency-critical production endpoint

B. A checkpointed hyperparameter search

C. A regulated database with no failover

D. A real-time emergency alert service

Correct Answer: B. A checkpointed hyperparameter search

Question 4

What does effective accelerator utilization measure most closely?

A. The time an accelerator is assigned to a project

B. The percentage of the invoice covered by a discount

C. Useful completed work relative to available capacity

D. The number of users registered on the platform

Correct Answer: C. Useful completed work relative to available capacity

Question 5

A service costs $720 and serves 2,400,000 requests in a month. What is its compute cost per 1,000 requests?

A. $0.03

B. $0.30

C. $3.00

D. $30.00

Correct Answer: B. $0.30

Question 6

Which activity belongs primarily to the Inform stage of FinOps?

A. Deleting all production backups

B. Providing allocation, forecasts, budgets, and unit-cost visibility

C. Replacing every workload with a smaller model

D. Moving all data to another provider

Correct Answer: B. Providing allocation, forecasts, budgets, and unit-cost visibility

Question 7

If actual spending is $42,000 and expected remaining spending is $25,000, what is the simple forecast?

A. $17,000

B. $25,000

C. $42,000

D. $67,000

Correct Answer: D. $67,000

Question 8

If IT energy is 1,000 kWh and PUE is 1.2, what is estimated facility energy?

A. 800 kWh

B. 1,000 kWh

C. 1,200 kWh

D. 2,200 kWh

Correct Answer: C. 1,200 kWh

Question 9

Which formula estimates operational emissions when energy and an emissions factor are known?

A. Energy divided by emissions factor

B. Energy multiplied by emissions factor

C. Emissions factor minus energy

D. Energy multiplied by PUE only

Correct Answer: B. Energy multiplied by emissions factor

Question 10

Which is an important limitation of carbon-aware workload placement?

A. It always increases model accuracy

B. It may conflict with data residency, latency, or transfer-cost requirements

C. It eliminates the need for cost monitoring

D. It applies only to permanently idle resources

Correct Answer: B. It may conflict with data residency, latency, or transfer-cost requirements