13. Capacity Planning, Cost Optimization, and Executive Decision-Making

Introduction and Context

Monitoring and logging are often treated as operational activities: engineers collect metrics, investigate incidents, and maintain dashboards. At postgraduate level, however, telemetry should also be understood as an economic and strategic instrument. Utilization trends reveal how systems consume scarce resources; demand forecasts indicate when present architecture will become inadequate; queueing behaviour exposes the relationship between load, latency, and saturation; and cost data connects technical choices with organizational value.

Capacity planning is the disciplined process of ensuring that an organization has sufficient computational, network, storage, personnel, and operational capability to meet expected demand at an acceptable level of performance and risk. Cost optimization is not simply reducing expenditure. It is the search for the most advantageous relationship between cost, performance, reliability, security, agility, and business outcomes. Executive decision-making brings these concerns together by translating technical evidence into investment, sourcing, architecture, and risk choices.

In DevOps, the subject is especially important because infrastructure is increasingly programmable, elastic, distributed, and consumption-based. Cloud platforms make resources available quickly, but they can also conceal inefficient designs behind automatic scaling and complex billing. Observability systems create similar tensions: detailed telemetry improves diagnosis, yet high-cardinality metrics, verbose logs, long retention periods, and extensive tracing can become significant cost centres. Sound decisions therefore require a joint view of system behaviour, financial impact, and organizational priorities.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the relationship among utilization, demand, capacity, performance, and risk.

2. Apply basic queueing concepts and scalability models to capacity decisions.

3. Construct demand forecasts and identify capacity thresholds.

4. Evaluate unit economics, telemetry costs, and cloud expenditure.

5. Compare scaling, architecture, platform, outsourcing, and investment alternatives.

6. Use FinOps practices to establish accountability and optimize consumption.

7. Design executive scorecards that communicate reliability, performance, cost, and business value.

8. Identify governance, ethical, regulatory, and operational risks in capacity and cost decisions.

From Utilization Data to Capacity Decisions

Capacity is not equivalent to the amount of hardware installed. A system may possess substantial nominal capacity while delivering poor service because of bottlenecks in databases, connection pools, network links, storage latency, software locks, or human operating procedures. Capacity must therefore be interpreted in relation to a service objective. For example, a platform may be considered adequate only if it supports 2,000 requests per second while maintaining a 99th-percentile latency below 300 milliseconds and an agreed error rate.

Utilization measures the proportion of a resource being consumed. CPU utilization, memory pressure, disk throughput, storage occupancy, network bandwidth, queue depth, and database connections are common examples. Average utilization is useful for identifying broad trends, but it can conceal bursts and saturation. Percentiles, maximum values, duration above threshold, and correlated resource behaviour provide a more reliable picture. A service operating at 45 percent average CPU may still fail during short traffic peaks if its load balancer, database, or dependency reaches saturation.

A useful capacity review distinguishes four levels:

• Installed capacity: the resources provisioned or available.
• Effective capacity: the usable capacity after operating-system, platform, replication, and safety overheads.
• Committed capacity: the portion reserved for known workloads or contractual obligations.
• Headroom: capacity deliberately kept available for bursts, failures, maintenance, and forecast uncertainty.

Headroom is not waste by definition. It is an investment in resilience and flexibility. Excessive headroom, however, may indicate overprovisioning. The appropriate amount depends on demand variability, scaling speed, failure consequences, recovery objectives, and the cost of additional resources.

Capacity planning commonly examines three horizons. Short-term planning manages seasonal events, releases, campaigns, and known workload changes. Medium-term planning addresses architectural limits, procurement commitments, and platform migration. Long-term planning considers business growth, product strategy, geographic expansion, regulatory obligations, and major technology investments. Each horizon requires different confidence levels and decision mechanisms.

Forecasting Demand and Recognizing Uncertainty

Demand forecasting estimates future workload using historical observations, business plans, product assumptions, and external drivers. Workload may be represented by requests per second, transactions per hour, active users, data volume, messages, jobs, or support cases. A forecast should identify both central expectation and uncertainty. A single number encourages false precision; a range or scenario set is more useful.

A simple trend model is:

Forecast demand = baseline demand + trend + seasonal effect + event effect

Baseline demand represents the normal workload. Trend captures sustained growth or decline. Seasonality describes recurring patterns such as daily, weekly, or annual cycles. Event effects include product launches, marketing campaigns, regulatory deadlines, or unusual incidents. More advanced approaches may use exponential smoothing, regression, time-series models, or machine-learning forecasting. Their value depends on data quality and the stability of the environment; sophisticated models cannot compensate for missing telemetry or a major change in business assumptions.

Scenario planning is particularly important in DevOps. A capacity plan may define a likely case, a high-growth case, and a stress case. Each scenario should specify assumptions, indicators that would confirm or reject it, and actions that can be taken. Forecasts should also be reviewed after architectural changes because caching, batching, compression, or a new user journey can alter the relationship between business demand and infrastructure demand.

A practical planning rule is to establish a trigger rather than waiting for failure. For instance, an organization may begin database partitioning when storage reaches 65 percent, initiate procurement when forecasted capacity crosses a committed limit, and conduct an emergency review when queue latency exceeds its service objective for two consecutive measurement periods. Triggers should be tied to lead time: the earlier a resource takes to acquire or implement, the earlier its warning threshold must be.

Queueing, Saturation, and the Nonlinearity of Performance

Queueing theory provides a conceptual foundation for understanding why performance often deteriorates rapidly near saturation. A system receives arrivals, processes them using one or more servers, and places excess work in a queue. If the arrival rate is represented by λ and the service rate by μ, utilization can be approximated as ρ = λ/μ for a single-server system. As ρ approaches 1, waiting time tends to increase sharply. In real systems, there may be multiple servers, priorities, retries, dependencies, and finite buffers, but the basic insight remains: high utilization reduces the ability to absorb variability.

Little’s Law expresses a widely useful relationship:

L = λW

where L is the average number of items in the system, λ is the average arrival rate, and W is the average time an item spends in the system. In an API platform, if 200 requests per second are in steady state and the average response time is 0.5 seconds, approximately 100 requests are simultaneously in the system. This relationship helps engineers validate telemetry and reason about the effect of reducing latency or controlling arrival rates.

Queues may occur in message brokers, thread pools, database connection pools, storage systems, and human approval processes. A growing queue is not always evidence that more servers are required. It may indicate slow downstream services, inefficient queries, retry storms, a traffic burst, or an intentionally asynchronous design. Capacity decisions should therefore examine the entire service dependency graph.

A critical operational distinction is between utilization and saturation. Utilization measures use; saturation measures inability to accept more work without delay, rejection, or degradation. Saturation indicators include queue depth, throttling, dropped packets, rejected connections, CPU steal time, garbage-collection pauses, and rate-limit responses. These indicators often provide earlier warning than user-visible failures.

Scalability Models and Architectural Choices

Vertical scaling increases the capacity of an individual resource by adding CPU, memory, storage performance, or network capability. It is often simple and operationally efficient, but hardware limits, cost escalation, and single-node failure risk constrain it. Horizontal scaling adds instances or workers. It can improve elasticity and fault tolerance, but requires stateless design, load distribution, coordination, data partitioning, and careful control of shared dependencies.

Elastic scaling adjusts capacity in response to workload. Reactive autoscaling uses observed indicators such as CPU, request rate, queue depth, or latency. Predictive scaling uses forecasts or scheduled events. Reactive policies are flexible but may respond too slowly to sudden demand; predictive policies can reduce delay but depend on forecast accuracy. Scaling policies should include stabilization windows, cooldown periods, minimum and maximum limits, and protection against oscillation.

The scalability of a system also depends on its architecture. Caching can reduce repeated computation and database load, though stale data and invalidation complexity must be managed. Asynchronous messaging can smooth bursts and isolate components, but it introduces eventual consistency and queue-management responsibilities. Sharding distributes data, but complicates transactions and rebalancing. Serverless execution can reduce idle capacity, but introduces cold starts, invocation charges, concurrency limits, and platform dependence. Managed services reduce operational burden, though their pricing and portability require scrutiny.

The right question is not “Which architecture scales best?” but “Which architecture provides acceptable performance, resilience, cost, and changeability for the workload and risk profile?” A design that handles extreme demand at very high cost may be inferior to a moderately scalable design with clear degradation controls and economical operation.

Unit Economics and the Economics of Telemetry

Unit economics connects expenditure with a meaningful unit of business or technical activity. Examples include cost per transaction, cost per active customer, cost per API call, cost per gigabyte processed, cost per successful order, and cost per incident resolved. Unit measures reveal whether growth is economically healthy. Total cloud spending may rise while cost per transaction falls, which can be acceptable; conversely, stable spending may conceal deteriorating efficiency if transaction volume declines.

A unit-cost calculation should define its boundary. For example:

Cost per successful transaction = attributable platform cost / number of successful transactions

Attributable cost may include compute, storage, network transfer, databases, observability, support, and shared platform services. Allocation is difficult when resources serve multiple products. Organizations may use direct tagging, shared-cost allocation rules, usage proportions, or proxy drivers. The method should be transparent and consistent rather than falsely precise.

Telemetry has direct and indirect costs. Direct costs include metric ingestion, log indexing, trace storage, data transfer, query execution, dashboard services, and retention. Indirect costs include agent overhead, storage administration, engineer time, alert fatigue, and the opportunity cost of processing irrelevant data. High-cardinality labels can multiply metric series; verbose debug logs can increase ingestion during incidents; long retention can create substantial archival expense.

Telemetry optimization should preserve decision value. Sampling traces, filtering low-value logs, aggregating metrics, separating hot and cold storage, applying retention tiers, and controlling label cardinality are common techniques. A telemetry policy should classify data according to operational purpose: real-time alerting may require high-resolution data, while capacity analysis may use downsampled historical data. Compliance or forensic requirements may justify longer retention, but such requirements should be explicit.

FinOps as an Operating Model

FinOps is a cross-functional approach to managing technology consumption and value. It brings engineering, finance, product, procurement, security, and leadership into a shared decision process. Its central principle is that teams should understand the financial consequences of the resources they consume while retaining the ability to move quickly.

A mature FinOps practice generally develops through three complementary activities. First, organizations create visibility through billing exports, tagging, account structure, dashboards, budgets, and allocation rules. Second, teams optimize by rightsizing, eliminating idle resources, selecting appropriate purchasing commitments, improving architecture, and managing data transfer and storage. Third, organizations operate with governance: budgets, forecasts, anomaly detection, policy controls, accountability, and regular review.

Common cloud pricing mechanisms include on-demand consumption, reservations or committed-use discounts, spot or interruptible capacity, tiered pricing, and enterprise agreements. Commitments may reduce unit price but create utilization risk. Spot capacity may be economical for fault-tolerant batch workloads but unsuitable for stateful or latency-sensitive services without appropriate design. Pricing decisions must therefore be evaluated against workload variability and business criticality, not price alone.

Cost optimization should avoid harmful local decisions. Reducing replicas may lower a team’s bill while increasing outage probability. Removing logs may reduce storage cost while weakening incident investigation. A balanced optimization proposal states the expected saving, performance effect, reliability effect, security and compliance implications, implementation cost, and reversal plan.

Strategic Decisions: Build, Buy, Outsource, or Migrate

Capacity and cost evidence often informs decisions beyond resource configuration. Organizations may build an internal platform, buy a managed product, outsource operations, or migrate workloads between providers. These choices involve total cost of ownership rather than visible purchase price.

Total cost of ownership may include licenses, infrastructure, personnel, training, integration, migration, support, downtime exposure, compliance, contract management, and exit costs. A managed service may have a higher direct price but reduce staffing requirements and operational risk. Conversely, a proprietary service may accelerate delivery while creating switching costs and concentration risk.

A decision matrix can compare alternatives against weighted criteria such as:

• service performance and scalability;
• reliability and recovery capability;
• security, privacy, and regulatory fit;
• three- to five-year total cost;
• implementation time and organizational capability;
• portability and exit feasibility;
• vendor support and strategic alignment.

Financial models should include sensitivity analysis. If a decision is profitable only under one optimistic growth assumption, it is fragile. Real-options thinking is useful where uncertainty is high: a reversible, incremental investment may be preferable to a large irreversible commitment, even if its nominal unit cost is higher.

Executive Scorecards and Decision Communication

Executives rarely need every metric collected by an observability platform. They need a coherent account of whether services are meeting business commitments, what risks are emerging, what resources are being consumed, and which decisions require attention. An executive scorecard should therefore connect operational indicators to outcomes.

A balanced scorecard may contain four perspectives:

1. Customer and service: availability, successful transaction rate, latency against service objectives, and major customer-impacting incidents.

2. Capacity and resilience: utilization trends, saturation risk, forecast horizon, recovery-test status, and critical dependency exposure.

3. Economics: total cost, unit cost, forecast variance, savings realized, commitment utilization, and telemetry cost.

4. Delivery and risk: change failure rate, deployment frequency, unresolved high-risk findings, technical debt, and regulatory obligations.

Each metric needs a definition, owner, time period, target, trend, confidence level, and action threshold. A red indicator without an accountable owner is not governance. Scorecards should show trends rather than isolated values and should distinguish actual results from forecasts. They should also avoid vanity metrics. A high deployment frequency is not automatically valuable if it increases failed changes or customer harm.

Executive communication should present choices, not merely problems. A strong decision brief states the situation, evidence, alternatives, recommendation, financial impact, risks, assumptions, and decision required. Technical uncertainty should be disclosed. Presenting a forecast as a certainty undermines trust and can lead to inappropriate investment.

Illustrative Case Study: Capacity and Cost Review at Northstar Payments

Background

Northstar Payments, a fictional regional payment platform, operates APIs for merchants and mobile applications. Its transaction volume has grown steadily, while the company has adopted multiple cloud services for compute, databases, messaging, logs, and distributed tracing. The engineering organization reports excellent average CPU utilization, but finance reports that cloud expenditure is rising faster than revenue.

Situation and Problem

During promotional events, 99th-percentile API latency exceeds the service objective and payment retries increase. A review finds that average CPU utilization is 48 percent, but the primary database reaches 88 percent utilization, the connection pool is frequently exhausted, and the message queue grows during bursts. Observability spending has also increased because every application instance emits verbose logs and unsampled traces. The executive committee must decide whether to purchase larger database capacity, redesign the transaction path, reduce telemetry, or move parts of the platform to a managed payment-processing service.

Analysis

The team first establishes workload and cost units: successful transactions, failed transactions, and cost per successful transaction. It separates fixed platform costs from variable processing costs and identifies shared services. Forecast scenarios show likely growth of 25 percent, with a stress case of 60 percent during a major campaign.

Queue analysis indicates that database service time, rather than API CPU, is the dominant constraint. The growing message queue confirms that average CPU is an inadequate capacity indicator. Little’s Law provides a consistency check between queue length, arrival rate, and waiting time. Tracing shows repeated database reads that can be cached, while logs contain high-volume health-check messages with limited diagnostic value.

The alternatives are evaluated as follows. Buying a larger database offers rapid relief but increases fixed cost and does not address inefficient queries. Query optimization and caching require engineering effort but reduce recurring load. Queue-based asynchronous processing can absorb bursts, although payment authorization itself must preserve appropriate consistency. Telemetry sampling and log filtering can lower cost without eliminating critical audit events. Outsourcing payment processing could reduce operational responsibility but would introduce fees, integration work, vendor dependence, and data-governance concerns.

Approach and Strategy

Northstar adopts a staged strategy. It optimizes the highest-cost queries, introduces bounded caching for suitable reference data, and increases database capacity temporarily to protect the upcoming campaign. It retains full-fidelity audit records while filtering health-check logs and sampling ordinary traces; errors, slow transactions, and selected high-risk flows remain unsampled. Autoscaling limits are revised using queue depth and latency, not CPU alone.

The FinOps team creates product-level cost allocation and reports cost per successful transaction monthly. Engineering owns resource efficiency, finance owns forecast reconciliation, and product leaders review the relationship between feature demand and capacity. A managed-service migration is postponed until a more complete total-cost and exit-risk analysis is available.

Outcome

In this illustrative case, the staged approach reduces immediate saturation risk and improves the relationship between transaction growth and cost. More importantly, it gives executives a transparent basis for future investment. The organization avoids treating a single metric, such as average CPU, as a complete representation of capacity.

Learning Points

The case demonstrates five principles: bottlenecks must be located across the dependency chain; capacity decisions should use scenarios and lead times; telemetry must be optimized according to information value; unit economics improves strategic visibility; and reversible interventions are valuable when demand and architectural outcomes remain uncertain.

Risks, Governance, and Professional Responsibilities

Capacity decisions can create safety, privacy, and fairness consequences. Underprovisioning a public service may deny access to users; aggressive cost controls may degrade support for less profitable customers; and automated scaling may process sensitive data across inappropriate regions. Telemetry can contain personal or confidential information, especially in logs and traces. Data minimization, access control, encryption, retention limits, masking, and lawful processing are therefore part of capacity and cost governance.

Organizations should define who may change scaling limits, commitments, retention settings, and production architectures. Emergency actions require audit trails and post-incident review. Cost anomaly detection should not automatically terminate critical workloads without safeguards. Vendor contracts should address service levels, data location, portability, support, billing transparency, and termination assistance.

Common mistakes include optimizing averages instead of percentiles, treating cloud elasticity as unlimited, ignoring data-transfer costs, purchasing commitments without utilization analysis, allocating shared costs arbitrarily, cutting observability during incidents, and reporting savings without measuring service impact. Another error is confusing correlation with causation: a cost increase after a release does not prove that the release caused it unless workload, pricing, and resource changes are examined.

Automation, Analytics, and Emerging Practice

Automation increasingly supports capacity and FinOps operations. Infrastructure-as-code can enforce tagging, region restrictions, retention policies, and resource limits. Automated rightsizing can identify underused instances, while anomaly detection can flag unexpected spending or traffic. Forecasting systems can recommend capacity changes, but recommendations should remain subject to policy, explainability, and human review for high-impact services.

A developing practice is the use of sustainability-aware optimization. Carbon intensity, hardware utilization, data movement, and workload timing may be incorporated alongside cost and performance. Another trend is platform engineering, in which internal platforms provide standardized deployment, observability, and cost controls. These platforms can improve governance, but excessive abstraction may conceal resource consumption from application teams.

AI-assisted operations can correlate telemetry, summarize incidents, and estimate the likely effect of scaling actions. Its limitations include biased or incomplete data, hallucinated explanations, feedback loops, and unsafe automated changes. AI should therefore be treated as decision support unless controls, testing, authorization, and rollback mechanisms justify greater autonomy.

Best Practices for Strategic Capacity and Cost Management

A robust practice begins with reliable telemetry and explicit service objectives. Organizations should:

• measure demand, saturation, latency, reliability, and cost together;
• forecast using trends, seasonality, business events, and multiple scenarios;
• plan from bottlenecks and dependency behaviour rather than average CPU alone;
• define headroom and triggers according to risk and procurement lead time;
• calculate unit economics with transparent allocation boundaries;
• classify telemetry by purpose, value, sensitivity, and retention requirement;
• review commitments, idle resources, architecture, and data transfer regularly;
• make cost and reliability ownership visible to product and engineering teams;
• use scorecards that show trends, targets, confidence, and accountable actions;
• evaluate alternatives through total cost, reversibility, risk, and strategic fit;
• validate automated recommendations and preserve rollback capability.

Chapter Summary

Capacity planning links utilization, demand forecasts, bottlenecks, scalability, and resilience. Queueing concepts explain why performance can degrade sharply as utilization approaches saturation, while Little’s Law connects throughput, work in progress, and response time. Effective planning uses scenarios, headroom, lead-time-based triggers, and dependency-aware analysis.

Cost optimization seeks value rather than expenditure reduction alone. Unit economics, total cost of ownership, telemetry-cost analysis, and FinOps practices help organizations understand how technical consumption affects business outcomes. Architecture, platform, outsourcing, and migration choices require analysis of performance, reliability, security, portability, and reversibility as well as price.

Executive scorecards translate technical evidence into decisions by combining customer service, capacity, economics, delivery, and risk perspectives. Ethical governance requires responsible treatment of telemetry, transparent allocation, accountable automation, and protection against cost controls that undermine reliability or equitable service. The central strategic lesson is that capacity, cost, and performance are one interconnected decision system.

Key Terms

Capacity planning: The process of ensuring sufficient resources to meet expected demand and service objectives.

Utilization: The proportion of a resource’s available capability that is being consumed.

Effective capacity: Usable capacity after platform, replication, operating, and safety overheads.

Headroom: Deliberately uncommitted capacity reserved for variability, failure, maintenance, and growth.

Saturation: A condition in which additional workload causes delay, rejection, degradation, or instability.

Demand forecasting: Estimating future workload from historical data, trends, events, and assumptions.

Queueing theory: The study of waiting lines and the relationship among arrivals, service, utilization, and delay.

Little’s Law: The relationship L = λW between items in a system, arrival rate, and time in the system.

Horizontal scaling: Increasing capacity by adding instances, workers, or nodes.

Vertical scaling: Increasing the capability of an existing resource.

Elasticity: The ability to adjust resources in response to workload changes.

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

Total cost of ownership: The complete cost of acquiring, operating, changing, governing, and retiring a solution.

FinOps: A cross-functional operating model for maximizing value from technology consumption.

Telemetry cost: Direct and indirect expenditure associated with collecting, storing, processing, and using observability data.

Cost allocation: Assigning shared or direct expenditure to products, teams, services, or business units.

Executive scorecard: A concise decision-oriented view of service, capacity, financial, delivery, and risk performance.

Real-options thinking: Valuing flexibility and reversibility when future conditions are uncertain.

Review Questions

Short Answer Questions

1. Distinguish installed capacity, effective capacity, and headroom.

2. Why can average CPU utilization provide an inadequate basis for capacity planning?

3. State Little’s Law and explain its variables.

4. What is meant by unit economics in a cloud-based service?

5. Identify two direct and two indirect costs of telemetry.

Long Answer Questions

1. Explain how demand forecasting, headroom, and lead-time-based triggers work together in a capacity plan.

2. Discuss vertical scaling, horizontal scaling, and elasticity, including their architectural trade-offs.

3. Explain FinOps as an operating model and describe its visibility, optimization, and governance activities.

4. Design an executive scorecard for a critical digital service and justify the measures selected.

5. Discuss how total cost of ownership should influence build, buy, outsource, and migrate decisions.

Analytical / Application Questions

1. A service receives 400 requests per second and has an average response time of 250 milliseconds. Use Little’s Law to estimate the average number of requests in the system. Explain what additional telemetry would be needed before making a scaling decision.

2. A company reduces log retention and removes replicas to lower its cloud bill. Analyze the likely reliability, diagnostic, compliance, and financial consequences, and propose a safer alternative.

3. A database reaches 85 percent utilization while application CPU remains below 40 percent, and queue latency rises during campaigns. Develop a staged capacity and cost strategy using forecasting, architecture, telemetry optimization, and executive reporting.

22. Multiple Choice Questions with Answers

Question 1

Which observation most strongly indicates that average CPU utilization is insufficient for a capacity decision?

A. CPU averages 45 percent while a database connection pool is repeatedly exhausted

B. CPU averages 45 percent and storage is mostly empty

C. CPU averages 45 percent and deployment frequency is increasing

D. CPU averages 45 percent and the service has a documented owner

Correct Answer: A. CPU averages 45 percent while a database connection pool is repeatedly exhausted

Question 2

According to Little’s Law, if a steady-state service receives 200 requests per second and average response time is 0.5 seconds, what is the approximate number of requests in the system?

A. 40

B. 100

C. 200

D. 400

Correct Answer: B. 100

Question 3

Why does waiting time often increase sharply as utilization approaches 100 percent?

A. Pricing automatically increases at high utilization

B. Variability leaves little spare capacity to absorb bursts

C. Horizontal scaling becomes impossible in every architecture

D. Telemetry stops collecting data at saturation

Correct Answer: B. Variability leaves little spare capacity to absorb bursts

Question 4

Which measure is most directly associated with unit economics?

A. Total number of dashboards

B. Number of engineering meetings

C. Cost per successful transaction

D. Maximum number of resource tags

Correct Answer: C. Cost per successful transaction

Question 5

Which telemetry optimization best preserves high-value diagnostic information?

A. Delete all traces during incidents

B. Retain audit and error data while sampling ordinary traces

C. Disable metrics for low-utilization services

D. Store every debug log indefinitely

Correct Answer: B. Retain audit and error data while sampling ordinary traces

Question 6

What is a central purpose of FinOps?

A. Transfer all financial responsibility to procurement

B. Maximize technology value through shared visibility and accountability

C. Eliminate all cloud commitments

D. Replace service-level objectives with budgets

Correct Answer: B. Maximize technology value through shared visibility and accountability

Question 7

Which factor should be included in a build-versus-buy total-cost analysis?

A. Only the vendor’s advertised monthly price

B. Only the initial implementation effort

C. Migration, staffing, integration, support, and exit costs

D. Only average CPU utilization

Correct Answer: C. Migration, staffing, integration, support, and exit costs

Question 8

Which executive scorecard measure best connects financial performance with workload growth?

A. Number of alerts created

B. Cost per successful transaction over time

C. Number of dashboard panels

D. Count of infrastructure resources

Correct Answer: B. Cost per successful transaction over time

Question 9

A queue grows while application CPU remains low. What is the most appropriate initial interpretation?

A. The system definitely needs more application CPU

B. A downstream bottleneck or service-time problem may exist

C. The queue proves that all telemetry is inaccurate

D. The workload should immediately be outsourced

Correct Answer: B. A downstream bottleneck or service-time problem may exist

Question 10

Why can purchasing a discounted cloud commitment create risk?

A. Discounts always increase latency

B. The organization may pay for capacity it does not use

C. Commitments prevent all forms of autoscaling

D. Committed resources cannot be monitored

Correct Answer: B. The organization may pay for capacity it does not use