Architecture Decision-Making and Digital Transformation

Introduction

Serverless computing and microservices are not goals in themselves. They are architectural means for improving the speed, resilience, scalability, and economic performance of digital services. Their value depends on context: workload characteristics, regulatory obligations, team capability, operating model, existing technical debt, and the organisation’s strategic objectives. A poorly chosen migration can replace a stable monolith with a distributed system that is more expensive and difficult to operate.

Architecture decision-making is therefore a discipline of structured reasoning under uncertainty. It connects business outcomes with technical choices, makes assumptions visible, records trade-offs, and establishes evidence for later review. In digital transformation, this discipline must be applied not only to software components, but also to platforms, processes, skills, governance, suppliers, and continuity arrangements.

This chapter examines how organisations can assess workloads, choose between architectural styles, decompose monoliths, migrate to cloud platforms, manage technical debt, establish platform teams, select vendors, and measure transformation outcomes. The emphasis is on professional judgement rather than technology adoption for its own sake.

Learning Objectives

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

1. Explain how architecture decisions support digital transformation strategy.
2. Assess workloads for monolithic, microservice, serverless, or hybrid architectures.
3. Plan incremental monolith decomposition using bounded contexts and value streams.
4. Design a migration roadmap that addresses technology, people, process, risk, and governance.
5. Identify, measure, and prioritise technical debt.
6. Explain the role of platform engineering and internal developer platforms.
7. Evaluate cloud vendors using weighted criteria rather than price alone.
8. Design continuity, resilience, and exit strategies for cloud-dependent systems.
9. Define measurable transformation outcomes and distinguish outputs from benefits.
10. Critically evaluate ethical, regulatory, organisational, and operational risks.

1. Architecture as a Strategic Decision Discipline

An architecture decision concerns a significant choice whose consequences are long-lived or difficult to reverse. Examples include selecting an event broker, adopting a serverless execution model, choosing a cloud region strategy, decomposing a customer-management monolith, or standardising on a database technology.

A useful architecture decision record (ADR) contains:

• Context: the business and technical situation.
• Decision: the selected approach.
• Options considered: credible alternatives, including doing nothing.
• Decision drivers: security, cost, reliability, speed, compliance, skills, or other priorities.
• Consequences: benefits, risks, constraints, and follow-on work.
• Evidence: experiments, benchmarks, incident data, or stakeholder analysis.
• Review trigger: circumstances under which the decision should be reconsidered.

The inclusion of “doing nothing” is important. A migration has costs and risks; retaining a monolith may be rational when it is stable, well understood, and not constraining strategic objectives. Architecture is not a competition in which the newest pattern always wins.

1.1 From technology adoption to outcome management

Digital transformation should be expressed through outcomes such as:

• reducing the time required to launch a product feature;
• improving availability of a critical customer service;
• reducing manual operational work;
• enabling a new digital revenue stream;
• meeting data-residency or audit requirements; or
• improving customer experience and accessibility.

A technology output is not automatically a business outcome. For example, “migrated 80% of servers to cloud” is an output. “Reduced approved service-recovery time from eight hours to one hour while maintaining compliance” is an outcome. The former may support the latter, but it does not prove it.

A transformation hypothesis can make this relationship explicit:

If the organisation introduces independently deployable services, automated delivery, and a governed platform, then product teams will release changes more frequently and safely, leading to improved customer responsiveness and reduced operational delay.

The hypothesis should be tested through measurable indicators rather than accepted as an article of faith.

2. Assessing Workloads and Selecting an Architectural Style

No single architecture is optimal for every workload. Assessment should begin with the workload’s behaviour and constraints, not with a preferred vendor or fashionable pattern.

2.1 Important workload dimensions

2.2 Comparative architectural options

A monolith deploys a large set of capabilities as one unit. It may be internally modular or internally tangled. Its advantages include simple deployment, local calls, straightforward transactions, and relatively simple testing. Its disadvantages include large release scope, scaling of the whole application, and the risk that changes in one area affect unrelated areas.

A modular monolith preserves a single deployable unit while enforcing strong internal boundaries. This is often an excellent transitional or permanent architecture. It permits domain separation without immediately introducing network calls, distributed data, and multiple operational pipelines.

Microservices organise an application as independently deployable services aligned with business capabilities. They can improve team autonomy and selective scaling, but introduce network failure, observability complexity, data consistency challenges, platform requirements, and a larger security surface.

Serverless usually refers to managed execution and infrastructure services in which the provider operates the underlying servers and capacity management. Functions-as-a-service, managed queues, event buses, object storage, and serverless databases can reduce infrastructure administration. However, developers remain responsible for application design, identity, configuration, cost control, resilience, and provider-specific constraints.

A hybrid architecture combines these styles. For example, a modular core may handle complex transactions while serverless functions process asynchronous notifications and image transformations.

2.3 A practical decision framework

A decision workshop should score alternatives against explicitly weighted criteria. Let s_i be the score of option i for criterion j, and w_j be the weight of criterion j. If scores are normalised to a common scale, the weighted score is:

The assumptions are that the criteria are sufficiently independent for the intended comparison, weights are non-negative, and all options are scored on the same scale. The score is a decision aid, not an objective truth. Sensitivity analysis should be performed by changing important weights or scores.

For example, suppose three options are assessed on speed, operational simplicity, and strategic flexibility. The weights are 0.30, 0.30, and 0.40. A serverless option receives scores of 8, 6, and 9 on a ten-point scale:

The result is meaningful only if the scoring scale and evidence are documented. A low score on a critical safety criterion should not necessarily be offset by high scores elsewhere; some requirements are threshold constraints, not tradeable preferences.

Useful decision questions include:

1. Is the workload strategically differentiating or commodity?
2. Does the proposed architecture reduce a known constraint?
3. Can the organisation operate it reliably at the required scale?
4. What failure modes are introduced by distribution and managed services?
5. How reversible is the decision?
6. What is the smallest experiment that can reduce uncertainty?

3. Decomposing a Monolith

Monolith decomposition is not simply splitting source files or placing existing functions behind HTTP endpoints. It is the separation of business capabilities, data ownership, deployment responsibility, and operational accountability.

3.1 Discovering boundaries

Domain-driven design provides useful concepts. A bounded context is a boundary within which a domain model and vocabulary have consistent meaning. A business capability is something the organisation must be able to do, such as pricing, fulfilment, claims processing, or identity management. A value stream describes the sequence of activities that produces value for a customer or stakeholder.

Boundary discovery should combine:

• business capability mapping;
• source-code dependency analysis;
• database table and query analysis;
• change-history analysis;
• incident and performance data;
• interviews with domain experts and operators; and
• identification of team ownership and regulatory boundaries.

A candidate service should have a coherent purpose, a manageable interface, clear data ownership, and a reason to change or scale independently. “One service per database table” is usually a poor rule because tables are storage structures, not necessarily business boundaries.

3.2 Decomposition patterns

The strangler pattern places a new capability around or in front of an existing system. Traffic is progressively redirected to the new component until the old path can be retired. This reduces the need for a risky single cutover.

A branch by abstraction introduces an abstraction layer inside the monolith. Existing and replacement implementations can coexist while callers are migrated gradually.

Event interception publishes events when important changes occur in the legacy system. New consumers can be developed without immediately moving the entire transaction path, although event correctness and duplication handling must be designed carefully.

Parallel run operates old and new implementations together and compares results. It is valuable for calculations such as pricing or eligibility, but requires clear treatment of discrepancies and side effects.

3.3 Data migration and consistency

Data is usually the hardest part of decomposition. A service should ideally own the data it changes. Other services consume information through APIs or events rather than directly updating its tables.

Distributed systems often cannot preserve a single ACID transaction across independent services. A saga coordinates a sequence of local transactions. If a later step fails, compensating actions attempt to restore an acceptable business state. A compensation is not always a perfect undo: a notification cannot be unread, and a payment reversal may require a separate transaction.

Event-driven designs must address:

• duplicate delivery and idempotent consumers;
• ordering and late events;
• schema evolution and compatibility;
• retries and poison messages;
• dead-letter handling;
• observability across correlation identifiers; and
• reconciliation between systems.

3.4 Migration sequence

A defensible decomposition roadmap normally proceeds as follows:

1. Establish baseline measures for reliability, delivery performance, cost, and user experience.
2. Map domains, dependencies, data ownership, and critical business processes.
3. Select a pilot boundary with meaningful value and manageable risk.
4. Create automated tests and observability around the existing behaviour.
5. Introduce an abstraction or routing seam.
6. Build the replacement capability with contract tests and independent deployment.
7. Migrate data and traffic incrementally.
8. Run operational rehearsals and compare outcomes.
9. Remove obsolete code, routes, credentials, and infrastructure.
10. Review the decision and update the roadmap based on evidence.

The final step is essential. Migration programmes often accumulate transitional components, creating a “distributed monolith” in which services are technically separate but must be released together.

4. Cloud Migration Planning

Cloud migration should be treated as a portfolio of workload decisions. Common migration approaches include:

• Retain: keep the workload where it is because migration value is low or constraints are unresolved.
• Retire: remove obsolete capability.
• Rehost: move with minimal application change.
• Replatform: adopt managed services with limited redesign.
• Refactor: substantially redesign the application.
• Repurchase: replace the system with a software service.
• Relocate: move a virtualised environment with minimal change.

These categories are not maturity levels. A regulated legacy system may appropriately be rehosted first, while a customer-facing service may be refactored to remove a strategic bottleneck.

A migration business case should include:

• discovery and engineering effort;
• data transfer and transformation;
• dual-running costs;
• training and recruitment;
• platform and observability costs;
• security and compliance work;
• expected operational savings or revenue benefits; and
• decommissioning and exit costs.

Cloud economics require attention to both fixed and variable costs. A simple total-cost model is:

Here, TCO is total cost over the selected period; C_migration is one-time migration cost; C_fixed is committed platform and licence cost; C_variable depends on usage; C_operations includes people, support, monitoring, and security; and C_exit represents planned transition or portability cost. The time horizon and cost scope must be stated. Comparing a one-year cloud bill with a ten-year on-premises capital investment is misleading.

Migration waves should be organised around business risk and dependencies rather than infrastructure convenience alone. Each wave needs entry criteria, acceptance criteria, rollback conditions, security approval, data validation, and an owner accountable for benefits.

5. Technical Debt and Architectural Sustainability

Technical debt is the future cost created by choosing an expedient approach instead of a more sustainable one. Debt is not identical to bad code. A deliberate shortcut can be rational if its repayment conditions are explicit. Undocumented or unmanaged debt is dangerous because interest accumulates through slower delivery, incidents, duplicated work, and reduced adaptability.

Examples include:

• unsupported runtime versions;
• duplicated business rules;
• inadequate automated tests;
• tightly coupled modules;
• undocumented interfaces;
• insecure defaults and unrotated credentials;
• manual deployment procedures;
• obsolete data stores; and
• excessive dependence on a provider-specific feature without an exit assessment.

A useful debt register records the item, affected capability, risk, evidence, owner, remediation estimate, and review date. Prioritisation should consider impact, probability, urgency, and effort. Security and regulatory debt may be treated as non-negotiable remediation rather than ranked purely by financial return.

A team can monitor indicators such as change failure rate, recovery time, build duration, dependency age, vulnerability exposure, and percentage of services with tested recovery procedures. These indicators are signals, not complete measures of architecture quality.

6. Platform Teams and the Operating Model

Microservices and serverless architectures shift responsibility toward product teams. Without common capabilities, every team may independently solve identity, logging, deployment, secrets, networking, cost monitoring, and compliance. This produces duplication and inconsistent controls.

A platform team provides an internal product that makes the safe path the easy path. Its users are developers and operational teams. Platform products may include:

• service templates and golden paths;
• identity and access integration;
• deployment pipelines;
• policy-as-code controls;
• observability and alerting;
• secure secrets management;
• approved data and messaging services;
• environment provisioning; and
• cost and service-ownership dashboards.

The platform should be treated as a product with a roadmap, user research, documentation, service-level objectives, and feedback channels. It should provide capabilities rather than impose unnecessary central control. A platform that becomes a mandatory ticket queue recreates the bottleneck it was intended to remove.

Responsibilities must be explicit. Product teams generally own application code, service configuration, business correctness, and on-call response. The platform team owns the reliability and usability of platform capabilities. Security, risk, and architecture functions define guardrails and assurance requirements. Ultimate accountability remains with organisational leadership.

7. Vendor Selection and Cloud Governance

Vendor selection should evaluate strategic fit, not only feature lists. A compact weighted model can assess:

Price requires careful interpretation. Consumption pricing may be attractive for irregular traffic but expensive for constant high utilisation. Egress charges, support plans, managed database costs, observability charges, and cross-region traffic can be material. A proof of concept should measure realistic workload behaviour rather than a small artificial test.

Avoiding lock-in is not always the correct objective. A managed service may provide substantial value through reliability and reduced operations. The relevant question is whether the dependency is understood, governed, and proportionate. Exit planning should identify export procedures, replacement options, data conversion, skills, contractual notice periods, and a tested minimum viable recovery path.

8. Business Continuity, Resilience, and Recovery

Business continuity begins with a business impact analysis. It identifies critical processes, dependencies, tolerable disruption, data-loss tolerance, and recovery priorities.

The recovery time objective (RTO) is the targeted maximum time to restore a service after disruption. The recovery point objective (RPO) is the targeted maximum tolerable period of data loss measured in time. For example, an RPO of 15 minutes means that, under the recovery design, the organisation aims to lose no more than approximately 15 minutes of committed data in the specified failure scenario.

A continuity strategy may include backups, replication, multi-zone deployment, multi-region deployment, queue buffering, graceful degradation, manual workarounds, and alternative suppliers. More redundancy increases complexity and cost; it does not eliminate all failure modes.

Recovery capability must be tested. A backup that has never been restored is an assumption, not evidence. Exercises should include corrupted data, expired credentials, provider outage, unavailable personnel, dependency failure, and communication breakdown. Serverless systems require particular attention to event backlogs, concurrency limits, retry storms, provider quotas, and hidden dependencies such as identity or DNS services.

9. Organisational Change and Governance

Architecture transformation changes authority and work practices. Teams may move from project hand-offs to product ownership, from manual release approval to automated policy checks, and from infrastructure administration to platform consumption. These changes can create anxiety, role ambiguity, and resistance.

Effective change management includes:

• a clear case for change linked to customer and organisational outcomes;
• executive sponsorship with visible commitment;
• involvement of practitioners in design decisions;
• training and protected learning time;
• revised performance measures that reward collaboration and reliability;
• incremental delivery that demonstrates value; and
• mechanisms for raising concerns without retaliation.

Governance should be proportional to risk. Architecture review boards can provide consistency, but central approval of every implementation detail creates delay. Lightweight ADRs, automated controls, reference architectures, and risk-based exceptions are often more effective than extensive documents.

Ethical and regulatory considerations include privacy by design, least-privilege access, explainability of automated decisions, accessibility, records retention, data sovereignty, environmental impact, and fair treatment of staff affected by automation. AI-assisted coding and operations can improve productivity, but generated code requires review, testing, licence scrutiny, secure handling of prompts and data, and accountability for outcomes.

10. Measuring Transformation Outcomes

A balanced measurement system should include leading indicators, operational indicators, and business outcomes.

The commonly used delivery metric change failure rate can be defined as:

where F is the number of deployments causing a production failure, rollback, or urgent remediation in the measurement period, and D is the total number of deployments. The organisation must define “failure” consistently; otherwise comparisons are unreliable. A higher deployment frequency can increase the denominator without improving reliability, so CFR should be read alongside recovery time and customer-impact measures.

A transformation dashboard should show trends, confidence, and interpretation. Metrics must not become targets that encourage harmful behaviour. For example, pressuring teams to increase deployment count may produce trivial releases or unsafe changes. Measurement should support learning and decision-making, not surveillance.

Applied Case: Illustrative RetailCo Transformation

Background

RetailCo operates a ten-year-old online ordering monolith. It processes orders, payments, stock reservations, promotions, and customer notifications in one deployment. Traffic is highly seasonal. Releases occur every three weeks, and a failed release can affect checkout for several hours.

Problem

The organisation proposes rewriting the entire platform as microservices on a serverless cloud architecture. Finance expects lower infrastructure cost, while engineering expects faster releases. However, the current system contains undocumented business rules and shares a relational database across all functions.

Analysis

The architecture group rejects an immediate rewrite because it would combine business uncertainty, data migration, and operational change in one high-risk programme. Baseline measurements show a median release lead time of 18 days, a change failure rate of 14%, and an average critical-service recovery time of 210 minutes. Seasonal load is five times normal demand, but payment and stock reservation require strong consistency and careful reconciliation.

A capability map identifies notifications and image processing as relatively independent, while stock reservation and payment are tightly coupled to business transactions. A weighted decision assessment favours a modular monolith for the transactional core and event-driven serverless components for notifications and image processing.

Approach and solution

RetailCo first introduces automated contract tests, centralised tracing, and an ownership catalogue. It creates an order-events interface using an outbox mechanism so that committed order changes can be published reliably. A notification service consumes the events idempotently. Image processing is moved to an asynchronous function pipeline with a dead-letter queue and cost limits.

The team then creates an internal platform providing deployment templates, identity integration, logging, dashboards, and policy checks. The payment and stock modules remain within a modular monolith while their interfaces and data ownership are clarified. A later experiment evaluates whether stock reservation can be separated without compromising consistency.

Migration waves include rollback plans and rehearsals. Success criteria include reducing critical-service recovery time below 60 minutes, reducing failed changes below 8%, maintaining checkout correctness during peak demand, and demonstrating restoration from backup.

Outcome

After two seasonal cycles, deployment lead time falls to six days and the measured change failure rate falls to 7%. Notification scaling becomes independent of checkout traffic, while image processing cost is controlled through concurrency limits. Infrastructure cost does not immediately fall; observability and platform investment initially increase expenditure. However, the organisation gains faster delivery and better resilience, and it avoids a high-risk rewrite.

Learning points

1. Decomposition should follow capability and change boundaries, not technology fashion.
2. A modular monolith can be a strategic architecture rather than a failed microservices attempt.
3. Baselines and explicit success criteria make transformation assessable.
4. Platform engineering is necessary when many teams must operate distributed workloads safely.
5. Cost, resilience, delivery speed, and business correctness must be evaluated together.

Challenges and Limitations

Architecture frameworks simplify reality. Weighted scoring can create false precision, especially when evidence is weak. Domain boundaries evolve as the business changes. Serverless pricing and provider limits may change, and managed services can conceal rather than remove operational dependencies. Microservices may increase organisational coordination costs when teams are too small or ownership is unclear.

Migration programmes can also suffer from optimism bias. Leaders may underestimate data quality problems, training requirements, dual-running costs, and the effort needed to retire old systems. Transformation metrics can be gamed or interpreted without context. Finally, resilience is relative to defined failure scenarios: multi-region deployment does not protect against a faulty global configuration, compromised credentials, or a flawed business rule replicated everywhere.

Best-Practice Checklist

• Begin with measurable business and user outcomes.
• Record significant decisions and their assumptions in ADRs.
• Treat regulatory and security requirements as constraints where appropriate.
• Prefer incremental migration with reversible steps.
• Establish service ownership, observability, and recovery testing early.
• Use modular monoliths when distribution does not yet create value.
• Give teams a platform product, not merely a collection of tools.
• Model total cost, including operations, data transfer, support, and exit.
• Test vendor claims with realistic experiments and references.
• Measure benefits over time and revise decisions when evidence changes.

Chapter Summary

Architecture decision-making links technical design to strategic outcomes. Workloads should be assessed according to demand, latency, state, coupling, transactions, security, operational capability, economics, and rate of change. Monoliths, modular monoliths, microservices, serverless, and hybrid systems each have legitimate uses; none is universally superior.

Successful decomposition identifies business capabilities and bounded contexts, establishes data ownership, and proceeds incrementally through patterns such as strangler migration, branch by abstraction, and event interception. Cloud migration requires portfolio-level choices, explicit cost models, dependency analysis, security controls, and measurable acceptance criteria. Technical debt must be made visible, assigned, prioritised, and repaid according to risk.

Platform teams can provide reusable, governed capabilities while preserving product-team autonomy. Vendor selection must consider reliability, compliance, skills, economics, portability, support, and exit options. Business continuity depends on defined RTO and RPO targets, tested recovery procedures, and understanding of hidden dependencies. Organisational change, ethical governance, and measurement are as important as technology.

The central principle is disciplined adaptation: select the simplest architecture that satisfies current strategic and operational needs, learn through evidence, and retain the ability to change direction.

Key Terms

Architecture decision record: A concise record of context, alternatives, decision, consequences, and review conditions.

Bounded context: A domain boundary within which concepts and terminology have consistent meaning.

Business capability: An organisational ability that creates value or supports operations.

Change failure rate: The percentage of deployments that cause failure, rollback, or urgent remediation.

Cloud migration: The movement, replacement, or redesign of workloads using cloud services.

Distributed monolith: Technically separate services that remain tightly coupled and must change or deploy together.

Event-driven architecture: An architecture in which components communicate through events representing significant occurrences.

Internal developer platform: A product offering reusable tools, services, workflows, and guardrails to development teams.

Monolith: An application delivered as one deployable unit, whether internally modular or tightly coupled.

Modular monolith: A single deployable application with enforced internal business and technical boundaries.

Platform team: A team that provides and operates shared capabilities for product and engineering teams.

Recovery point objective: The maximum targeted period of data loss following a defined disruption.

Recovery time objective: The maximum targeted time to restore a service following a defined disruption.

Saga: A sequence of local transactions coordinated with compensating actions for failure handling.

Serverless computing: Use of managed execution or infrastructure services where the provider operates underlying capacity.

Strangler pattern: Incremental replacement of legacy capability by routing selected functionality to new components.

Technical debt: Future cost or risk created by expedient technical decisions.

Total cost of ownership: The complete cost of an option over a defined period and scope.

Value stream: A sequence of activities that produces value for a customer or stakeholder.

Weighted decision model: A structured comparison that combines criterion weights and option scores.

Review Questions

Short Answer Questions

1. What information should be included in an architecture decision record?
2. Distinguish a monolith from a modular monolith.
3. Define recovery time objective and recovery point objective.
4. Why is data ownership important in microservice decomposition?
5. What is the purpose of an internal developer platform?

Long Answer Questions

1. Compare monolithic, modular monolithic, microservice, and serverless architectures for an online retail workload.
2. Explain how the strangler pattern can reduce the risk of monolith decomposition.
3. Discuss the technical, financial, and organisational factors in a cloud migration business case.
4. Explain how vendor lock-in can be governed without rejecting all provider-specific services.
5. Evaluate the role of measurement in digital transformation, including the risks of poorly designed metrics.

Analytical / Application Questions

1. An organisation has a stable transactional monolith, infrequent releases, and no significant scaling problem, but executives want microservices. Construct a decision analysis identifying evidence that would justify retaining, modularising, or decomposing the system.
2. Design a three-wave migration plan for a claims-processing system in which notifications, document processing, and claim settlement currently share one database. Identify risks, data strategies, rollback conditions, and success measures.
3. A cloud vendor offers a low execution price but charges substantial data-egress fees and provides limited export tooling. Develop a weighted vendor assessment and an exit strategy, explaining which criteria should be treated as threshold constraints.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the purpose of an architecture decision record?

A. To document only the final implementation code

B. To record context, alternatives, decision, consequences, and review conditions

C. To replace all operational documentation

D. To guarantee that an architecture decision will never change

Correct Answer: B. To record context, alternatives, decision, consequences, and review conditions

Question 2

Which workload characteristic most strongly supports event-driven serverless processing?

A. A requirement for one tightly coupled ACID transaction across all operations

B. A stable workload with no variation in demand

C. Asynchronous, independently scalable processing such as image transformation

D. A requirement to access every table in a shared database directly

Correct Answer: C. Asynchronous, independently scalable processing such as image transformation

Question 3

What is a principal risk of decomposing a monolith by database table alone?

A. Tables always provide valid business boundaries

B. The resulting services may lack coherent business responsibility and remain tightly coupled

C. It necessarily eliminates all data duplication

D. It prevents the use of automated testing

Correct Answer: B. The resulting services may lack coherent business responsibility and remain tightly coupled

Question 4

A decision model uses weights 0.3, 0.3, and 0.4 and scores 8, 6, and 9. What is the weighted score?

A. 6.8

B. 7.0

C. 7.8

D. 8.4

Correct Answer: C. 7.8

Question 5

What does an RPO of 15 minutes indicate?

A. The service must be restored within 15 minutes

B. The system should aim to lose no more than approximately 15 minutes of data in the defined scenario

C. The system must remain available for 15 minutes after failure

D. The backup must be retained for exactly 15 minutes

Correct Answer: B. The system should aim to lose no more than approximately 15 minutes of data in the defined scenario

Question 6

Which activity is most characteristic of a platform team?

A. Owning every product team’s business roadmap

B. Providing reusable deployment, identity, observability, and policy capabilities

C. Approving every line of application code manually

D. Removing product teams’ responsibility for their services

Correct Answer: B. Providing reusable deployment, identity, observability, and policy capabilities

Question 7

Which migration approach involves moving a workload with minimal application change?

A. Retire

B. Refactor

C. Rehost

D. Repurchase

Correct Answer: C. Rehost

Question 8

Why should a backup restoration be tested?

A. Because backup existence alone proves recovery capability

B. Because an untested backup is only an assumption of recoverability

C. Because testing eliminates the need for backups

D. Because restoration tests measure deployment frequency

Correct Answer: B. Because an untested backup is only an assumption of recoverability

Question 9

If 5 of 100 deployments cause a production failure or rollback, what is the change failure rate?

A. 0.5%

B. 5%

C. 20%

D. 95%

Correct Answer: B. 5%

Question 10

Which is the strongest reason to use a modular monolith as an intermediate architecture?

A. It guarantees zero technical debt

B. It establishes internal boundaries without immediately introducing distributed-system complexity

C. It requires every module to use a separate cloud provider

D. It prevents future decomposition permanently

Correct Answer: B. It establishes internal boundaries without immediately introducing distributed-system complexity