12. Economics, FinOps, Sustainability, and Strategic Sourcing

Introduction and Context

Cloud and edge computing are often presented as technical transformations, but their long-term success depends equally on economic design. A workload may be architecturally elegant and operationally reliable yet strategically unsound if its cost structure is opaque, its supplier commitments are inflexible, or its environmental consequences are ignored. In distributed computing, economic decisions are inseparable from architecture: latency requirements influence edge placement, resilience requirements influence redundancy, data gravity influences transfer costs, and sustainability objectives influence the selection of regions, hardware, and operating schedules.

Traditional information technology budgeting generally treated infrastructure as capital expenditure. Organizations purchased servers, networks, facilities, and software licenses, depreciated them over several years, and allocated costs through relatively stable annual budgets. Cloud computing introduced elastic, metered consumption, while edge computing added a geographically distributed and operationally heterogeneous layer. These models create flexibility but also complicate forecasting, accountability, procurement, and environmental measurement.

This chapter examines the economic and strategic governance of cloud and edge architectures. It develops methods for total cost of ownership (TCO), pricing and unit economics, FinOps, sourcing and contracting, and build–buy–partner decisions. It also considers energy, carbon, water, hardware lifecycle, and rebound effects. The central argument is that cost optimization cannot be separated from value optimization. The least expensive infrastructure is not necessarily the most economical if it reduces service quality, increases risk, or creates hidden environmental and organizational costs.

Learning Objectives

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

1. Distinguish capital expenditure, operating expenditure, total cost of ownership, and total economic impact in cloud and edge environments.

2. Analyze pricing models, cost drivers, and unit economics for distributed workloads.

3. Apply FinOps principles to allocation, forecasting, optimization, governance, and accountability.

4. Evaluate procurement, outsourcing, service contracts, and supplier concentration risks.

5. Make defensible build–buy–partner decisions using strategic and financial criteria.

6. Quantify major environmental impacts, including energy, carbon, water, hardware lifecycle, and rebound effects.

7. Design sustainable workload-placement and sourcing strategies.

8. Critically assess limitations in economic and sustainability estimates.

From Infrastructure Cost to Economic Value

The simplest financial distinction is between capital expenditure (CapEx) and operating expenditure (OpEx). CapEx includes investments such as owned servers, data-centre construction, and edge appliances. OpEx includes consumption-based compute, storage, bandwidth, managed services, support, electricity, facilities, and personnel. Cloud services shift a substantial portion of expenditure toward OpEx, but the distinction is not absolute. Reserved capacity, committed-use discounts, prepaid services, and dedicated hardware may create economically similar obligations to capital investment.

Total cost of ownership is broader than the provider invoice. A useful expression is:

TCO = direct service cost + personnel cost + migration cost + integration cost + security and compliance cost + resilience cost + exit cost − residual value

For edge systems, facilities, field support, physical security, connectivity, installation, replacement logistics, and local power systems must be included. For cloud systems, data transfer, observability, support plans, managed databases, software licenses, identity services, backup, disaster recovery, and idle resources are frequent sources of hidden expenditure.

TCO should not be confused with business value. A workload may have a high TCO but generate greater revenue, safety, or operational benefit than a cheaper alternative. Consequently, decision makers should also examine total economic impact, including revenue enablement, avoided downtime, improved compliance, reduced labor, customer retention, and strategic flexibility.

A sound economic analysis establishes a system boundary. If one alternative includes application engineering but another excludes it, comparison is invalid. The analysis should specify time horizon, workload growth, service-level requirements, discount rates where appropriate, migration assumptions, tax treatment, depreciation, residual value, and the treatment of risk. Sensitivity analysis is essential because cloud demand, energy prices, foreign exchange, data-transfer volume, and service prices may change materially.

Pricing Models and Unit Economics

Cloud and edge providers use several pricing mechanisms. On-demand pricing offers flexibility but normally carries a higher unit price. Reserved or committed-use pricing reduces unit cost in exchange for a term commitment. Spot or preemptible capacity offers substantial discounts but permits interruption. Dedicated hosts and bare-metal services provide isolation and licensing advantages but may reduce utilization. Serverless pricing is commonly based on requests, execution duration, memory allocation, or combinations of these variables. Edge providers may charge for hardware, site access, bandwidth, installation, local processing, and support separately.

The correct comparison is not simply price per virtual machine. It is price per useful unit of business output. Examples include cost per transaction, cost per video stream, cost per training job, cost per connected device per month, cost per gigabyte processed, or cost per completed inference. A basic unit-cost measure is:

Cost per unit of work = total attributable cost ÷ number of useful units delivered

The word “useful” matters. A failed transaction, discarded computation, duplicate data transfer, or idle reservation should not be counted as productive output. Unit economics expose architectural inefficiency that aggregate monthly invoices may conceal.

Consider a service processing 100 million transactions per month. If compute, storage, network, observability, and support total $500,000, the apparent cost is $0.005 per transaction. If only 80 million transactions are successful and billable, the economically meaningful cost is $0.00625 per successful transaction. If a design change raises infrastructure cost by 10 percent but increases successful throughput by 30 percent, unit economics improve even though the invoice rises.

Cost allocation is difficult when resources are shared. Organizations may use direct allocation, proportional allocation, activity-based costing, or showback and chargeback. Direct allocation assigns identifiable resources to a product. Proportional allocation distributes shared costs according to usage, such as CPU hours, storage volume, or data-transfer quantity. Activity-based costing assigns costs according to activities that cause them, such as deployment frequency, support events, or compliance operations. Showback reports cost without internal billing; chargeback transfers financial responsibility to consuming units.

FinOps as an Operating Discipline

FinOps is a cross-functional operating discipline that connects engineering, finance, procurement, product management, and leadership around the economic use of cloud technology. It is not merely a collection of billing dashboards. Its purpose is to create timely visibility, shared accountability, and informed trade-offs between cost, performance, resilience, security, and sustainability.

A mature FinOps practice commonly develops through three overlapping capabilities. First, teams inform: they make consumption visible, establish meaningful allocation, and improve forecasting. Second, teams optimize: they right-size resources, remove waste, negotiate commitments, improve architectures, and manage data lifecycles. Third, teams operate: they embed economic controls in delivery processes, budgets, policy, architecture review, and product planning.

Effective FinOps depends on reliable metadata. Tags, labels, accounts, projects, environments, owners, products, and cost centres should be governed as operational data rather than optional documentation. Allocation must also accommodate shared platforms. A central security service, Kubernetes cluster, data lake, or observability platform may support many products; arbitrary allocation can produce misleading incentives. Allocation rules should be transparent, stable, and periodically reviewed.

Forecasting can combine historical trends, business drivers, engineering plans, and scenario analysis. A purely time-series forecast may fail when a product launches or an architecture changes. Driver-based forecasting is often more useful: expected users, transactions, storage growth, model invocations, or edge sites are translated into resource consumption and cost. Variance analysis then distinguishes demand growth from price changes, inefficiency, architectural decisions, and unexpected incidents.

Automation is central to operational FinOps. Policies can identify unattached volumes, idle load balancers, oversized instances, anomalous spending, expired test environments, and unexpected regional usage. Automated remediation must be governed carefully. Stopping an apparently idle resource may interrupt a disaster-recovery system or a compliance process. Economic automation therefore requires ownership metadata, exception handling, approval thresholds, audit trails, and rollback mechanisms.

FinOps should not create dysfunctional incentives. If teams are rewarded only for reducing expenditure, they may reduce testing, resilience, observability, or performance. A balanced scorecard can include unit cost, service-level attainment, availability, security posture, deployment lead time, carbon intensity, and customer outcomes. Cost is one dimension of engineering quality, not its sole definition.

Procurement, Outsourcing, and Service Contracts

Cloud procurement differs from conventional hardware procurement because consumption can begin immediately while contractual exposure accumulates gradually. Organizations should distinguish list price, effective price, committed spend, minimum spend, transfer charges, support charges, and exit obligations. A discount can be economically harmful if it encourages unused commitment or locks the organization into an unsuitable service.

Requests for proposal should describe workload characteristics and desired outcomes rather than prescribe a particular technical solution unnecessarily. Important evaluation criteria include performance, availability, data residency, portability, support responsiveness, incident transparency, security controls, audit rights, subcontractor governance, environmental reporting, and termination assistance.

Service-level agreements (SLAs) specify measurable commitments, such as availability or response time. They should be distinguished from service-level objectives (SLOs), which are operational targets, and service-level indicators (SLIs), which are measurements. Financial service credits are often inadequate compensation for strategic service failure. Contracts should therefore address recovery-time objectives, recovery-point objectives, incident notification, data restoration, support escalation, vulnerability remediation, and exit assistance.

Outsourcing can provide scale, specialist expertise, and faster access to technology. It can also create dependency, knowledge loss, reduced bargaining power, and ambiguity over accountability. A provider may operate the infrastructure, but the customer generally remains responsible for business outcomes, lawful processing, data classification, and appropriate architecture. The shared-responsibility model must be translated into contract language, operating procedures, and evidence requirements.

Supplier concentration is a strategic risk. Concentration may arise from dependence on one cloud provider, one telecommunications carrier, one hardware manufacturer, one managed-service integrator, or one geographic region. Multi-cloud or multi-provider strategies can reduce selected risks but introduce duplicated skills, data movement, operational complexity, and potentially higher cost. Portability should therefore be risk-based rather than ideological. An organization may retain a portable data representation, tested recovery path, and contractual exit rights without running every workload simultaneously on multiple clouds.

Build–Buy–Partner Decisions

The build–buy–partner decision concerns more than software acquisition. It determines where the organization will develop distinctive capability and where it will rely on external markets. A capability should generally be built when it is strategically differentiating, closely tied to proprietary knowledge, difficult to procure appropriately, and feasible to operate at the required quality. Buying is attractive when a capability is standardized, available from mature suppliers, and not a source of competitive differentiation. Partnering is useful when outcomes require complementary expertise, shared investment, or local presence.

A decision matrix can score alternatives against strategic differentiation, time to value, lifecycle cost, talent availability, security, compliance, interoperability, resilience, supplier power, reversibility, and sustainability. Scores should be supported by evidence and sensitivity analysis rather than treated as objective truth. The analysis should also consider opportunity cost: internal engineers assigned to commodity infrastructure cannot simultaneously develop customer-facing or research capabilities.

The cheapest acquisition price may conceal integration, customization, training, migration, governance, and exit costs. Conversely, internal development may underestimate maintenance, on-call obligations, technical debt, recruitment, and the cost of keeping pace with a rapidly changing ecosystem. A staged approach is often appropriate: pilot a purchased service, retain an abstraction boundary, measure actual unit economics, and revisit the decision when demand or strategic importance changes.

Environmental Economics of Cloud and Edge Systems

Sustainability analysis begins with energy but cannot end there. Operational energy is influenced by server utilization, processor efficiency, cooling, power distribution, networking, storage, and the energy used at edge sites. A simplified energy estimate is:

Energy = power × time

For a device drawing 200 watts continuously for one year, energy use is approximately 1,752 kilowatt-hours before accounting for additional facility overhead. Data-centre efficiency may be represented by power usage effectiveness (PUE), defined as total facility energy divided by IT equipment energy. If IT equipment consumes 1,000 kWh and the facility consumes 1,200 kWh in total, PUE is 1.2. PUE is useful but incomplete: it does not measure the carbon intensity of electricity, embodied emissions, water consumption, or workload productivity.

Operational carbon can be estimated as:

Operational carbon = energy consumed × electricity carbon-intensity factor

Carbon-intensity factors vary by grid, time, contractual accounting method, and data source. Location-based and market-based reporting can produce different results. Estimates should state their boundary and uncertainty. Embodied carbon includes extraction, manufacturing, transport, installation, maintenance, and disposal of equipment. Extending hardware life can avoid manufacturing impacts, but old equipment may consume more energy or lack required security and performance capabilities.

Water deserves separate treatment. Water may be consumed directly in cooling and indirectly through electricity generation and semiconductor manufacturing. Water usage effectiveness (WUE) can express data-centre water use relative to IT energy, but reported values may not be comparable across climates, cooling technologies, and accounting boundaries. A region with low-carbon electricity may nevertheless face severe local water stress. Sustainable placement therefore requires local environmental context rather than reliance on a single global metric.

Edge computing changes the sustainability calculation. Processing data locally can reduce wide-area network traffic, latency, and centralized data movement. However, many small sites may have lower utilization, duplicated equipment, difficult maintenance, and inefficient cooling. The correct comparison is between complete alternatives: centralized processing, regional cloud processing, edge processing, or a hybrid design. Network energy, device replacement, field visits, and end-of-life treatment must be included.

Workload Placement and Rebound Effects

Sustainable workload placement considers technical feasibility, economic cost, carbon intensity, water stress, latency, resilience, regulatory constraints, and social impacts. A placement policy may schedule flexible batch jobs in regions or time periods with lower marginal carbon intensity, while keeping latency-sensitive or legally restricted workloads near users. Such policies require trustworthy telemetry and must not violate data-residency or availability requirements.

Carbon-aware scheduling is most suitable for deferrable workloads such as batch analytics, backups, model training, rendering, and some data-processing pipelines. It is less suitable for interactive transactions with strict latency objectives. Geographic shifting may also increase data-transfer costs or move environmental burdens between communities. Sustainability optimization is consequently a constrained multi-objective problem, not a single-variable minimization exercise.

The rebound effect occurs when efficiency lowers the cost of a service and thereby increases demand, offsetting some or all expected environmental savings. More efficient inference may lead organizations to run substantially more inference. Lower storage prices may encourage indefinite retention. Edge deployment may reduce per-device communication but make large-scale sensing economically attractive. Assessments should therefore model demand elasticity and system-level behavior, not assume that technical efficiency automatically reduces total impact.

An Illustrative Case: Regional Edge Analytics for a Logistics Network

Background

The following fictional case concerns Northstar Logistics, a company operating warehouses and delivery fleets in several countries. Its existing platform transmits camera feeds and sensor data to a central cloud region for anomaly detection. The company is considering regional edge nodes to reduce response time and network traffic.

Situation and Problem

The centralized design has predictable operations but produces high bandwidth charges and delays in detecting conveyor faults. The proposed edge design would place accelerators and storage in warehouses. Initial estimates show lower network expenditure, but the proposal requires hardware purchases, local support, physical security, replacement stock, and additional electricity. Management also wants to reduce carbon emissions without compromising safety or service availability.

Analysis

The architecture team defines three alternatives: centralized cloud processing, regional cloud processing, and warehouse edge processing. It measures cost per inspected package, detection latency, availability, energy use, embodied hardware impact, water risk, and five-year exit cost. The team discovers that the first edge estimate excludes technician travel, spare devices, security monitoring, and hardware disposal. It also finds that regional cloud processing meets most latency requirements without installing equipment at every warehouse.

For workloads requiring immediate conveyor shutdown, local inference is retained. Video retention, model training, and historical analytics remain in regional or central cloud services. The hybrid design avoids transmitting all raw video while preserving centralized governance. Devices are selected with remote management, secure boot, hardware inventory, repairability, and an expected replacement plan.

Strategy and Solution

Northstar conducts a six-month pilot at representative sites: a large modern warehouse, a small facility with unreliable connectivity, and a site in a water-stressed region. FinOps dashboards report cost per inspected package and cost by site. Sustainability dashboards report energy, estimated operational carbon, hardware age, and transport-related maintenance impacts. A contract with the hardware partner includes security updates, spare-part availability, data deletion, and end-of-life responsibilities.

The company adopts an allocation policy that charges product teams for variable processing while centrally funding shared safety controls. Batch model training is scheduled in lower-carbon periods where feasible. An annual architecture review examines whether edge sites remain economically justified as network prices, hardware efficiency, and model requirements change.

Outcome

The illustrative outcome is not a universal prescription: the hybrid design provides the best balance for Northstar because only a subset of decisions requires immediate local processing. A fully centralized design would be simpler but slower and more bandwidth-intensive; a fully distributed design would reduce some data movement but create excessive operational complexity. The case demonstrates the importance of complete boundaries, unit economics, staged experimentation, and lifecycle governance.

Learning Points

The case highlights five principles. First, placement decisions should be workload-specific rather than ideological. Second, edge TCO includes field operations and end-of-life management. Third, sustainability requires energy, carbon, water, and embodied impacts to be considered together. Fourth, shared controls require allocation methods that do not punish product teams unfairly. Fifth, contracts and architecture should preserve the ability to revise the design.

Risks, Limitations, and Common Errors

Economic models can create false precision. Forecasts depend on assumptions about demand, price, utilization, exchange rates, and technical performance. Sustainability estimates may rely on incomplete provider data, inconsistent boundaries, or average rather than marginal carbon factors. Decision makers should publish assumptions, provide ranges, and perform sensitivity analysis.

Common errors include optimizing visible compute while ignoring data transfer and managed-service charges; purchasing commitments without demand confidence; treating tags as an afterthought; allocating shared costs using arbitrary rules; comparing cloud invoices with only server acquisition costs; assuming multi-cloud automatically improves resilience; and measuring carbon without considering water or embodied impacts.

Another risk is metric gaming. A team may reduce reported cost by moving expenditure to another department, reduce carbon intensity by shifting workloads without reducing total emissions, or improve utilization by degrading performance. Governance should therefore combine financial, operational, environmental, and user-outcome measures.

Security and privacy also have economic dimensions. Weak identity controls can produce fraudulent consumption, while inappropriate data movement can trigger legal penalties and remediation costs. Contractual rights to audit, incident evidence, deletion, portability, and subcontractor disclosure are essential for regulated workloads. Ethical sourcing should consider labor conditions, conflict minerals, e-waste, and the distribution of environmental burdens across communities.

Emerging Directions and Best Practices

Several developments are reshaping this field. Carbon-aware orchestration is becoming more feasible as providers expose regional and temporal emissions signals. Artificial intelligence can detect anomalous consumption, forecast demand, recommend rightsizing, and identify idle resources, although automated recommendations require human oversight and explainable controls. Confidential computing, specialized accelerators, and increasingly heterogeneous edge hardware may improve security or performance but complicate lifecycle economics.

Sustainable FinOps is emerging as an integrated practice in which cost and environmental metrics are attached to products and units of work. This approach is valuable only when measurements are comparable and decisions do not sacrifice reliability or equity. Digital product passports, hardware reuse, modular repair, and supplier disclosures may improve lifecycle accountability.

Practical best practices include:

• Define TCO boundaries, time horizons, and assumptions before comparing architectures.
• Measure cost per useful business unit, not merely aggregate spend.
• Establish ownership, allocation, forecasting, and anomaly-response processes.
• Treat commitments as financial contracts and review them against actual demand.
• Include migration, support, resilience, security, exit, and field-operation costs.
• Use balanced metrics covering cost, performance, reliability, security, carbon, water, and hardware lifecycle.
• Prefer reversible and staged decisions where uncertainty is high.
• Make supplier obligations measurable through SLAs, audit rights, reporting, and exit assistance.
• Use carbon-aware placement only within regulatory, latency, resilience, and data-governance constraints.
• Reassess rebound effects and demand growth after every major efficiency intervention.

Chapter Summary

Cloud and edge economics require a system-level perspective. TCO extends beyond provider bills to include people, integration, security, resilience, migration, facilities, hardware lifecycle, and exit. Unit economics connect infrastructure consumption to useful business output and reveal whether apparent savings are real. FinOps provides the organizational discipline needed to make consumption visible, optimize resources, forecast demand, and embed accountability without sacrificing service quality.

Strategic sourcing requires careful evaluation of pricing, commitments, service levels, supplier concentration, portability, and termination rights. Build–buy–partner decisions should reflect strategic differentiation, lifecycle cost, capability, risk, and opportunity cost. Sustainability analysis must include operational energy, carbon intensity, water, embodied emissions, hardware replacement, and rebound effects. Sustainable placement is therefore a constrained, multi-objective architectural decision. The most robust approach combines transparent assumptions, measurable outcomes, staged experimentation, cross-functional governance, and continuous reassessment.

Key Terms

Capital expenditure (CapEx): Investment in assets expected to provide value over multiple accounting periods.

Operating expenditure (OpEx): Ongoing expenditure for consuming services, operating systems, personnel, and facilities.

Total cost of ownership (TCO): All relevant costs of acquiring, operating, changing, and retiring a solution.

Unit economics: Analysis of revenue or cost associated with a defined unit of useful business output.

FinOps: Cross-functional discipline for managing and optimizing the economic use of cloud services.

Showback: Reporting consumption costs to teams without directly billing them.

Chargeback: Transferring allocated costs to the teams or products that consume services.

Committed-use pricing: Discounted pricing obtained in exchange for a usage or spending commitment.

Spot capacity: Discounted, interruptible computing capacity offered when spare provider capacity exists.

Service-level agreement (SLA): Contractual commitment defining measurable service performance or availability.

Service-level objective (SLO): Internal or operational target for a service attribute.

Portability: Ability to move applications, data, or workloads between environments with acceptable effort.

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

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

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

Water usage effectiveness (WUE): Measure relating data-centre water consumption to IT energy use.

Rebound effect: Increase in demand that offsets environmental savings from improved efficiency.

Carbon-aware computing: Scheduling or placing workloads according to variations in carbon intensity.

Strategic sourcing: Structured selection and governance of suppliers to achieve economic, operational, and strategic objectives.

Review Questions

Short Answer Questions

1. What costs should be included in a cloud and edge TCO analysis?

2. How does unit economics differ from aggregate infrastructure spending?

3. Distinguish showback from chargeback.

4. What is the purpose of an SLA, and how does it differ from an SLO?

5. Why is PUE insufficient as a complete sustainability metric?

Long Answer Questions

1. Explain how FinOps operates as an organizational discipline rather than merely a billing function.

2. Compare on-demand, committed-use, and spot pricing models, including their strategic risks.

3. Discuss the major economic and governance issues involved in outsourcing cloud and edge operations.

4. Develop a framework for making build–buy–partner decisions for a strategically important platform capability.

5. Explain how energy, carbon, water, embodied impacts, and hardware lifecycle should be integrated into architecture evaluation.

Analytical / Application Questions

1. An organization reduces compute expenditure by 20 percent but experiences a 15 percent increase in failed transactions. How should it evaluate whether the initiative created economic value?

2. A company is considering edge processing at 500 sites. Identify the variables required for a five-year comparison with regional cloud processing and propose a pilot design.

3. A provider offers a large discount in exchange for a three-year commitment. Design a sensitivity analysis that would determine whether the commitment is financially and strategically defensible.

22. Multiple Choice Questions with Answers

Question 1

Which measure most directly captures the economic efficiency of a cloud workload?

A. Total monthly invoice

B. Number of virtual machines

C. Cost per successful business transaction

D. List price of the largest instance

Correct Answer: C. Cost per successful business transaction

Question 2

What is the principal purpose of FinOps?

A. To eliminate all cloud expenditure

B. To connect engineering, finance, and business decisions about technology consumption

C. To replace service-level objectives with budgets

D. To require every workload to use one provider

Correct Answer: B. To connect engineering, finance, and business decisions about technology consumption

Question 3

A commitment discount is most risky when an organization:

A. Has stable and well-forecast demand

B. Can measure utilization continuously

C. Has highly uncertain or rapidly changing demand

D. Uses automated cost reporting

Correct Answer: C. Has highly uncertain or rapidly changing demand

Question 4

Which item is most likely to be omitted from an incomplete edge-computing TCO estimate?

A. Field maintenance and replacement logistics

B. Application business value

C. User interface color

D. Programming language syntax

Correct Answer: A. Field maintenance and replacement logistics

Question 5

If IT equipment consumes 1,000 kWh and total facility energy is 1,200 kWh, the PUE is:

A. 0.83

B. 1.00

C. 1.20

D. 2.20

Correct Answer: C. 1.20

Question 6

Why can a multi-cloud strategy increase rather than reduce total cost?

A. It always eliminates data-transfer charges

B. It may duplicate skills, tools, operations, and data movement

C. It prevents supplier concentration without any operational effort

D. It guarantees identical service interfaces

Correct Answer: B. It may duplicate skills, tools, operations, and data movement

Question 7

Which workload is generally most suitable for carbon-aware time shifting?

A. Emergency control traffic with strict latency requirements

B. Interactive payment authorization

C. Deferrable batch model training

D. Real-time medical-device control

Correct Answer: C. Deferrable batch model training

Question 8

What is a rebound effect in sustainable computing?

A. A reduction in demand after efficiency improves

B. An increase in demand that offsets efficiency-related savings

C. A contractual penalty for poor availability

D. A hardware failure caused by overheating

Correct Answer: B. An increase in demand that offsets efficiency-related savings

Question 9

Which factor is central to a build–buy–partner decision?

A. Whether the capability is strategically differentiating

B. Whether the provider has the lowest advertised price only

C. Whether all workloads can run at the edge

D. Whether the architecture avoids all contracts

Correct Answer: A. Whether the capability is strategically differentiating

Question 10

Why should sustainability assessment include water and embodied impacts?

A. Energy use never affects carbon emissions

B. Operational electricity is the only environmental impact

C. A low-carbon design may still create local water stress or manufacturing impacts

D. Water and embodied impacts are identical to PUE

Correct Answer: C. A low-carbon design may still create local water stress or manufacturing impacts