Cloud Strategy, Migration and Digital Transformation

Introduction and Context

Cloud adoption is no longer primarily a decision about renting servers. It is a strategic redesign of how an organization acquires technology, delivers products, manages risk, and learns from data. Cloud platforms provide elastic infrastructure, managed services, automation, globally distributed delivery, and programmable security controls. These capabilities can improve agility and resilience, but they do not automatically produce business value. Poorly governed adoption can increase expenditure, create regulatory exposure, fragment architecture, and reproduce inefficient processes at a larger scale.

Cloud strategy therefore connects business objectives with technology choices. It addresses which capabilities should move to cloud, why they should move, which operating model will support them, how value will be measured, and how people and processes must change. Migration is one component of this strategy; digital transformation is the broader organizational outcome.

A useful distinction is:

• Cloud migration: moving applications, data, infrastructure, or capabilities from one environment to another, often from on-premises systems to public, private, or hybrid cloud.
• Cloud modernization: changing architecture, platforms, or delivery practices to gain cloud-native benefits such as automation, elasticity, resilience, and rapid release.
• Digital transformation: redesigning products, processes, customer experiences, and organizational capabilities through digital technologies and new operating practices.

Migration without modernization may deliver data-center exit or capacity flexibility but leave technical debt intact. Modernization without strategic alignment may produce technically elegant systems with weak economic or business justification.

Learning Objectives

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

1. Explain the relationship among cloud strategy, migration, modernization, and digital transformation.

2. Design an appropriate cloud adoption and operating model.

3. Assess workload suitability, organizational readiness, risk, and business value.

4. Select among rehost, replatform, refactor, repurchase, retain, and retire pathways.

5. Construct and evaluate a cloud business case, including total cost and non-financial value.

6. Plan governance, security, skills, change management, and continuous improvement.

7. Critically evaluate limitations, ethical issues, and contemporary developments in cloud transformation.

Strategic Foundations of Cloud Adoption

From technology procurement to capability management

Traditional IT commonly treats infrastructure as a capital asset acquired through periodic projects. Cloud changes this pattern toward services consumed on demand and paid for according to use, commitment, or subscription. The strategic consequence is not merely a different invoice. Responsibility shifts toward product teams, engineering practices, financial management, vendor governance, and continuous optimization.

A mature strategy begins with business outcomes such as faster product launch, improved service availability, regulatory compliance, geographic expansion, analytics capability, or reduced data-center dependence. Technology outcomes—such as container adoption or serverless computing—should be treated as means rather than ends.

Cloud adoption models

An adoption model defines the scope, sequence, and governance of cloud use. Common models include:

Centralized model. A central IT or cloud center of excellence controls architecture, platforms, standards, and much of delivery. This supports consistency and risk control, but can become a bottleneck.

Federated model. Business units or product teams retain substantial autonomy within enterprise guardrails. This improves responsiveness but requires strong standards, identity management, financial transparency, and platform engineering.

Product-platform model. A platform team provides reusable “internal products,” such as landing zones, identity integration, observability, deployment pipelines, and approved data services. Product teams consume these capabilities while remaining accountable for business outcomes. This model often combines autonomy with standardization.

Multi-cloud or hybrid model. Workloads are distributed across multiple providers or between cloud and on-premises environments. Such arrangements may be justified by regulation, resilience, acquisition history, specialized services, or negotiation leverage. They also introduce portability costs, duplicated skills, inconsistent controls, and more complex operations. Multi-cloud should be a deliberate risk or capability choice, not an automatic assumption that more providers are always safer.

The cloud operating model

A cloud operating model specifies how people, processes, technology, and accountability work together. Its major design dimensions are:

• Decision rights: who approves architecture, security exceptions, spending, data use, and vendor selection.
• Accountability: who owns an application’s availability, cost, security, data quality, and business performance.
• Platform services: standardized networking, identity, logging, backup, policy enforcement, and developer tooling.
• Ways of working: product management, agile delivery, DevSecOps, automation, and continuous improvement.
• Skills and organization: cloud engineering, security engineering, reliability, data, finance, procurement, and change leadership.
• Controls and evidence: policies, automated checks, audit trails, risk registers, and performance metrics.

Cloud introduces a shared-responsibility model. The provider is generally responsible for security of the underlying cloud service, while the customer remains responsible for security in the service, including identities, configurations, data, applications, and—depending on the service model—operating systems and networks. The exact boundary varies among infrastructure, platform, and software services and must be verified in provider documentation and contracts.

Assessing Organizational Readiness

A migration program should not begin with a provider-specific design. It should begin with an assessment of readiness and constraints. A practical assessment covers six dimensions:

1. Strategic readiness: Are desired outcomes measurable and sponsored by accountable executives?

2. Portfolio readiness: Are applications, dependencies, data flows, owners, licenses, and service levels known?

3. Technical readiness: Can systems be securely connected, observed, automated, and operated in the target environment?

4. Operational readiness: Are incident response, backup, disaster recovery, service management, and support arrangements defined?

5. People readiness: Do teams possess or have access to architecture, security, platform, data, and financial-management skills?

6. Governance readiness: Can the organization enforce policy, meet regulatory obligations, manage suppliers, and control exceptions?

Readiness should produce evidence rather than a subjective label. Examples include an application inventory with dependency confidence, tested recovery procedures, an identity integration plan, trained personnel, and documented data classifications.

A cloud center of excellence (CCoE) can accelerate readiness by providing standards, reference architectures, coaching, reusable automation, and communities of practice. It should enable delivery rather than become a permanent approval bureaucracy. Over time, mature organizations often distribute knowledge into product teams while retaining a small group for architecture, policy, platform evolution, and complex risk.

Workload Discovery and Classification

The unit of migration is usually a workload: an application and its data, integrations, operational processes, and users. A technically correct server inventory is insufficient because application dependencies and business criticality determine migration risk.

For each workload, collect:

• business owner and technical owner;
• business capability and user population;
• architecture, runtime, interfaces, and data stores;
• performance, availability, recovery time objective (RTO), and recovery point objective (RPO);
• data sensitivity, residency, retention, and legal requirements;
• utilization patterns and seasonality;
• licensing and support constraints;
• technical debt and modernization potential;
• migration complexity, dependencies, and acceptable outage window.

Workloads can be classified by business criticality, data sensitivity, architectural coupling, volatility of demand, and transformation potential. A stable, low-risk internal application may be a suitable early candidate. A highly coupled payment system with strict recovery and regulatory requirements may require extensive preparation or temporary retention.

Portfolio analysis should identify migration waves. A wave is a group of workloads selected for a coherent business and technical reason—for example, an application and its database, or several services supporting one product. “Move everything” is not a migration strategy; sequencing reduces risk and creates learning.

The Six Migration Pathways

The commonly used “six Rs” are decision patterns rather than rigid categories. A workload may use different pathways for its application, database, and surrounding processes.

Rehost

Rehosting, or lift-and-shift, moves a workload with minimal code or architecture change. It is fast and useful for data-center exit, contract deadlines, or applications that are stable but not worth redesigning immediately. Its limitations include preserving inefficient architecture, weak elasticity, and possibly poor cloud economics. Rehosting should include security, monitoring, backup, and operational redesign; “minimal code change” does not mean “no engineering work.”

Replatform

Replatforming makes limited changes to use managed services or a more suitable runtime without fundamentally redesigning the application. Examples include moving a database to a managed relational service, adopting a managed Kubernetes platform, or changing the operating system image. It may reduce maintenance and improve reliability while controlling risk. Compatibility, performance, and service limits must be tested.

Refactor or re-architect

Refactoring changes the internal design substantially to exploit cloud capabilities. Examples include decomposing a monolith, introducing asynchronous messaging, designing stateless services, using elastic data services, or implementing automated delivery. Refactoring can improve agility and resilience but requires strong product ownership, testing, observability, domain understanding, and sustained investment. It is not justified solely by the popularity of a technology.

Repurchase

Repurchasing replaces an existing system with a commercial or cloud-based product, often delivered as software as a service. It can reduce custom maintenance and accelerate capability acquisition. Evaluation must include data portability, integration, configuration limits, subscription escalation, exit terms, privacy, and whether the organization is exchanging technical debt for vendor dependence.

Retain

Retention keeps a workload in its current environment temporarily or permanently. Reasons include regulatory restrictions, unresolved dependencies, stable economics, latency requirements, contractual constraints, or insufficient business value. Retain should be an explicit decision with a review date, not an unexamined default.

Retire

Retirement removes a workload or capability that is redundant, unused, or replaced. It often produces the greatest savings and risk reduction because it eliminates licenses, interfaces, vulnerabilities, and operational effort. Retirement requires evidence of non-use, data retention decisions, stakeholder approval, and a rollback or archival plan where necessary.

Decision criteria

A pathway decision should balance business value, risk, feasibility, time, and long-term architecture. A simple weighted decision model can structure discussion:

\[S = \sum_{i=1}^{n} w_i x_i\]

where \(S\) is the option score, \(w_i\) is the weight assigned to criterion \(i\), and \(x_i\) is the normalized score for that criterion. The weights should sum to 1, and all criteria must use a consistent scale, such as 0 to 100. This model supports comparison; it does not replace expert judgment or risk acceptance. Criteria might include business value, migration effort, compliance fit, operational risk, time to value, and strategic alignment. Sensitivity analysis should test whether a small change in weights reverses the decision.

Building the Cloud Business Case

A credible business case compares realistic alternatives over a defined period. Relevant cost categories include:

• compute, storage, database, network, backup, and observability consumption;
• provider support, subscriptions, marketplace products, and software licenses;
• migration tooling, data transfer, testing, remediation, and dual running;
• personnel training, recruitment, consulting, and operating-model change;
• security, compliance, resilience, and service-management controls;
• decommissioning, contract termination, and retained infrastructure;
• opportunity costs and expected productivity effects.

The appropriate comparison is not “cloud bill versus server purchase.” It is the total cost and value of feasible alternatives, including the cost of capital, facilities, labor, downtime, risk, and modernization. Cloud costs are variable and can be difficult to forecast; on-premises costs may be under-allocated or hidden in shared services.

For an investment evaluation, a basic net present value model is:

\[NPV = \sum_{t=0}^{T} \frac{B_t-C_t}{(1+r)^t}\]

where \(B_t\) is benefit in period \(t\), \(C_t\) is cost in period \(t\), \(r\) is the discount rate per period, and \(T\) is the evaluation horizon. Cash flows must be measured consistently, and assumptions about inflation, taxes, residual value, and risk must be documented. NPV is useful for comparable financial alternatives but may undervalue strategic flexibility, learning, customer experience, or regulatory necessity. Scenario analysis should examine demand growth, provider pricing, exchange rates, migration delay, and expected utilization.

FinOps applies financial accountability and engineering practices to variable technology consumption. It links finance, engineering, procurement, and product management. Practices include tagging and allocation, budgets and alerts, rightsizing, commitment management, architectural cost reviews, unit economics, and accountability for waste. Cost optimization must not sacrifice security, resilience, or customer outcomes. A low bill achieved by under-provisioning may simply transfer cost to outages.

Useful measures include cost per transaction, cost per active customer, deployment frequency, lead time for changes, change failure rate, service availability, recovery performance, incident volume, and customer experience. These metrics should be interpreted together: speed without reliability is not transformation success.

Migration Governance and Delivery

A disciplined migration is usually iterative:

1. Define outcomes and guardrails. Establish scope, success measures, risk appetite, security requirements, and decision rights.

2. Discover and assess. Build a dependency-aware portfolio and classify data and workloads.

3. Design the foundation. Create accounts or subscriptions, identity, network connectivity, logging, security baselines, policy enforcement, backup, and landing-zone automation.

4. Pilot and learn. Select a representative but manageable workload. Test performance, security, operations, cost, and rollback.

5. Migrate in waves. Use rehearsals, runbooks, automated testing, migration factories where appropriate, and explicit go/no-go criteria.

6. Stabilize and optimize. Measure actual outcomes, remove temporary controls, tune performance and cost, and decommission obsolete assets.

7. Modernize selectively. Refactor where evidence shows sufficient value and readiness.

A landing zone is a governed baseline for cloud use. It normally includes identity federation and privileged-access controls, network patterns, account or subscription structure, centralized logs, security monitoring, encryption and key management, policy-as-code, vulnerability management, backup, and cost allocation. It is not a one-time product; it evolves with threats and services.

Migration plans must include cutover, data synchronization, validation, rollback, communications, and support. Testing should include functional, performance, security, resilience, integration, and operational acceptance. A migration is complete only when the service is usable, supportable, secure, observable, and economically understood.

Digital Transformation and Organizational Change

Digital transformation changes relationships among customers, employees, processes, information, and technology. Cloud enables transformation through rapid experimentation, scalable digital channels, data platforms, automation, and globally accessible services; it does not determine the business model.

The strongest transformation programs organize around products or value streams rather than temporary projects. A product team has a durable mission, customer measures, engineering capability, and authority to improve continuously. Platform teams reduce cognitive load by offering secure, reusable capabilities. Site reliability engineering (SRE) contributes reliability practices such as service-level objectives, error budgets, automation, and learning from incidents. DevSecOps integrates security and compliance into delivery rather than leaving them to a final checkpoint.

Change management is substantive, not ceremonial. Leaders should explain why change is needed, involve affected groups, provide role-specific training, recognize new responsibilities, and measure adoption. Cloud can alter job boundaries: infrastructure specialists may become platform engineers; operations staff may work with developers; finance may need consumption analytics; auditors may evaluate automated evidence. Reskilling and fair workforce transition are ethical and practical necessities.

Common failure patterns include executive sponsorship without team capacity, migration targets measured only by server counts, central teams that block delivery, uncontrolled developer autonomy, excessive dependence on consultants, and modernization undertaken without product or domain ownership.

Security, Ethics, Regulation, and Resilience

Cloud strategy must incorporate security and privacy from the beginning. Core practices include least privilege, strong authentication, separation of duties, secure software supply chains, encryption in transit and at rest, secrets management, continuous configuration assessment, vulnerability remediation, immutable or protected backups, and tested incident response.

Regulatory obligations may concern data residency, cross-border transfer, retention, financial records, health information, critical infrastructure, accessibility, and audit evidence. Legal review should address provider terms, subprocessors, breach notification, government access, service levels, portability, and termination assistance. Compliance is a shared organizational responsibility; a provider’s certification does not make every customer workload compliant.

Ethical issues include surveillance and excessive employee monitoring, opaque automated decisions, discriminatory data practices, environmental impact, unequal access to digital services, and concentration of power in large providers. Data minimization, purpose limitation, transparency, human oversight, accessibility, and impact assessment are important safeguards.

Resilience requires more than selecting multiple availability zones. Organizations should identify failure modes, define RTO and RPO, eliminate unnecessary dependencies, test restoration, and understand provider and regional failure scenarios. Multi-region or multi-cloud designs can improve some forms of resilience but add operational complexity and may create new failure modes. Resilience architecture should be proportionate to business impact.

Contemporary Developments and Critical Perspectives

Several developments are reshaping cloud strategy:

• Generative AI services increase demand for scalable compute and managed model APIs, while introducing risks involving data leakage, intellectual property, hallucination, bias, model concentration, and unpredictable consumption costs. AI workloads require model governance, evaluation, access controls, provenance, and human accountability.
• Edge and distributed cloud place computation closer to devices and users to reduce latency or support disconnected operation. They complicate fleet management, security, and data synchronization.
• Confidential computing seeks to protect data while in use through hardware-supported trusted execution environments, but requires careful assessment of threat models and provider guarantees.
• Sovereign and industry clouds respond to jurisdictional, regulatory, and sector-specific requirements. “Sovereignty” is multidimensional: location, legal control, operational control, personnel, and technology supply chain may all matter.
• Green cloud strategy considers workload efficiency, carbon-aware scheduling, hardware life cycles, and data-transfer effects. A cloud provider’s renewable-energy claims do not remove the need for customer-level measurement and responsible demand.

Critical evaluation remains essential. Cloud may increase concentration risk, reduce portability, and make architectural decisions dependent on proprietary interfaces. Open standards and containers can help in some layers but do not eliminate data gravity, operational dependence, or re-engineering costs. The strategic question is not whether cloud is universally superior, but where its capabilities produce greater value than credible alternatives.

Illustrative Case: Northstar Health Services

Background

Northstar Health Services, a fictional regional provider, operates patient scheduling, clinician collaboration, billing, and analytics systems across two data centers. Its data centers are approaching renewal, specialist administrators are difficult to recruit, and digital appointment services experience seasonal demand peaks. Patient information is subject to health-privacy and residency requirements.

Problem

The executive team proposes moving all systems to a public cloud within twelve months. The chief information officer is concerned that a rapid lift-and-shift could reproduce fragile integrations, expose sensitive records, and increase costs. Clinical leaders require uninterrupted service, while finance wants a defensible business case.

Analysis

The portfolio team discovers that the scheduling application uses a supported but tightly coupled database, the billing system depends on a licensed legacy platform, and analytics workloads are highly variable. Several unused reporting servers contain obsolete extracts. Recovery documentation is incomplete, and application ownership is unclear. The organization has strong clinical expertise but limited cloud engineering and FinOps capability.

The team classifies data by sensitivity and confirms residency, retention, access, and audit requirements with legal and privacy officers. It maps dependencies and defines service objectives. The obsolete reporting servers become retirement candidates. Analytics is a replatform candidate using managed data services with controlled ingestion. Scheduling is initially rehosted only after identity, encryption, monitoring, backup, and failover tests are established. Billing is retained temporarily because its licensing and integration risks exceed near-term value. A later repurchase assessment compares a regulated SaaS product with continued operation.

Approach and solution

Northstar establishes a small CCoE with security, platform, clinical operations, finance, and architecture representation. It builds a landing zone with federated identity, privileged-access management, centralized logging, policy controls, encryption-key management, network segmentation, and cost allocation. A pilot migrates a low-criticality administrative service. The pilot exposes an undocumented interface, leading to improved discovery rather than a production incident.

Migration waves are scheduled around clinical calendars. Each wave has data validation, rollback criteria, communications, and a named service owner. Finance introduces unit-cost reporting per appointment and per analytics query. The organization trains infrastructure staff in platform engineering and assigns product owners to patient-facing services. After stabilization, the scheduling team begins incremental refactoring of notification and availability components rather than rewriting the entire system.

Outcome

In this illustrative case, Northstar reduces data-center dependence, improves visibility of operational ownership, and handles appointment peaks more consistently. Financial results are mixed during the first year because of dual running, training, and migration work. The strongest early benefits are improved recovery testing, faster release of patient-facing changes, retirement of redundant reporting infrastructure, and clearer accountability. The case demonstrates that value emerges from sequencing, governance, and operating-model change—not from relocation alone.

Learning points

1. A strategic deadline should not eliminate workload-level analysis.

2. Sensitive workloads require legal, privacy, security, and operational evidence.

3. Retain and retire are active strategic choices.

4. Business value may initially appear as resilience, speed, or risk reduction rather than immediate savings.

5. Incremental modernization is often safer than a complete rewrite.

Challenges and Limitations

Cloud programs face uncertain consumption, price changes, supplier outages, skills shortages, migration fatigue, and conflicting stakeholder incentives. Technical debt may be underestimated because documentation is incomplete. Business cases may claim savings without accounting for dual running, egress, support, training, and retained systems. Benchmark results may not predict production behavior. Provider-native services can accelerate delivery while increasing switching costs.

No framework eliminates judgment. Weighted scores depend on assumptions; financial models depend on forecasts; readiness assessments can be biased by their authors. Organizations should document uncertainty, conduct independent review, use pilots, and revise decisions when evidence changes. Governance should control material risk without suppressing experimentation.

Best-Practice Principles

• Start with measurable business outcomes and accountable owners.
• Build an accurate, dependency-aware portfolio before selecting migration waves.
• Establish identity, security, observability, resilience, and cost controls early.
• Treat migration, modernization, and transformation as related but distinct decisions.
• Use the six Rs as hypotheses supported by evidence, not as slogans.
• Make product teams accountable for outcomes and platform teams accountable for reusable enablement.
• Automate policy, testing, provisioning, evidence collection, and safe rollback.
• Measure unit economics and service outcomes, not only infrastructure counts.
• Include privacy, accessibility, sustainability, portability, and workforce effects in strategy.
• Review the strategy continuously as technology, regulation, demand, and organizational capability evolve.

Chapter Summary

Cloud strategy aligns business outcomes, architecture, operating model, economics, governance, and organizational capability. Migration is a portfolio and change-management discipline rather than a simple infrastructure relocation. Workloads must be discovered, classified, and sequenced according to dependencies, criticality, data obligations, readiness, and value. Rehost, replatform, refactor, repurchase, retain, and retire provide practical pathways, but each involves trade-offs.

A sound business case includes total costs, dual running, risk, skills, contracts, and non-financial benefits. Cloud operating models define decision rights, platform services, product accountability, security controls, and FinOps practices. Digital transformation depends on product thinking, DevSecOps, reliability engineering, leadership, reskilling, and redesigned processes. Security, privacy, regulation, resilience, sustainability, portability, and ethical use must be integrated from the beginning. The central strategic principle is selective use: cloud creates value when its capabilities are matched to evidence-based business and technical needs.

Key Terms

Cloud strategy: A plan linking cloud capabilities to organizational objectives, risks, and investments.

Cloud migration: Movement of workloads, data, or capabilities to another operating environment.

Cloud modernization: Architectural or operational improvement intended to exploit cloud capabilities.

Digital transformation: Organizational redesign using digital technologies and new operating practices.

Cloud operating model: The arrangement of roles, decision rights, processes, platforms, and controls for operating cloud services.

Shared responsibility: Allocation of security and operational duties between provider and customer.

Cloud center of excellence: A group that enables standards, reusable practices, skills, and governance for cloud adoption.

Workload: An application, its data, dependencies, users, and operational requirements.

Rehost: Move a workload with minimal code or architecture change.

Replatform: Make limited changes to use a more suitable managed platform or service.

Refactor: Substantially redesign an application to gain architectural or operational benefits.

Repurchase: Replace a system with a commercial product or software service.

Retain: Keep a workload in its current environment for a justified reason.

Retire: Decommission a redundant or obsolete workload.

Landing zone: A governed, automated baseline for secure cloud use.

FinOps: Collaborative financial management of variable technology consumption.

RTO: Target maximum time to restore a service after disruption.

RPO: Target maximum acceptable period of data loss measured backward from disruption.

Product team: A durable, cross-functional team accountable for a product or value outcome.

Policy-as-code: Machine-enforceable rules used to assess or control configurations and deployments.

Review Questions

Short Answer Questions

1. Distinguish cloud migration from digital transformation.

2. What responsibilities commonly remain with a cloud customer under shared responsibility?

3. State two reasons why an organization might retain a workload.

4. What is the purpose of a cloud landing zone?

5. Why should a cloud business case include dual-running costs?

Long Answer Questions

1. Explain the six migration pathways and evaluate the conditions under which each is appropriate.

2. Design a cloud operating model for a large enterprise using product teams and a central platform team.

3. Discuss how FinOps, reliability engineering, and DevSecOps contribute to cloud transformation.

4. Explain how privacy, regulation, resilience, and portability should influence cloud strategy.

5. Critically assess the claim that multi-cloud automatically reduces organizational risk.

Analytical / Application Questions

1. An organization has a tightly coupled billing system, an obsolete reporting platform, and a variable-demand analytics workload. Recommend a pathway for each and justify your decisions using risk, value, and feasibility.

2. Construct a weighted decision matrix for rehost versus refactor using at least five criteria. State your weights, scoring assumptions, and sensitivity concerns.

3. A proposed migration shows lower infrastructure cost but requires eighteen months of dual running, training, and major security investment. Explain how you would revise the business case and decide whether to proceed.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes cloud modernization from cloud migration?

A. Modernization always means moving to a different provider.

B. Modernization changes architecture or operations to gain cloud capabilities.

C. Modernization only concerns contract negotiation.

D. Modernization is the retirement of unused systems.

Correct Answer: B. Modernization changes architecture or operations to gain cloud capabilities.

Question 2

Which migration pathway replaces an existing system with a commercial or SaaS product?

A. Rehost

B. Retain

C. Repurchase

D. Replatform

Correct Answer: C. Repurchase

Question 3

What is a principal purpose of a cloud landing zone?

A. To eliminate all application testing

B. To provide a governed baseline for secure cloud use

C. To guarantee the lowest possible cloud bill

D. To replace business ownership of applications

Correct Answer: B. To provide a governed baseline for secure cloud use

Question 4

In the NPV expression presented in the chapter, what does r represent?

A. The number of workloads

B. The recovery point objective

C. The discount rate per period

D. The migration completion rate

Correct Answer: C. The discount rate per period

Question 5

Which workload is the clearest candidate for retirement?

A. A regulated payment system with active users

B. A redundant reporting server confirmed to be unused

C. A patient scheduling system with strict availability needs

D. A core database supporting current transactions

Correct Answer: B. A redundant reporting server confirmed to be unused

Question 6

What is a central principle of FinOps?

A. Only finance staff are accountable for cloud cost.

B. Cloud cost should be hidden from product teams.

C. Finance, engineering, procurement, and product teams share financial accountability.

D. Security controls should be removed to reduce expenditure.

Correct Answer: C. Finance, engineering, procurement, and product teams share financial accountability.

Question 7

Why may refactoring be riskier than rehosting?

A. It requires substantial architectural change and testing.

B. It cannot improve agility.

C. It always prevents use of managed services.

D. It requires no understanding of the application domain.

Correct Answer: A. It requires substantial architectural change and testing.

Question 8

Which statement about shared responsibility is most accurate?

A. The provider is responsible for every customer configuration.

B. The customer has no security responsibilities when using SaaS.

C. Responsibilities vary by service model, and customers retain important duties.

D. Shared responsibility applies only to private clouds.

Correct Answer: C. Responsibilities vary by service model, and customers retain important duties.

Question 9

Which measure most directly expresses a recovery point objective?

A. Maximum acceptable data-loss period

B. Time required to deploy a feature

C. Cost per active customer

D. Number of cloud accounts

Correct Answer: A. Maximum acceptable data-loss period

Question 10

Why is multi-cloud not automatically a complete resilience solution?

A. It always eliminates portability concerns.

B. It can add duplicated skills, inconsistent controls, and operational complexity.

C. It prevents all regional failures.

D. It makes governance unnecessary.

Correct Answer: B. It can add duplicated skills, inconsistent controls, and operational complexity.