Cloud Economics, FinOps and Vendor Management

Introduction

Cloud computing changes not only how technology is operated but also how it is purchased, measured and governed. Traditional infrastructure expenditure is dominated by periodic capital investment, depreciation and data-centre operations. Cloud expenditure is more variable: resources can be acquired on demand, scaled automatically and billed according to consumption. This flexibility creates business value, but it also introduces financial complexity. A technically successful cloud migration may still fail economically if workloads are poorly sized, data-transfer costs are ignored, discounts are misunderstood, or accountability is unclear.

Cloud economics examines the relationship between cloud architecture, service consumption, risk and business value. FinOps is the organisational and operational discipline used to maximise that value through collaboration among engineering, finance, procurement, security and business teams. Vendor management extends the analysis to contracts, licensing, service-level agreements (SLAs), supplier risk and exit planning.

The central managerial question is not simply “How can cloud costs be reduced?” It is “How can the organisation obtain the required business outcomes at an acceptable total cost, risk and level of strategic flexibility?” Cost reduction is therefore one objective, but not the only objective. Reliability, performance, speed of delivery, resilience, compliance and innovation must also be considered.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Distinguish capital expenditure, operating expenditure, total cost of ownership and total economic impact.

2. Construct cloud cost models and interpret unit economics.

3. Explain pricing dimensions, discounts, commitments, elasticity and hidden costs.

4. Design a FinOps operating model based on accountability, visibility and continuous optimisation.

5. Forecast cloud expenditure and evaluate optimisation alternatives.

6. Analyse procurement, contracts, licensing, SLAs and provider concentration risk.

7. Develop practical exit, portability and multi-provider strategies.

8. Critically evaluate the trade-off between cost, performance, resilience, compliance and innovation.

1. Foundations of Cloud Economics

1.1 Cost categories

Capital expenditure (CapEx) is expenditure on assets expected to provide benefits over several accounting periods, such as servers, storage systems and data-centre equipment. Operating expenditure (OpEx) is recurring expenditure associated with operating a service, including consumption charges, support, personnel and software subscriptions. Cloud services generally shift a greater proportion of infrastructure spending toward OpEx, although cloud adoption does not eliminate capital costs. Internal migration programmes, network upgrades, security tooling and engineering platforms may require substantial investment.

A useful total cost of ownership (TCO) model is:

TCO = Direct provider charges + Internal operating costs + Transition costs + Risk and compliance costs − Residual value

Direct provider charges include compute, storage, databases, networking, observability, support and marketplace software. Internal operating costs include staff, platform engineering, FinOps, security, service management and training. Transition costs include assessment, migration, refactoring, testing, temporary duplication and decommissioning. Risk and compliance costs include controls, audits, insurance and expected losses associated with outages or non-compliance. Residual value may include reusable licences, retained equipment value or transferable knowledge.

This expression is a management model rather than an accounting standard. Its usefulness depends on consistent scope, time horizon, currency and treatment of shared costs. A comparison must use equivalent service levels. Comparing a highly available managed database with a basic self-managed server is not economically meaningful unless availability, security, staffing and recovery requirements are also compared.

1.2 Cost, price and value

Price is the amount charged by a provider. Cost is the resource sacrifice incurred by the organisation. Value is the contribution of a service to organisational objectives. These concepts are related but not identical. A more expensive cloud configuration may create greater value by reducing transaction latency, improving customer conversion or shortening development cycles.

Cloud economic analysis should therefore include benefits such as:

• faster time to market;
• reduced provisioning time;
• improved availability and disaster recovery;
• access to advanced managed services;
• reduced operational burden;
• ability to scale during demand peaks; and
• reduced opportunity cost of maintaining legacy platforms.

A simple net-benefit model is:

Net benefit = Quantified benefits − TCO

Benefits should be measured against a baseline and stated over a defined period. Some benefits, such as improved developer productivity or reduced risk, are uncertain and should be represented through scenarios rather than presented as precise facts.

1.3 Cloud cost characteristics

Cloud cost has four important characteristics. First, it is metered: consumption is associated with measurable units such as virtual CPU-hours, gigabyte-months, requests or outbound gigabytes. Second, it is elastic: expenditure can rise and fall with demand. Third, it is granular: many services generate numerous line items. Fourth, it is shared: platforms, networks, security services and support plans often serve several products.

These characteristics produce a shift from periodic budgeting to continuous economic management. Engineering decisions become financial decisions. A choice of architecture affects not only performance and reliability but also request volume, data movement, storage retention and operational labour.

2. Pricing Models and Cost Drivers

2.1 Major pricing dimensions

Common pricing dimensions include:

• Time-based compute: charges per instance-hour, vCPU-hour or memory-hour.
• Consumption-based services: charges per request, transaction, operation or execution duration.
• Storage: charges per gigabyte-month, often varying by storage class, performance and redundancy.
• Data transfer: charges for network egress, inter-region traffic, cross-zone traffic or dedicated connectivity.
• Licensing: charges based on users, cores, hosts, features or software consumption.
• Support: fixed or percentage-based charges linked to provider spend.
• Commitments: discounts in exchange for a defined term or spending/usage commitment.

A monthly estimate for a simple compute workload can be expressed as:

Monthly compute cost = Number of resources × Hours per resource × Price per resource-hour

If a workload uses 20 virtual machines, each priced at $0.10 per hour, for 730 hours, the compute charge is 20 × 730 × $0.10 = $1,460. This estimate excludes storage, networking, operating-system licences, support, taxes and related services. The assumption of 730 hours represents an average month and should not be confused with a guarantee of actual calendar hours.

2.2 Elasticity and utilisation

The economic advantage of elasticity depends on whether resources can be released or scaled when demand falls. A continuously running resource with low utilisation may be more expensive than a smaller or serverless alternative. However, utilisation alone is not a sufficient optimisation metric: a highly utilised resource that violates latency or resilience requirements is not economically optimal.

Resource right-sizing requires evidence about CPU, memory, storage, throughput and latency over a representative period. Short observation windows may miss month-end processing, seasonal peaks or failure-recovery conditions. Automated scaling should include limits, cooldown periods and monitoring to prevent runaway expenditure.

2.3 Discounts and commitments

Providers commonly offer discounted pricing through reservations, savings plans, committed-use discounts, spot or pre-emptible capacity, and volume pricing. Each mechanism transfers some risk to the customer.

A commitment is economically attractive when the discounted savings exceed the cost of unused capacity and the value of lost flexibility. The relevant comparison is not simply the advertised discount. It is the expected cost under uncertain demand:

Expected commitment cost = Committed quantity × Discounted rate + Expected unused commitment cost + Flexibility cost

The flexibility cost represents the value of being able to change provider, region, instance family or architecture. It is difficult to measure precisely, but it should not be ignored in strategic decisions.

Spot or pre-emptible resources may be appropriate for interruptible workloads such as batch analytics, testing or stateless rendering. They are unsuitable for workloads that cannot tolerate interruption unless a robust recovery design exists.

2.4 Hidden and indirect costs

Important cost drivers are frequently omitted from initial estimates. These include:

• data egress and cross-region transfer;
• idle load balancers, public IP addresses and unattached disks;
• backup copies and long retention periods;
• observability ingestion and log storage;
• managed-service premiums;
• marketplace software licences;
• support plans;
• security and compliance tooling;
• migration and refactoring labour;
• duplicate environments used during transition; and
• costs caused by poor tagging or fragmented accounts.

Data gravity is particularly significant. Once large datasets and dependent applications accumulate in a provider, moving them may require substantial transfer charges, transformation effort and downtime planning. Architectural convenience at the beginning of a project can therefore create future switching costs.

3. Unit Economics and Financial Models

3.1 Cost allocation and shared services

A cloud organisation should distinguish direct, shared and unallocated costs. Direct costs can be assigned to a product or team, such as a production database dedicated to one application. Shared costs support several consumers, such as a security platform or central network. Unallocated cost represents a governance failure when ownership is unknown.

Allocation methods should be transparent and stable. Shared network or platform costs can be distributed using drivers such as data volume, request count, number of environments, headcount or a fixed proportional rule. No allocation method is universally correct; the method should approximate causation without creating excessive administrative burden.

Tagging, account or subscription hierarchy, naming conventions and resource inventories provide the data foundation. Tags should identify at least owner, product, environment, cost centre, data classification and lifecycle. Mandatory tagging should be combined with automated policy enforcement because manual tagging degrades over time.

3.2 Unit economics

Unit economics connects expenditure to a meaningful business output. Examples include:

• cost per active customer per month;
• cost per transaction;
• cost per API request;
• cost per training job;
• cost per gigabyte processed; and
• cost per order fulfilled.

For a service with total monthly cloud cost C and monthly business units U:

Unit cost = C / U

The denominator must be operationally meaningful and measured consistently. If a platform costs $12,000 in a month and processes 600,000 orders, its cloud cost per order is $0.02. If orders fall to 300,000 while fixed platform costs remain unchanged, unit cost rises to $0.04. This distinction shows why total spend can remain stable while economic efficiency deteriorates.

Unit economics should be segmented where behaviour differs. Production and development traffic, premium and standard customers, or synchronous and batch workloads may have materially different costs. A single average can conceal cross-subsidies and unprofitable usage patterns.

3.3 Forecasting

A basic forecast is:

Forecast spend = Baseline recurring spend + Variable rate × Forecast usage + Planned changes

This model assumes the rate structure is stable and usage is represented by a suitable driver. Forecast accuracy declines when architecture is changing, pricing is volatile or demand is seasonal. Mature forecasting uses at least three scenarios: conservative, expected and high-growth. Forecasts should be updated using actual-versus-budget variance analysis.

Variance can be decomposed into price variance, usage variance, rate or discount variance, and scope variance. For example, a higher bill may result from increased customer activity, a new service, loss of a discount or inefficient resource growth. Correct diagnosis is more useful than simply imposing a spending cap.

4. FinOps as an Operating Model

FinOps is a cross-functional practice for making the economic implications of technology visible and actionable. It is not merely a finance department function or a cost-cutting exercise. Its success depends on engineers understanding cost, finance understanding technical drivers, and product leaders understanding the economic consequences of customer and architectural choices.

4.1 FinOps principles

A practical FinOps model is based on the following principles:

1. Teams take ownership: those who create or influence consumption should see and manage its consequences.

2. Decisions are driven by business value: cost is evaluated with performance, reliability, security and product outcomes.

3. Everyone is accountable: central teams provide policy, data and enablement; product teams act on opportunities.

4. Reports are timely and actionable: information must arrive early enough to influence behaviour.

5. The organisation recognises cloud’s variable cost model: budgets and forecasts must accommodate elasticity.

6. FinOps is iterative: measurement, optimisation and learning occur continuously.

4.2 Operating phases

FinOps activities can be organised into three recurring phases:

• Inform: establish visibility through billing data, allocation, tagging, dashboards, budgets and forecasts.
• Optimise: remove waste, right-size resources, improve architecture, select discounts and control data movement.
• Operate: integrate financial targets into governance, product planning, procurement and engineering processes.

These phases are not strictly sequential. An optimisation action without reliable allocation may benefit the wrong team; visibility without operational action becomes reporting theatre.

4.3 Accountability model

A central FinOps team typically defines standards, maintains cost-data platforms, supports forecasting, negotiates with providers and facilitates cross-team decisions. Engineering teams own resource design, utilisation and technical remediation. Finance owns budgeting, accounting interpretation and financial controls. Procurement manages commercial terms and supplier processes. Product leaders connect cost to customer value and prioritise trade-offs.

A responsibility assignment matrix can clarify who is accountable for forecasting, tagging, commitment purchases, anomaly response, architecture reviews and contract renewal. Accountability should follow influence: a team should not be blamed for costs it cannot observe or control.

4.4 Metrics and controls

Useful metrics include forecast accuracy, percentage of spend allocated to an owner, idle-resource rate, commitment utilisation, unit cost, anomaly detection time, optimisation realisation rate and cost per business transaction. Metrics should be used diagnostically, not as simplistic performance rankings. For example, low utilisation may be desirable for a latency-sensitive service with deliberate redundancy.

Controls include budget alerts, quota limits, approval workflows for expensive resources, automated shutdown of non-production environments, policy-as-code, anomaly detection and periodic architecture reviews. Hard controls should be reserved for situations where uncontrolled expenditure or risk is unacceptable; excessive friction can encourage teams to bypass governance.

5. Procurement, Contracts and Licensing

5.1 Procurement strategy

Cloud procurement should begin with demand analysis rather than immediate negotiation. The organisation should understand workload profiles, growth assumptions, regions, data requirements, compliance obligations, switching constraints and likely service mix. A low unit price is not necessarily the best commercial outcome if it is attached to inflexible commitments or restrictive terms.

A sourcing process may include requirements definition, market analysis, request for proposal, technical and financial evaluation, negotiation, due diligence, contract approval and ongoing supplier review. Technical teams should participate because pricing and contractual language often depend on architecture.

5.2 Contract provisions

Important provisions include:

• service description and price schedules;
• change-control and price-change notice periods;
• billing currency, taxes and invoicing rules;
• service credits and remedies;
• data ownership and permitted use;
• confidentiality and data protection;
• audit rights and compliance evidence;
• subcontractor transparency;
• incident notification and cooperation;
• support response and escalation;
• termination rights and suspension rules;
• data retrieval, deletion and transition assistance; and
• liability, indemnity and insurance.

Service credits are not equivalent to compensation for all business losses. Organisations should assess whether credits are meaningful, whether they are the exclusive remedy, and whether availability is measured in a way that reflects the service’s business importance.

5.3 Software licensing

Cloud architecture can alter software licensing exposure. Licences may be based on physical cores, virtual cores, users, hosts, transactions or subscription tiers. Vendor mobility rights, bring-your-own-licence rules and restrictions on outsourcing should be reviewed before migration. A technically valid deployment may still breach licence terms if the provider’s infrastructure or multitenant model is excluded.

Licence optimisation requires an inventory, entitlement reconciliation, usage measurement and review of alternative editions or open-source components. Open-source software reduces licence fees but does not eliminate support, security, compliance and engineering costs. Legal review is necessary for licences with source-disclosure, attribution or service-use obligations.

6. SLAs, Resilience and Provider Risk

An SLA defines measurable service commitments, such as availability, response time, support response or restoration objectives. Availability over a period can be represented as:

Availability percentage = (Agreed service time − Unavailable time) / Agreed service time × 100

The calculation is meaningful only when the measurement window, exclusions, maintenance rules, dependencies and service boundaries are explicit. A provider SLA does not guarantee end-to-end application availability. The customer may introduce failures through misconfiguration, identity systems, network design or dependent services.

Organisations should distinguish:

• RTO: maximum targeted time to restore service after disruption.
• RPO: maximum targeted amount of data loss measured in time.
• SLA: contractual service commitment, often with defined remedies.
• SLO: internal or operational reliability target.
• SLI: measured indicator used to assess an objective.

Provider risk includes financial instability, outages, cyber incidents, geopolitical exposure, regulatory change, concentration risk, opaque subcontractors and unilateral product or price changes. A risk assessment should examine both probability and impact, but rare systemic events deserve scenario analysis even when historical frequency is low.

7. Portability, Exit and Multi-Provider Strategy

Exit planning should be performed before deep dependency develops. An exit plan identifies data formats, application dependencies, identity integration, networking, operational tooling, licences, skills, migration sequencing, temporary parallel operation and validation requirements. It should estimate time, cost, capacity and business interruption.

Portability exists at several levels:

• data portability through documented export formats;
• application portability through containers or portable runtimes;
• platform portability through abstraction layers;
• operational portability through transferable monitoring, deployment and security practices.

Portability is not free. Excessive abstraction can reduce access to valuable provider capabilities, increase engineering effort and weaken performance. A rational strategy classifies workloads: some may remain provider-specific because the benefits outweigh switching risk; others should use portable designs because regulatory, strategic or operational risk is high.

Multi-cloud can reduce concentration risk, but it may increase network cost, duplicated tooling, skills requirements, operational complexity and security exposure. It should be adopted for a clear business reason, not as an assumed synonym for resilience. Resilience within one provider’s independent regions may be more economical than operating two full cloud platforms, depending on failure scenarios and recovery requirements.

8. Detailed Illustrative Case: FinOps in an Online Retailer

Background

The fictional retailer Northstar Commerce migrated its storefront, order processing and analytics platform to a public cloud. Revenue increased, but monthly cloud expenditure rose from $180,000 to $310,000 in eight months. Leadership initially requested a 20% blanket reduction.

Problem analysis

The initial investigation found that only 62% of expenditure was assigned to an owner. Development environments ran continuously, log retention was excessive, and cross-region data transfer had not been included in the original business case. Several analytics jobs used on-demand compute despite being interruptible. A three-year commitment had also been purchased for a workload whose architecture was being redesigned.

The FinOps team separated direct production costs, shared platform costs and transition costs. It established product-level dashboards and introduced unit cost per completed order. Although total monthly cost was $310,000, the business processed 10 million orders, giving a cloud cost of $0.031 per order. Forecast demand predicted 13 million orders, so a simple proportional forecast would be misleading because baseline platform costs were largely fixed.

Approach

Northstar introduced mandatory ownership metadata, automated shutdown schedules for non-production resources, lifecycle policies for logs, and workload-specific rightsizing. Batch analytics moved to interruptible capacity with checkpointing. The network architecture was redesigned to reduce unnecessary cross-region transfers. Procurement renegotiated support and commitment terms, while legal and security teams added exit-assistance and data-deletion requirements to the renewal.

The company did not pursue the cheapest configuration for every service. It retained redundant production capacity for payment processing and maintained higher observability for fraud detection. Product and engineering teams reviewed cost per order alongside latency, conversion and failure rates.

Outcome

After six months, monthly expenditure fell to $248,000 while order volume reached 12.5 million. Cost per order fell to approximately $0.01984 ($248,000 / 12,500,000). The improvement resulted from both reduced waste and greater scale; it was not attributable to one discount alone. Forecast variance decreased because teams distinguished baseline and variable costs. Northstar also documented an exit plan for its data and critical applications.

Learning points

The case demonstrates that FinOps is a management system rather than an isolated savings programme. Allocation enables accountability, unit economics connects technology to business value, and contract management must address future flexibility. It also shows that cost optimisation must not undermine availability, fraud controls or customer experience.

9. Governance, Ethics and Contemporary Developments

Cloud financial governance involves more than efficiency. Cost allocation can influence product priorities, internal funding and employee evaluation; inaccurate allocation may unfairly penalise teams. Organisations should explain allocation rules, protect commercially sensitive usage data and avoid incentives that encourage unsafe under-provisioning.

Regulatory requirements may affect data location, retention, sovereignty, auditability and subcontractor disclosure. Financial controls should preserve evidence for invoices, approvals, commitments and changes. Automated optimisation must be tested carefully: deleting apparently idle resources may destroy forensic data or violate retention obligations.

AI-assisted FinOps tools can identify anomalies, forecast demand, recommend rightsizing and generate infrastructure changes. Their recommendations require human oversight because training data may be incomplete, billing semantics may be misunderstood, and automated actions can create outages or data loss. The governance principle is “assistive automation with bounded authority”: systems may recommend or execute low-risk actions within explicit policies, while high-impact changes require approval and audit trails.

Contemporary practice increasingly links FinOps with sustainability. Cloud cost and carbon impact are not identical, but inefficient computation often has environmental consequences. Workload scheduling, efficient architectures, longer hardware utilisation by providers and reduced data movement can support both economic and environmental objectives. Green claims should be based on measured or documented evidence rather than assumed from cloud use alone.

Best Practices

1. Define TCO scope, time horizon and service-level assumptions before comparing options.

2. Establish ownership for every material cost category.

3. Build allocation and tagging into platform architecture rather than treating them as reporting additions.

4. Use unit economics connected to genuine business outcomes.

5. Forecast with scenarios and explain variances by cause.

6. Optimise continuously, but protect reliability, security and compliance requirements.

7. Treat commitments as risk-bearing financial decisions.

8. Review data-transfer, observability, backup and licence costs explicitly.

9. Negotiate exit, data portability, audit and price-change provisions before renewal.

10. Test disaster recovery and exit plans rather than relying solely on contractual assurances.

11. Use multi-cloud selectively and document its additional operating cost.

12. Apply automation with safeguards, approvals, rollback and auditability.

Challenges and Limitations

Cloud economic models are affected by uncertain demand, changing prices, incomplete allocation data, exchange-rate movements and evolving architectures. TCO comparisons may omit opportunity cost or assign uncertain benefits excessive precision. Unit metrics can be gamed if teams optimise the denominator rather than customer value. Central governance can become bureaucratic, while decentralised autonomy can produce fragmentation and waste.

No framework eliminates judgement. The correct decision may be to spend more for resilience, compliance or speed. Mature cloud economics makes these trade-offs explicit, measurable where possible and reviewable over time.

Chapter Summary

Cloud economics evaluates cloud decisions through cost, value, risk and strategic flexibility. TCO includes provider charges, internal operations, transition, risk and compliance costs, while unit economics connects expenditure to business outcomes such as orders or transactions. Pricing is shaped by compute, storage, requests, data transfer, licences, support and commitments; hidden costs and switching costs are essential to analysis.

FinOps establishes shared accountability among engineering, finance, procurement and product teams. Its recurring cycle of informing, optimising and operating depends on allocation quality, forecasting, anomaly management and unit-cost metrics. Vendor management complements FinOps through procurement discipline, licensing review, contract controls, SLAs, resilience analysis and exit planning. Provider-specific services may create value but also increase dependency. Multi-cloud is a strategic choice with both benefits and costs. Finally, optimisation must preserve security, reliability, compliance, ethical governance and long-term business value.

Key Terms

TCO: Total cost of ownership over a defined scope and period.

CapEx: Capital expenditure on assets expected to provide continuing benefit.

OpEx: Operating expenditure incurred in ongoing service delivery.

FinOps: Cross-functional discipline for maximising business value from cloud spending.

Unit economics: Analysis of cost and value per meaningful business unit.

Cost allocation: Assignment of shared or direct expenditure to consumers or owners.

Right-sizing: Adjusting resources to appropriate performance and capacity requirements.

Elasticity: Ability to scale resources in response to changing demand.

Commitment discount: Reduced price exchanged for a usage or spending commitment.

Spot capacity: Discounted capacity that may be interrupted by the provider.

Data egress: Data transferred out of a provider, region or service boundary.

Forecast variance: Difference between planned and actual expenditure.

SLA: Contractual service-level commitment with defined measurement and remedies.

SLO: Operational target for a service characteristic such as availability.

SLI: Measured indicator used to assess an SLO.

RTO: Target time for restoring service after disruption.

RPO: Target maximum period of data loss after disruption.

Vendor concentration risk: Exposure arising from dependence on one supplier.

Portability: Ability to move applications, data or operations between environments.

Exit strategy: Planned approach for reducing or ending dependence on a provider.

Review Questions

Short Answer Questions

1. Distinguish TCO from the provider’s invoice amount.

2. What is the purpose of unit economics in FinOps?

3. Explain the difference between an SLA, SLO and SLI.

4. Why can data egress become a strategic cost?

5. Identify two responsibilities of a central FinOps team.

Long Answer Questions

1. Explain how cloud pricing differs from traditional infrastructure economics and discuss the managerial consequences.

2. Develop a FinOps operating model for a large enterprise involving finance, engineering, procurement and product management.

3. Critically evaluate the advantages and risks of reserved or committed cloud capacity.

4. Discuss the contractual, technical and organisational elements of an effective cloud exit strategy.

5. Explain why cloud optimisation must consider reliability, security, compliance and business value rather than cost alone.

Analytical / Application Questions

1. An application costs $40,000 per month and processes 2 million transactions. After optimisation, fixed costs fall by $6,000 and transaction volume rises to 2.5 million. Calculate the original and new cost per transaction, and interpret the change.

2. A company is considering multi-cloud for resilience. Analyse the decision using failure scenarios, skills, duplicated tooling, network charges, portability and recovery objectives.

3. A provider offers a 30% discount for a three-year commitment, but the workload may be replaced within one year. Construct a decision analysis identifying the information needed before accepting the offer.

Multiple Choice Questions with Answers

Question 1

Which item is most likely to be included in a complete cloud TCO model but not in the provider invoice?

A. Internal platform engineering labour

B. The provider's compute charge

C. The provider's storage charge

D. The provider's network charge

Correct Answer: A. Internal platform engineering labour

Question 2

A service costs $12,000 and processes 600,000 orders in one month. What is its cloud cost per order?

A. $0.002

B. $0.02

C. $0.20

D. $2.00

Correct Answer: B. $0.02

Question 3

Which FinOps phase primarily establishes visibility through allocation, dashboards and forecasting?

A. Inform

B. Optimise

C. Operate

D. Exit

Correct Answer: A. Inform

Question 4

Which pricing option generally carries the greatest interruption risk?

A. On-demand capacity

B. Reserved capacity

C. Spot or pre-emptible capacity

D. Dedicated host capacity

Correct Answer: C. Spot or pre-emptible capacity

Question 5

Which metric best connects cloud expenditure to a business outcome?

A. Number of provider accounts

B. Cost per completed order

C. Number of engineers

D. Number of availability zones

Correct Answer: B. Cost per completed order

Question 6

What does RPO primarily describe?

A. Maximum targeted service restoration time

B. Maximum targeted amount of data loss measured in time

C. Contractual billing period

D. Provider support response time

Correct Answer: B. Maximum targeted amount of data loss measured in time

Question 7

Why should a commitment discount be evaluated cautiously?

A. It always increases the unit price

B. It can create unused-capacity and flexibility risk

C. It eliminates all data-transfer charges

D. It guarantees application availability

Correct Answer: B. It can create unused-capacity and flexibility risk

Question 8

Which contractual provision most directly supports future provider migration?

A. Marketing approval rights

B. Data retrieval and transition assistance

C. Employee holiday policy

D. Office maintenance terms

Correct Answer: B. Data retrieval and transition assistance

Question 9

A service has 100 hours of agreed service time and 2 hours of unavailability. What is its availability percentage under the stated formula?

A. 2%

B. 50%

C. 98%

D. 102%

Correct Answer: C. 98%

Question 10

What is a major limitation of multi-cloud as a risk-reduction strategy?

A. It always prevents outages

B. It can increase duplicated tooling, skills and network costs

C. It removes the need for exit planning

D. It guarantees lower total cost

Correct Answer: B. It can increase duplicated tooling, skills and network costs