Cloud Platforms and Solution Architecture

Introduction and Context

Cloud computing has evolved from a collection of remotely hosted infrastructure services into a broad ecosystem of programmable platforms, managed services, development tools, governance mechanisms, and industry-specific capabilities. Contemporary enterprise architecture therefore involves more than selecting virtual machines or storage. Architects must evaluate provider ecosystems, compose services through APIs, manage identity and data movement, satisfy regulatory obligations, and preserve sufficient portability to avoid unacceptable dependence on one supplier.

The principal public-cloud ecosystems—Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and specialist or regional providers—offer broadly similar infrastructure categories but differ in service maturity, operational models, pricing structures, geographic reach, data services, developer experience, and integration with existing enterprise technologies. A sound architecture is not necessarily multi-cloud. It is fit for purpose: its technology choices are justified by business requirements, risk tolerance, skills, financial constraints, and expected change.

This chapter examines how to evaluate cloud platforms and design interoperable solutions using APIs, managed services, architectural principles, and portability strategies. It also considers the tension between using high-value proprietary services and limiting vendor lock-in.

Learning Objectives

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

1. Compare major cloud-provider ecosystems using technical, economic, operational, and governance criteria.

2. Explain how APIs, identity services, networking, data services, containers, and event systems support cloud solution architecture.

3. Apply Well-Architected principles to evaluate reliability, security, performance, cost, operational excellence, and sustainability.

4. Distinguish infrastructure, platform, and higher-level managed services in terms of control and portability.

5. Design an interoperable architecture and identify sources of vendor lock-in.

6. Recommend a proportionate portability, governance, and migration strategy for an enterprise scenario.

1. Cloud Platforms as Ecosystems

A cloud provider is best understood as an ecosystem rather than a catalogue of isolated products. The ecosystem normally includes:

• Compute: virtual machines, autoscaling groups, containers, Kubernetes services, serverless functions, and specialized hardware.
• Storage: object, block, file, archival, and database storage.
• Networking: virtual networks, load balancers, private connectivity, DNS, content delivery, and network security controls.
• Data platforms: relational and non-relational databases, data warehouses, data lakes, stream processing, and analytics.
• Integration: message queues, publish-subscribe systems, event buses, API gateways, and workflow engines.
• Security and governance: identity and access management, key management, security posture management, audit logging, policy engines, and compliance tooling.
• Operations: monitoring, logging, tracing, configuration management, deployment automation, and incident-management integrations.
• Specialized capabilities: artificial intelligence, machine learning, Internet of Things, digital twins, geographic information systems, and industry services.

The value of an ecosystem arises from integration. A managed database can use the provider’s identity system, monitoring, backup, networking, and key-management services with relatively little operational effort. The same integration, however, can create switching costs if application logic depends on provider-specific APIs or data formats.

1.1 Major Provider Profiles

AWS has a broad service portfolio, a mature infrastructure marketplace, extensive global coverage, and strong adoption among technology companies and enterprises. Its services often expose detailed configuration choices. This breadth supports sophisticated architectures but can increase design complexity and the need for specialized skills.

Microsoft Azure is strongly integrated with Microsoft identity, productivity, developer, and enterprise-management technologies. Organizations using Microsoft Entra ID, Windows Server, SQL Server, .NET, or Microsoft 365 may obtain substantial integration and migration benefits. Azure also provides extensive open-source, Linux, container, data, and AI capabilities.

Google Cloud is particularly associated with large-scale data processing, analytics, Kubernetes, cloud-native development, and machine learning. Its heritage in internet-scale systems influences its managed data and container services. Organizations should nevertheless evaluate regional availability, enterprise integration, commercial terms, and operational skills for each workload.

Specialist and regional providers may offer advantages in sovereignty, local support, predictable pricing, bare-metal capability, or particular managed services. They can be appropriate where regulatory, latency, contractual, or workload-specific requirements outweigh the breadth of hyperscale ecosystems.

These profiles are tendencies, not universal rankings. Provider selection must be based on workload evidence rather than reputation alone.

1.2 A Provider-Evaluation Framework

A structured evaluation should score providers against weighted criteria. Typical criteria include:

1. Functional fit: required compute, database, messaging, analytics, AI, and integration features.

2. Non-functional fit: availability, latency, throughput, recovery objectives, scalability, and security.

3. Geographic and sovereignty fit: regions, zones, data-residency controls, and local regulatory compliance.

4. Operational fit: observability, automation, support, incident response, and staff capability.

5. Economic fit: consumption pricing, discounts, licensing, egress, support, migration, and exit costs.

6. Integration fit: identity, networks, enterprise applications, development tools, and existing contracts.

7. Portability and exit fit: standards support, export capability, replacement options, and data portability.

8. Strategic fit: provider roadmap, ecosystem stability, supplier risk, and organizational bargaining position.

A weighted decision model can be expressed as

S = Σ(wᵢ rᵢ)

where S is the total score, wᵢ is the normalized weight assigned to criterion i, and rᵢ is the normalized provider rating for that criterion. The weights should sum to 1, and the rating scale must be defined before evaluation. This model supports transparency; it does not eliminate judgement. A provider with a high average score may still fail a mandatory requirement such as a data-residency condition. Mandatory constraints should therefore be applied before weighted scoring.

2. Architectural Layers and Service Choices

Cloud architecture is commonly described as a stack of abstraction layers:

• Infrastructure as a Service (IaaS): virtual machines, disks, networks, and firewalls. The customer controls operating systems and much of the runtime but bears more operational responsibility.
• Platform as a Service (PaaS): managed application runtimes, databases, integration platforms, and analytics services. The provider operates more of the platform, while the customer manages application configuration and data.
• Containers and orchestration: applications are packaged with dependencies and deployed through container platforms. Containers improve consistency but do not make an application automatically portable; storage, networking, identity, and observability may remain provider-specific.
• Serverless and function platforms: execution is triggered by events or requests, with infrastructure allocation abstracted. These platforms can reduce operations but often impose provider-specific event models, runtimes, limits, and billing behavior.
• Software as a Service (SaaS): a complete application is consumed through interfaces and configuration. The customer has the least infrastructure control but may gain speed and standardized functionality.

The central design decision is not “managed versus unmanaged.” It is the allocation of responsibilities. A managed service is attractive when the provider can operate a capability more efficiently and reliably than the organization. It is less attractive when its proprietary behavior, data model, or pricing creates unacceptable strategic dependence.

2.1 Managed Services and the Shared-Responsibility Model

The provider is typically responsible for the security and operation of the underlying cloud infrastructure, while the customer remains responsible for identity configuration, data protection, application security, access policies, and correct service use. The boundary varies by service. For example, a virtual machine customer manages the guest operating system; a managed database customer may not manage database patching but still manages schemas, users, queries, and data classification.

Managed services can improve reliability and reduce undifferentiated operational work. They may also introduce service quotas, opaque implementation details, regional limitations, and difficult migration paths. Architecture reviews should explicitly record:

• which party owns each operational responsibility;
• what failure modes remain possible;
• how data is backed up and restored;
• how service limits are monitored;
• how the service can be replaced or exited.

3. APIs as the Fabric of Cloud Architecture

An API is a defined interface through which software requests data or operations. Cloud APIs are commonly exposed through REST over HTTPS, software development kits, command-line tools, infrastructure-as-code providers, event interfaces, and sometimes gRPC or other protocols. APIs enable automation, service composition, testing, and integration across organizational boundaries.

3.1 API Design Concerns

A production API should address:

• Resource and operation semantics: clear nouns, actions, state transitions, and HTTP methods where REST is used.
• Authentication and authorization: tokens, workload identities, scopes, roles, and least privilege.
• Idempotency: repeated submission of an operation should not create unintended duplicate effects. This is essential for retries in distributed systems.
• Versioning: changes should preserve compatibility or provide an explicit migration path.
• Rate limits and quotas: clients must handle throttling through bounded retries and backoff.
• Timeouts and failure handling: no distributed call should wait indefinitely.
• Observability: request identifiers, structured logs, metrics, and traces support diagnosis.
• Data contracts: schemas, validation, classification, and compatibility rules should be managed as products.

A useful architectural distinction is between provider APIs and domain APIs. Provider APIs create cloud resources and invoke platform capabilities. Domain APIs expose business capabilities such as placing an order or calculating a claim. Applications should avoid allowing provider-specific resource semantics to leak unnecessarily into domain contracts. An adapter or anti-corruption layer can translate between them.

3.2 Infrastructure as Code and Control-Plane Automation

Infrastructure as Code (IaC) represents infrastructure configuration in version-controlled, reviewable definitions. Declarative tools describe the desired state; the tool determines changes needed to reach it. IaC improves repeatability, enables automated testing, supports disaster recovery, and creates an audit trail. It does not guarantee portability: an IaC module using a proprietary database or identity feature remains dependent on that service.

Effective IaC practice includes separate environments, reusable modules, policy checks, secret separation, state protection, drift detection, and controlled deployment pipelines. Provider-native IaC tools may expose the newest capabilities quickly, whereas multi-provider abstractions may offer portability at the cost of delayed feature support or a lowest-common-denominator design.

4. Well-Architected Solution Design

Well-Architected frameworks provide a systematic way to review design decisions. Names and details vary among providers, but common pillars are:

Operational Excellence

The architecture should support reliable deployment, monitoring, incident response, learning, and continual improvement. Infrastructure and application changes should be automated where practical. Operational readiness includes runbooks, service-level indicators, escalation paths, and tested recovery procedures.

Security

Security requires strong identity, least privilege, segmentation, encryption, secure configuration, vulnerability management, threat detection, and auditable activity. Identity should be treated as a control plane: human access should be federated and strongly authenticated, while workloads should use short-lived identities rather than embedded long-lived credentials.

Reliability

Reliability is the ability to perform correctly and recover from disruption. Designs should anticipate hardware failure, zone failure, dependency failure, bad deployment, data corruption, and regional outage. Redundancy alone is insufficient: recovery must be tested, and dependencies must not create a hidden single point of failure.

Two important recovery objectives are:

• Recovery Time Objective (RTO): the maximum acceptable time to restore service after a disruptive event.
• Recovery Point Objective (RPO): the maximum acceptable amount of data loss measured in time.

A system requiring an RPO of five minutes needs a data-protection design capable of capturing or replicating changes within that bound; a nightly backup cannot satisfy it. RTO and RPO are business requirements translated into technical design, not merely infrastructure settings.

Performance Efficiency

Performance design considers latency, throughput, concurrency, capacity, caching, data locality, serialization, and scaling behavior. Benchmarking should use representative workloads. A low-latency compute service is not useful if a cross-region database call dominates the response time.

Cost Optimization

Cost optimization includes right-sizing, utilization, purchase commitments, autoscaling, storage lifecycle policies, architectural efficiency, and governance. Total cost must include data transfer, support, licenses, operational labor, migration, security tooling, and exit activities. Unit economics—such as cost per transaction or cost per analytical query—are more informative than an undifferentiated monthly bill.

Sustainability

Sustainable design seeks to reduce energy and material consumption while meeting requirements. Efficient architectures may use right-sized resources, managed autoscaling, efficient data retention, workload scheduling, and regions with suitable energy characteristics. Sustainability decisions must not compromise legal, resilience, or latency requirements without explicit trade-off analysis.

These pillars conflict at times. Multi-region replication can improve reliability while increasing cost, energy use, and data-governance complexity. A Well-Architected review therefore documents trade-offs rather than treating every pillar as an absolute maximum.

5. Interoperability and Portability

Interoperability is the ability of systems from different providers or organizational domains to exchange and use information. Portability is the ability to move an application, workload, or data between environments with acceptable effort and behavior. A system may be interoperable without being portable: it can exchange messages with another cloud but still depend deeply on a proprietary database.

Portability has several dimensions:

• Application portability: moving code and runtime behavior.
• Data portability: exporting, transforming, and importing data with acceptable fidelity and downtime.
• Operational portability: reproducing monitoring, deployment, identity, backup, and incident processes.
• Skills portability: availability of people who can operate the design elsewhere.
• Contractual portability: legal rights to export data, terminate services, and obtain assistance.

Open standards can help, including HTTP, TLS, SQL, OpenAPI, OCI container images, Kubernetes APIs, and common observability formats. Standards do not guarantee equivalence. Kubernetes, for example, standardizes many orchestration concepts but does not standardize every storage class, identity integration, network policy, or managed add-on.

5.1 Portability Strategies

1. Avoidance: choose standardized services and limit proprietary features. This maximizes potential portability but may sacrifice productivity or capability.

2. Abstraction: isolate provider-specific functionality behind interfaces, adapters, or service layers. This preserves substitution options but introduces code and operational overhead.

3. Replication: implement comparable deployments in more than one provider. This can improve resilience and bargaining power but substantially increases testing and operational complexity.

4. Exit preparation: maintain export procedures, data dictionaries, infrastructure definitions, recovery documentation, and periodically tested migration plans.

5. Selective adoption: use proprietary managed services where their value is high, while isolating them from the core domain and maintaining a realistic exit assessment.

A practical principle is to optimize for portability of critical business capability, not identical portability of every component. A temporary analytics workload may reasonably use a provider-native warehouse, while a regulated customer master may require stronger exit controls.

6. Vendor Lock-In: Analysis and Management

Vendor lock-in occurs when switching provider, service, or architecture is sufficiently costly, risky, or slow that the customer loses meaningful choice. Lock-in is not automatically undesirable. Specialization can create superior performance, security, or development speed. The relevant question is whether the benefits exceed the strategic and operational costs.

Sources of lock-in include:

• proprietary databases and data models;
• provider-specific event schemas and workflow semantics;
• tightly coupled identity and authorization policies;
• unique AI models, vector indexes, or hardware accelerators;
• large data volumes and egress charges;
• specialized operational knowledge;
• contractual discounts and licensing arrangements;
• compliance approvals that are difficult to reproduce elsewhere.

A lock-in assessment should examine switching time, migration cost, data transformation, service equivalence, downtime, retraining, legal constraints, and failure during transition. It should distinguish technical lock-in from economic, organizational, and contractual lock-in.

Countermeasures include open data formats, documented APIs, domain-driven boundaries, automated testing, containerized application components, independent backups, dual-skilled teams, contract negotiation, and periodic exit exercises. However, running active-active systems across multiple clouds is not a universal solution. It may introduce inconsistent semantics, higher latency, duplicated security controls, difficult data consistency problems, and substantially greater cost.

7. A Reference Architecture for an Enterprise Application

Consider a customer-facing order platform with web and mobile clients. A fit-for-purpose architecture may include:

• a content delivery network and web application protection;
• stateless application services deployed on managed containers or a platform runtime;
• an API gateway enforcing authentication, quotas, and routing;
• a relational database for transactional order data;
• an object store for documents and media;
• a durable message or event service for asynchronous fulfillment;
• a separate analytics store populated through controlled data pipelines;
• centralized identity, secrets, key management, logs, metrics, and traces;
• IaC and continuous delivery pipelines;
• backups, cross-zone resilience, and documented regional recovery.

The core business API should use domain terms rather than exposing database tables or provider-specific resource identifiers. Provider adapters can translate payment, messaging, and storage operations. Data ownership should be explicit: the order service owns order state, while analytics consumes governed events rather than querying production tables indiscriminately.

The design should define consistency expectations. An order may require strong transactional consistency within the order database, while fulfillment notifications can be eventually consistent through a durable event. This separation avoids imposing expensive synchronous dependencies on every downstream service.

8. Illustrative Case: Northstar Insurance Claims Platform

Background

Northstar Insurance, a fictional regional insurer, operates a claims platform in a private data centre. It experiences seasonal demand peaks, slow release cycles, and increasing requirements for mobile access, fraud analytics, and auditable data handling. The company is considering a hyperscale cloud migration but is concerned about regulatory sovereignty and dependence on proprietary services.

Problem

The existing platform contains a relational claims database, document storage, batch analytics, and several tightly coupled applications. The target architecture must achieve an RTO of four hours and an RPO of fifteen minutes for claims processing. Personally identifiable information must remain in approved jurisdictions. The organization has strong SQL and .NET skills but limited Kubernetes expertise.

Analysis

A full rewrite would create unacceptable delivery and operational risk. A direct virtual-machine migration would preserve dependencies and fail to exploit managed operations. A multi-cloud active-active design would exceed current skills and complicate consistency, identity, and compliance. The most proportionate strategy is a staged modernization with a primary provider and a documented exit capability.

The evaluation weights regulatory fit, Microsoft integration, database compatibility, recovery capability, operational skills, cost, and portability. Azure is selected as the initial platform because of existing identity and .NET integration, but the decision is recorded as conditional and subject to periodic review. This is not a claim that Azure is universally superior; it is a fit-for-purpose decision for the stated constraints.

Approach and Solution

Northstar first establishes a landing zone with separate accounts or subscriptions, centralized identity, policy enforcement, network segmentation, logging, key management, and budget controls. The existing application is initially moved to managed virtual machines to reduce migration risk. Database backups are encrypted, independently retained, and tested through restoration exercises.

In the second stage, document storage moves to object storage through an abstraction service that exposes Northstar’s own document API. The application is decomposed gradually: claims notifications are published to a durable event interface, and analytics consumes masked or tokenized data in a separate environment. The domain API uses OpenAPI contracts and does not expose provider resource identifiers.

The team uses IaC modules, automated security tests, deployment approvals, and synthetic monitoring. It defines service-level indicators for claim submission latency, successful processing, event lag, and recovery success. A quarterly exit test exports claims data, schemas, document metadata, and configuration to a controlled secondary environment. The test need not operate the entire platform continuously; its purpose is to validate that critical business capability can be reconstructed within an agreed time.

Outcome

The staged approach reduces initial operational risk and improves release automation without demanding immediate organizational transformation. Managed services reduce patching and infrastructure effort, while adapters, independent backups, documented contracts, and tested exports reduce strategic dependence. Some lock-in remains in identity, monitoring, and database features; management accepts it because the business value is documented and the exit controls are funded.

Learning Points

1. Provider selection is contextual rather than ideological.

2. Portability is a spectrum and must be attached to critical business capabilities.

3. A migration plan should include operational readiness, not only resource deployment.

4. Independent restoration and exit tests provide stronger evidence than architecture diagrams.

5. A primary-cloud strategy can be responsible when risks are measured and managed.

9. Governance, Ethics, and Regulation

Cloud architecture creates governance responsibilities beyond technical efficiency. Data classification should determine storage location, retention, encryption, access, and deletion. Privacy principles such as purpose limitation, data minimization, accuracy, access control, and accountability should be designed into data pipelines. Sensitive data should not be copied into development, analytics, or AI environments without authorization and appropriate de-identification.

Organizations should maintain a responsibility matrix covering provider, platform team, application owner, data owner, security, and compliance functions. Contracts should address breach notification, audit rights, subcontractors, service availability, data return, deletion certification, portability assistance, and termination. Regulatory compliance is not transferred simply because infrastructure is operated by a provider; the customer remains accountable for lawful processing and appropriate controls.

AI services introduce additional issues: model and data provenance, confidentiality of prompts and training data, bias, explainability, human oversight, retention, and geographic processing. An AI API should be assessed like any other external dependency, with explicit rules about what data may be submitted and how outputs are validated. AI-generated infrastructure or code must also pass normal security, testing, and approval processes.

10. Contemporary Developments and Best Practices

Several developments are reshaping cloud architecture:

• Confidential computing seeks to protect data while it is being processed through hardware-backed isolated execution.
• Platform engineering creates internal developer platforms that provide approved paths for deployment, security, observability, and governance.
• FinOps combines engineering, finance, and business ownership to manage cloud value rather than merely reduce invoices.
• Distributed cloud and edge computing place selected capabilities closer to users, devices, or regulated locations.
• OpenTelemetry and policy as code improve cross-tool observability and automated governance.
• Sovereign-cloud initiatives address jurisdiction, operational control, and trusted personnel requirements.
• Generative AI services increase the importance of data governance, model evaluation, and provider-contract scrutiny.

Best practice is to begin with business capabilities and non-functional requirements, establish architectural guardrails, select the least operationally burdensome service that meets requirements, and record trade-offs. Automate provisioning and testing; use least privilege; design for failure; measure unit cost and service outcomes; maintain independent backups; and rehearse recovery and exit procedures. Review architecture continuously because provider offerings, regulations, workload patterns, and organizational skills change.

Chapter Summary

Cloud platforms are integrated ecosystems of compute, storage, networking, data, security, operations, and specialized services. Effective provider evaluation considers functional and non-functional requirements, geography, skills, economics, governance, integration, and exit capability rather than relying on market reputation.

APIs and infrastructure as code provide the programmable foundation of cloud architecture. Good API design addresses identity, authorization, idempotency, versioning, quotas, failure handling, observability, and data contracts. Managed services can improve reliability and reduce operational work, but they may create dependency through proprietary interfaces, data models, and pricing.

Well-Architected analysis examines operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. RTO and RPO translate business recovery requirements into technical controls. Interoperability and portability are related but distinct: systems may communicate across providers without being readily movable. Portability should be prioritized for critical business capabilities and supported through standards, abstraction, independent backups, documented contracts, and tested exit procedures.

Vendor lock-in is multidimensional and not inherently unacceptable. The professional decision is to make dependencies visible, quantify their value and switching risk, and govern them deliberately. A staged, fit-for-purpose architecture is often more responsible than either total provider dependence or an unnecessarily complex multi-cloud design.

Key Terms

API: A defined interface through which software requests data or operations.

Cloud ecosystem: The integrated set of services, tools, partners, skills, and governance capabilities surrounding a provider.

Managed service: A service operated substantially by the provider on behalf of the customer.

Infrastructure as Code: Version-controlled, machine-readable definition and automation of infrastructure configuration.

Interoperability: The ability of different systems to exchange and use information.

Portability: The ability to move a workload, application, or data between environments.

Vendor lock-in: Dependence that makes switching provider or service costly, risky, or slow.

RTO: Maximum acceptable time to restore service after disruption.

RPO: Maximum acceptable time-based amount of data loss after disruption.

Well-Architected framework: A structured method for reviewing cloud architecture against recognized design pillars.

Least privilege: Granting only the permissions required for an identity or process.

Idempotency: The property that repeating an operation does not create unintended additional effects.

API gateway: A managed entry point that can provide routing, authentication, quotas, and policy enforcement.

Landing zone: A governed foundational cloud environment containing identity, networking, policies, logging, and security controls.

IaC drift: Difference between the declared infrastructure state and the actual deployed state.

Eventual consistency: A model in which replicas or dependent systems become consistent after a delay.

FinOps: A cross-functional practice for managing cloud value, usage, and financial accountability.

Data sovereignty: Requirements concerning the jurisdiction and control under which data is stored or processed.

Anti-corruption layer: An adapter that prevents an external model from contaminating an internal domain model.

Unit economics: Cost or value measured per business unit, such as transaction or customer.

Review Questions

Short Answer Questions

1. What distinguishes interoperability from portability?

2. Identify four criteria for evaluating a cloud provider.

3. Why is idempotency important in cloud APIs?

4. Define RTO and RPO.

5. Name three common sources of vendor lock-in.

Long Answer Questions

1. Compare IaaS, PaaS, containers, serverless, and SaaS in terms of control, operational responsibility, and portability.

2. Explain how the Well-Architected pillars can conflict and how an architect should manage those trade-offs.

3. Discuss the benefits and risks of provider-managed databases.

4. Explain how infrastructure as code supports governance while potentially preserving provider dependence.

5. Develop a structured framework for selecting a primary cloud provider for a regulated enterprise.

Analytical / Application Questions

1. An organization requires an RPO of fifteen minutes but currently performs nightly backups. Diagnose the gap and recommend an appropriate protection and testing strategy.

2. Design a portability strategy for a high-value claims-processing capability that uses a proprietary database, event service, and identity platform.

3. Evaluate whether active-active deployment across two public clouds is justified for a transaction system. Identify the evidence, costs, consistency issues, and governance conditions that should inform the decision.

Multiple Choice Questions with Answers

Question 1

Which criterion should normally be treated as a mandatory constraint before applying a weighted provider score?

A. Aesthetic preference for the provider portal

B. Data-residency compliance

C. Number of conference presentations

D. Popularity among developers

Correct Answer: B. Data-residency compliance

Question 2

What is the primary purpose of an API gateway in the reference architecture?

A. Replacing all databases

B. Providing entry-point routing, authentication, and quota enforcement

C. Eliminating the need for identity management

D. Converting every application into a batch job

Correct Answer: B. Providing entry-point routing, authentication, and quota enforcement

Question 3

Which statement best describes portability?

A. The ability of systems to exchange messages

B. The ability to move an application or data between environments with acceptable effort

C. The ability to scale a service vertically

D. The ability to encrypt data at rest

Correct Answer: B. The ability to move an application or data between environments with acceptable effort

Question 4

An RPO of fifteen minutes primarily specifies:

A. The maximum acceptable restoration time

B. The maximum acceptable data loss measured in time

C. The maximum API response time

D. The maximum database transaction duration

Correct Answer: B. The maximum acceptable data loss measured in time

Question 5

Which practice most directly limits exposure of long-lived credentials?

A. Embedding passwords in application code

B. Using short-lived workload identities

C. Sharing one administrator account

D. Disabling audit logs

Correct Answer: B. Using short-lived workload identities

Question 6

Why does using containers not automatically guarantee multi-cloud portability?

A. Containers cannot run outside a data centre

B. Storage, identity, networking, and observability may remain provider-specific

C. Containers do not package application dependencies

D. Containers require proprietary hardware in every case

Correct Answer: B. Storage, identity, networking, and observability may remain provider-specific

Question 7

Which is an example of an anti-corruption layer?

A. An adapter translating a provider event format into a domain event

B. A public password shared by all services

C. A backup deleted after every deployment

D. A database with no schema

Correct Answer: A. An adapter translating a provider event format into a domain event

Question 8

What is a principal advantage of managed services?

A. They eliminate all customer security responsibilities

B. They reduce undifferentiated operational work

C. They guarantee zero vendor lock-in

D. They remove the need for recovery testing

Correct Answer: B. They reduce undifferentiated operational work

Question 9

Which practice provides the strongest evidence that an exit plan is usable?

A. Keeping an undated architectural aspiration

B. Periodically testing data export and reconstruction

C. Assuming another provider has identical services

D. Avoiding all managed services

Correct Answer: B. Periodically testing data export and reconstruction

Question 10

Which statement about multi-cloud active-active architecture is most accurate?

A. It is always cheaper than using one provider

B. It automatically solves data consistency problems

C. It can improve resilience but adds operational, consistency, and cost complexity

D. It removes the need for provider-specific skills

Correct Answer: C. It can improve resilience but adds operational, consistency, and cost complexity