Cloud and Hybrid Data Platforms

Introduction and Context

Cloud data platforms have transformed big data engineering from the procurement and operation of physical infrastructure into the design of elastic, programmable, and service-oriented systems. Instead of purchasing servers, storage arrays, and network equipment in advance, an organisation can provision managed object storage, distributed databases, stream-processing services, container platforms, and serverless functions on demand. This shift changes not only deployment mechanics but also architecture, economics, governance, security, and professional responsibility.

A cloud platform is not simply a remote data centre. It is an operating model that combines virtualised infrastructure, self-service provisioning, measured consumption, automation, geographical distribution, and provider-managed services. A hybrid platform combines resources operated by different parties or environments, commonly an enterprise data centre with one or more public clouds. A multicloud architecture uses services from two or more cloud providers, often to satisfy regulatory, resilience, capability, or commercial objectives.

For big data engineers, the central challenge is to select an appropriate balance among scalability, portability, resilience, performance, cost, sustainability, and operational control. These properties frequently conflict. A highly managed proprietary service may reduce operational effort but increase switching costs. A portable open-source stack may reduce lock-in but require more engineering and maintenance. A platform distributed across regions may improve availability but increase latency, data-transfer cost, and carbon impact.

Learning Objectives

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

1. Explain the architectural roles of managed storage, compute, serverless, and streaming services.
2. Design cloud, multicloud, and hybrid data platforms for realistic workload requirements.
3. Evaluate scalability, portability, resilience, vendor lock-in, sustainability, and shared responsibility.
4. Apply quantitative reasoning to capacity, availability, recovery, and cost decisions.
5. Recommend governance, security, and operating practices for cloud data engineering.
6. Critically assess contemporary developments such as lakehouse architectures, confidential computing, and AI-assisted operations.

1. Cloud Service Models and Data-Platform Architecture

Cloud services are commonly classified as infrastructure as a service, platform as a service, and software as a service. Infrastructure services expose virtual machines, networks, and block or object storage. Platform services provide higher-level runtime environments such as managed databases, data warehouses, stream processors, and container orchestration. Software services expose complete applications. Big data platforms frequently combine all three.

A useful architectural abstraction separates the platform into six planes:

The planes are logically distinct but operationally connected. For example, a batch transformation reads data from object storage, obtains credentials through an identity service, records lineage in a catalogue, and writes results to a warehouse. A sound design makes these dependencies explicit.

Managed Storage

Object storage is the foundation of many modern data platforms. It stores objects identified by keys within logical containers and is well suited to large files, immutable datasets, backups, logs, and analytical table formats. It offers high durability and elastic capacity, but it is not identical to a conventional POSIX file system. Operations such as renaming large collections, frequent small updates, and low-latency random writes may be inefficient.

Block storage presents virtual disks to compute instances and is appropriate for operating systems, transactional databases, and workloads requiring predictable I/O semantics. File storage provides shared hierarchical access and is useful when multiple compute nodes require a common file interface. Managed databases and warehouses abstract storage layout, indexing, replication, and query execution, but their data models and APIs can be provider-specific.

Data lakes normally use object storage as a low-cost, durable system of record. A lakehouse adds transaction management, schema enforcement, time travel, table optimisation, and warehouse-like query semantics. Open table formats can improve interoperability, although portability is not guaranteed merely because a format is open: catalogues, execution engines, security policies, and proprietary extensions may still create dependency.

Managed Compute

Compute choices include virtual machines, managed clusters, containers, serverless functions, serverless containers, and managed analytical engines. Virtual machines provide broad control and compatibility. Containers package applications consistently but still require orchestration, observability, and security management. Managed clusters are suitable for sustained distributed processing, whereas serverless services are attractive for intermittent, event-driven, or highly variable workloads.

The selection should reflect workload shape. A continuously active transformation with stable utilisation may be cheaper and more predictable on reserved or committed capacity. A workload that runs briefly after unpredictable events may benefit from serverless execution. Large analytical queries may be best served by a managed warehouse that separates storage and compute, allowing each to scale independently.

Serverless Data Engineering

Serverless does not mean that no servers exist. It means that the provider manages server provisioning and much of the runtime operation, while the customer specifies code, configuration, or queries. Benefits include rapid provisioning, automatic scaling, and reduced infrastructure administration. Limitations include startup latency, execution-duration limits, concurrency quotas, opaque scheduling, provider-specific event models, and potentially difficult cost forecasting.

A robust serverless design is idempotent: repeating an operation produces the same logical result as executing it once. This property is essential because retries are normal in distributed systems. Idempotency can be implemented through deterministic event identifiers, conditional writes, deduplication tables, or transactional merges.

Streaming Services

Streaming platforms accept ordered or partially ordered event records and make them available to consumers. Important concepts include topics or streams, partitions, offsets, consumer groups, retention, delivery semantics, watermarks, and event time. Partitioning determines parallelism and often affects ordering: records with the same partition key may preserve order within a partition, but global ordering is generally unavailable at scale.

At-most-once delivery may lose records but avoids duplicates. At-least-once delivery prevents silent loss under normal retry assumptions but may produce duplicates. Exactly-once processing is a constrained end-to-end property requiring coordination among the source, processing engine, state, and sink; it should not be claimed merely because a broker provides a transactional feature.

For out-of-order events, event-time processing uses windows and watermarks. A watermark is an estimate that events earlier than a particular timestamp are unlikely to arrive. Late-event policies must specify whether late records are discarded, sent to a side output, or used to revise previously computed results.

2. Scalability and Elasticity

Scalability describes how a system accommodates increased workload. Vertical scaling increases the resources of a node; horizontal scaling adds nodes or execution units. Big data systems generally favour horizontal scaling, but not all operations scale linearly. Network shuffles, metadata services, hot keys, serial dependencies, and small-file overhead can become bottlenecks.

A simple capacity estimate for storage is:

where C_total is required capacity, D_daily is daily logical data volume, R is the replication or retained-copy factor, T is the retention period in days, and O is fractional overhead for metadata, indexes, temporary data, and growth margin. The variables must use consistent units, such as tebibytes per day and tebibytes. This estimate assumes approximately stable daily volume and does not model compression unless D_daily is measured after compression.

For example, if a platform receives 4 TB per day, retains data for 90 days, maintains 1.2 effective copies, and reserves 15% overhead, then:

The result is a planning estimate, not a billing figure. Cloud charges may depend on stored bytes, operations, retrieval, replication, and data transfer.

Parallel speed-up can be described using Amdahl’s law:

where S(N) is speed-up using N workers, f is the fraction of execution that remains serial, and 1 − f is the parallel fraction. The model assumes fixed workload and ignores communication, scheduling, and resource contention. If f = 0.1 and N = 20, the idealised speed-up is approximately 7. Thus, adding resources cannot eliminate a serial bottleneck.

Elasticity should be evaluated against workload variability. Autoscaling policies need measurable signals, such as queue depth, lag, CPU utilisation, memory pressure, or processing time. Scaling too slowly causes backlogs; scaling too aggressively increases cost and may overload downstream systems.

3. Availability, Resilience, and Recovery

Availability is the proportion of time a service is usable according to a defined service-level objective. For a period with total time T_total and unavailable time T_down, availability is:

If a service has 99.9% monthly availability, the permitted unavailability in a 30-day month is approximately:

This calculation assumes a 30-day month and does not imply that every failure will last exactly that long.

For independent components arranged in series, where all components must operate, availability is approximately:

For independent redundant components arranged in parallel, where at least one must operate, availability is:

These formulas assume statistical independence, which is often unrealistic in cloud systems because a shared region, identity service, network, or software defect can cause correlated failure.

Resilience is broader than availability. It includes resistance to failure, recovery, graceful degradation, and adaptation. Disaster-recovery planning uses two central objectives:

• Recovery point objective (RPO): the maximum acceptable amount of data loss measured in time.
• Recovery time objective (RTO): the maximum acceptable time to restore service.

A platform with a 15-minute RPO needs replication, checkpointing, or backup practices that can recover to a point no more than approximately 15 minutes before failure. A 2-hour RTO requires tested procedures capable of restoring service within two hours. Backups that have never been restored are not reliable evidence of recoverability.

Common resilience patterns include multi-zone deployment, cross-region replication, immutable backups, queue-based buffering, circuit breakers, bulkheads, replayable event logs, and graceful degradation. Each introduces cost, operational complexity, or consistency trade-offs.

4. Hybrid and Multicloud Architecture

Hybrid architecture is justified when an organisation must retain sensitive workloads on premises, use specialised equipment, satisfy data-residency rules, integrate with existing systems, or maintain continuity during cloud disruption. Typical patterns include:

1. Cloud bursting: normal processing occurs on premises and excess demand is sent to cloud resources.
2. Data-lake extension: cloud object storage provides scalable analytical capacity while core transactional systems remain local.
3. Disaster recovery: cloud infrastructure is maintained as a recovery environment.
4. Distributed processing: data is processed near its source to reduce movement and latency.
5. Sovereign or regulated partitioning: selected datasets remain in a controlled jurisdiction or facility.

Multicloud can reduce dependence on one provider and provide access to specialised services. However, it often duplicates networking, identity, monitoring, skills, security controls, and operational processes. A multicloud strategy should therefore be driven by explicit requirements rather than by an assumption that more providers automatically produce resilience.

Portability exists at several layers:

Portability is not free. Maintaining abstractions may prevent use of valuable provider capabilities. The appropriate question is not whether a system is portable in the abstract, but which components must be replaceable, within what time, and at what cost.

5. Vendor Lock-In and Economic Evaluation

Vendor lock-in is the difficulty or cost of changing provider, service, architecture, or operating model. It may arise from proprietary APIs, data formats, identity models, workflow definitions, networking configurations, staff expertise, or accumulated operational knowledge. Lock-in is not always negative. A managed service may create productive specialisation and lower total cost of ownership. The concern is unmanaged or irreversible dependence.

A practical assessment should examine:

• Data-exit time and egress charges.
• Availability of export tools and open formats.
• Replacement services and migration complexity.
• Contractual termination and support conditions.
• Skills required in the destination environment.
• Compatibility of security, governance, and observability controls.
• Performance and feature loss after migration.

A total-cost model should include storage, compute, requests, data transfer, licences, support, engineering labour, migration, backup, compliance, and expected failure costs. A simplified annual cost model is:

This identity is a budgeting framework, not a universal billing formula. Each term must be defined for the provider’s pricing model. In particular, network cost may include ingress, egress, inter-region transfer, private connectivity, and replication.

FinOps practices connect engineering choices with financial accountability. Teams should allocate costs through tags, accounts, projects, or chargeback models; monitor unit economics such as cost per terabyte processed or cost per million events; and review idle resources, inefficient queries, excessive retention, and unnecessary cross-region transfer.

6. Shared Responsibility, Security, and Governance

The shared-responsibility model divides security obligations between provider and customer. The provider normally secures the physical facilities, hardware, and foundational service. The customer remains responsible for data classification, identity configuration, access policies, application logic, secrets, retention, and often operating-system or network controls, depending on the service model. Responsibility shifts upward as services become more managed, but it never disappears.

A secure data platform should implement:

• Least-privilege identity and short-lived credentials.
• Separation of duties for development, deployment, and production access.
• Encryption in transit and at rest, with controlled key management.
• Private connectivity and restricted service endpoints where appropriate.
• Centralised audit logging with tamper-resistant retention.
• Data classification, masking, tokenisation, and access monitoring.
• Automated policy checks in infrastructure-as-code pipelines.
• Tested incident response and recovery procedures.

Governance must cover the full data life cycle: collection, classification, storage, use, sharing, retention, archival, and deletion. Regulatory requirements may include privacy, financial reporting, health information, national sovereignty, and records management. De-identification is not automatically irreversible; combinations of quasi-identifiers may permit re-identification. Data minimisation and purpose limitation are therefore technical as well as legal concerns.

Data quality governance should assign ownership for schema, definitions, freshness, accuracy, completeness, and permitted use. A catalogue without accountable owners becomes a directory rather than a governance system. Lineage is especially important when analytical outputs influence credit, employment, health, or public-sector decisions.

7. Sustainability and Carbon-Aware Engineering

Cloud sustainability involves both provider efficiency and customer choices. Concentrated facilities can achieve high utilisation, but aggregate demand still has environmental consequences. Engineering decisions affect energy use through compute intensity, data movement, storage duration, replication, and idle capacity.

Useful practices include right-sizing, autoscaling, efficient file formats, compaction, partition pruning, workload scheduling, lifecycle policies, deletion of redundant data, and regional placement informed by energy characteristics. Sustainability must not be reduced to selecting a supposedly green region: the correct assessment also considers reliability, latency, data sovereignty, and the embodied impact of hardware.

A useful operational metric is energy or carbon intensity per unit of useful work, such as grams of carbon dioxide equivalent per terabyte processed or per thousand analytical queries. Measurements vary by provider methodology and should therefore be treated as estimates. Carbon-aware scheduling should not violate availability, privacy, or deadline requirements.

8. Design Method: From Requirements to Platform

A disciplined design process begins with workload and business requirements rather than with a preferred service.

Step 1: Characterise the workload

Document data volume, velocity, variety, retention, query patterns, latency, concurrency, peak-to-average ratio, ordering requirements, and failure tolerance.

Step 2: Classify data and constraints

Identify personal, confidential, regulated, operational, and public data. Record residency, retention, encryption, audit, and deletion requirements.

Step 3: Select storage and data formats

Choose object, block, file, database, warehouse, or lakehouse services based on access patterns. Prefer open, documented formats where future migration is important.

Step 4: Select compute and processing style

Compare batch, micro-batch, streaming, interactive SQL, machine learning, and transactional workloads. Decide whether managed clusters, containers, virtual machines, or serverless execution best fits the workload.

Step 5: Design failure and recovery behaviour

Define RPO, RTO, retry policies, idempotency, replay, backup, replication, and degradation modes. Test them under realistic conditions.

Step 6: Design identity, governance, and observability

Specify ownership, access paths, audit evidence, lineage, quality checks, metrics, logs, traces, alerts, and escalation procedures.

Step 7: Model cost and sustainability

Estimate normal and peak cost, migration cost, data-transfer cost, operational labour, and environmental impact. Establish budgets and unit metrics.

Step 8: Automate and validate

Use infrastructure as code, continuous integration, policy testing, schema testing, performance tests, chaos experiments, restore tests, and controlled releases.

9. Illustrative Case: Regional Retail Intelligence Platform

Background

A fictional international retailer operates point-of-sale systems in 12 countries, an on-premises enterprise resource-planning system, and a growing e-commerce channel. It requires near-real-time inventory visibility, daily financial reporting, and machine-learning forecasts. Some customer data must remain within national or regional boundaries.

Problem

The existing central data warehouse receives nightly extracts. Inventory reports are often several hours old, data-transfer costs are increasing, and a single-site failure could interrupt reporting. The organisation wants cloud elasticity but cannot move all transactional data to one public provider.

Analysis

The workloads have different characteristics. Point-of-sale events are high-volume and append-oriented. Inventory updates require low-latency processing. Financial reporting needs governed, reproducible batch data. Forecasting needs historical data, feature engineering, and scalable experimentation. Regulatory constraints apply to customer identifiers, while aggregated sales data has fewer restrictions.

Approach and Solution

The retailer adopts a hybrid lakehouse design. Regional event gateways receive sales and inventory events. Events are partitioned by region and store, with event identifiers used for deduplication. Regional processing validates schemas, removes or tokenises sensitive fields, and writes governed data to regional object storage. Aggregated, non-identifying measures are replicated to a central analytical environment.

A managed stream processor calculates inventory deltas and publishes updates to operational dashboards. Daily financial transformations use an open table format and versioned schemas. Compute is serverless for irregular forecasting experiments and scheduled managed clusters for predictable nightly transformations. The on-premises ERP remains the system of record for selected transactions, while private connectivity and asynchronous queues reduce dependence on continuous network availability.

Identity is federated, with separate production and development roles. Policies restrict analysts to approved regional or aggregated datasets. Central observability records pipeline lag, rejected events, data freshness, query cost, and recovery status. Infrastructure and policies are deployed through code. Quarterly restore exercises verify that backups and regional failover procedures meet the agreed RTO.

Outcome

Inventory visibility improves from hours to minutes, while regulated customer identifiers remain in approved locations. The architecture avoids full dependence on one provider by using open data formats and portable processing interfaces, but it deliberately accepts provider-specific managed streaming and identity features where their operational benefits are substantial. The organisation also discovers that replication of large historical datasets is more expensive and carbon-intensive than expected, leading to lifecycle policies and selective replication.

Learning Points

The case demonstrates that hybrid architecture should be organised around data classification and workload characteristics, not around an abstract desire to use multiple clouds. It also shows that portability is selective, resilience requires testing, and sustainability must be considered alongside latency and compliance.

10. Contemporary Developments and Critical Perspectives

Lakehouse systems continue to converge data-lake flexibility with warehouse governance. Their success depends on transaction semantics, catalogue interoperability, metadata quality, and disciplined table maintenance rather than on terminology alone. Data mesh approaches emphasise domain ownership and data products, but decentralisation without common standards can increase inconsistency and duplication.

Confidential computing uses hardware-supported protected execution environments to reduce exposure while data is processed. It may help with sensitive workloads, but organisations must evaluate attestation, performance, provider trust, and operational complexity. Policy-as-code and automated compliance are becoming essential as platform scale exceeds manual review capacity.

Generative AI is increasingly used to produce SQL, infrastructure configurations, data-quality rules, and operational explanations. It can accelerate engineering but may generate insecure permissions, incorrect queries, or misleading diagnoses. Human review, testing, provenance, and least privilege remain necessary. AI workloads also intensify concerns about accelerator scarcity, energy consumption, data leakage, and model governance.

A mature platform therefore treats cloud adoption as socio-technical design. Technology, contracts, skills, controls, operating procedures, and organisational incentives jointly determine outcomes.

Challenges and Limitations

Cloud platforms do not eliminate distributed-systems problems. Network partitions, inconsistent views, retries, clock differences, quota limits, noisy neighbours, and correlated provider failures remain possible. Managed services may hide implementation details that are important during diagnosis. Pricing complexity can produce unexpected bills, especially through data transfer and high-frequency API calls.

Hybrid systems introduce latency, incompatible identity models, duplicated monitoring, and difficult change management. Multicloud systems may increase resilience in theory while creating more common configuration errors in practice. Open standards improve portability but cannot remove data gravity, skills dependence, or migration cost. Finally, sustainability estimates are often incomplete, so claims should be transparent about boundaries, assumptions, and measurement uncertainty.

Best-Practice Checklist

• Begin with workload, regulatory, and recovery requirements.
• Separate data, compute, control, security, and governance concerns.
• Prefer open formats and documented interfaces where replacement matters.
• Use managed services when their benefits justify dependency.
• Make processing idempotent and design explicitly for retries.
• Define and test RPO and RTO rather than merely documenting them.
• Monitor cost, performance, quality, security, and sustainability together.
• Treat identity configuration as a primary security control.
• Automate infrastructure, policy, testing, and evidence collection.
• Rehearse migration, restoration, failover, and incident response.

Chapter Summary

Cloud and hybrid data platforms combine elastic infrastructure with managed storage, compute, serverless execution, and streaming services. Their design requires more than choosing a provider: engineers must match architecture to workload shape, data classification, latency, recovery, governance, cost, portability, and sustainability requirements.

Object storage and lakehouse formats provide scalable analytical foundations; managed databases and warehouses support governed access; containers and clusters provide control; serverless services reduce infrastructure administration; and streaming platforms support continuous event processing. Scalability is constrained by serial work, data movement, metadata, and resource contention. Availability and resilience depend on redundancy, recovery objectives, idempotency, replay, and tested procedures.

Hybrid and multicloud architectures can satisfy sovereignty, integration, resilience, and capability requirements, but they also create operational and economic complexity. Vendor lock-in should be assessed at data, compute, identity, processing, and operational layers. The shared-responsibility model requires customers to secure data, identities, configurations, applications, and governance even when the provider manages the underlying infrastructure.

A professional cloud data engineer makes trade-offs explicit, measures unit economics and environmental impact, automates controls, and validates assumptions through testing. The most effective architecture is not necessarily the most distributed or the most portable; it is the one whose dependencies, risks, and operational responsibilities are understood and managed.

Key Terms

Cloud platform: A programmable pool of on-demand computing, storage, networking, and managed services.

Hybrid cloud: An architecture combining privately controlled infrastructure with public-cloud resources.

Multicloud: The use of services from two or more cloud providers.

Object storage: Scalable storage of independently addressed objects, commonly used for data lakes.

Lakehouse: A data architecture combining lake-style storage with warehouse-style governance and transactions.

Serverless computing: Provider-managed execution in which customers specify code, queries, or configuration rather than servers.

Streaming: Continuous ingestion and processing of event records.

Partition: A subdivision of data or events used for parallelism and, often, local ordering.

Idempotency: The property that repeated execution produces the same logical result as one execution.

RPO: Recovery point objective; the maximum acceptable amount of data loss measured in time.

RTO: Recovery time objective; the maximum acceptable time to restore service.

Availability: The proportion of time a service is usable according to a defined criterion.

Scalability: The ability of a system to accommodate increased workload.

Elasticity: The ability to acquire and release resources in response to changing demand.

Vendor lock-in: The difficulty, cost, or risk of changing provider or service.

Data gravity: The tendency of large or valuable datasets to attract applications and make movement difficult.

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

Data lineage: A record of data origins, transformations, movement, and outputs.

FinOps: A practice connecting cloud consumption, engineering decisions, and financial accountability.

Carbon-aware computing: Scheduling or designing workloads with consideration of energy and carbon impact.

Review Questions

Short Answer Questions

1. Distinguish vertical scaling from horizontal scaling.
2. What are RPO and RTO, and why are they different?
3. Why does serverless computing not mean that servers are absent?
4. Define vendor lock-in and identify two causes of it.
5. What responsibilities commonly remain with a cloud customer under the shared-responsibility model?

Long Answer Questions

1. Explain how object storage, managed warehouses, containers, and serverless services can be combined in a cloud data platform.
2. Compare hybrid and multicloud architectures, including their motivations, benefits, and operational risks.
3. Discuss how streaming systems handle partitioning, ordering, delivery semantics, and late events.
4. Evaluate the relationship among portability, managed services, cost, and operational control.
5. Develop a governance and security framework for a regulated cloud lakehouse.

Analytical / Application Questions

1. A platform receives 6 TB of compressed data daily, retains it for 60 days, maintains 1.5 effective copies, and reserves 20% overhead. Calculate the planning capacity using C_total = D_daily × R × T × (1 + O). State two factors not captured by the estimate.
2. A data pipeline has a serial fraction of 0.08. Using Amdahl’s law, estimate the ideal speed-up with 16 workers and explain why actual speed-up may be lower.
3. Design a hybrid architecture for a hospital that must keep identifiable patient data within a national boundary but wants cloud-based analytics and disaster recovery. Justify storage, processing, identity, resilience, and governance choices.

Multiple Choice Questions with Answers

Question 1

Which storage type is generally most suitable as the durable foundation for a large analytical data lake?

A. Object storage

B. Block storage attached to one virtual machine

C. A local temporary disk

D. A browser cache

Correct Answer: A. Object storage

Question 2

A workload has a serial fraction of 0.1. According to Amdahl’s law, what is the ideal speed-up with 20 workers?

A. 2

B. 7.14 approximately

C. 18

D. 20

Correct Answer: B. 7.14 approximately

Question 3

Which statement best describes an RPO of 15 minutes?

A. The service must recover within 15 minutes

B. The system may lose no more than approximately 15 minutes of data

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

D. The backup must run exactly every 15 minutes

Correct Answer: B. The system may lose no more than approximately 15 minutes of data

Question 4

Which property is most important when a serverless data-processing function may be retried?

A. Idempotency

B. Global ordering

C. Manual provisioning

D. Permanent local state

Correct Answer: A. Idempotency

Question 5

What is a common consequence of partitioning a streaming topic?

A. Guaranteed global ordering across all records

B. Parallel processing with ordering typically limited within a partition

C. Elimination of duplicate events

D. Removal of the need for consumer coordination

Correct Answer: B. Parallel processing with ordering typically limited within a partition

Question 6

Which formula represents availability for two independent redundant components where either can serve the request?

A. A₁ × A₂

B. A₁ + A₂

C. 1 − (1 − A₁)(1 − A₂)

D. 1 − A₁A₂

Correct Answer: C. 1 − (1 − A₁)(1 − A₂)

Question 7

Which choice most directly reduces cloud vendor lock-in at the data layer?

A. Using undocumented proprietary formats

B. Using open, documented data formats and export procedures

C. Increasing the number of provider-specific APIs

D. Storing all data in temporary instance disks

Correct Answer: B. Using open, documented data formats and export procedures

Question 8

Under the shared-responsibility model, which activity normally remains the customer’s responsibility?

A. Physical security of the provider’s data centre

B. Manufacture of provider servers

C. Correct configuration of customer identities and access policies

D. Maintenance of the provider’s power systems

Correct Answer: C. Correct configuration of customer identities and access policies

Question 9

Which practice most directly supports carbon-aware data engineering?

A. Retaining every intermediate file indefinitely

B. Running all workloads at maximum capacity continuously

C. Right-sizing resources and applying lifecycle policies to unnecessary data

D. Replicating every dataset to every region

Correct Answer: C. Right-sizing resources and applying lifecycle policies to unnecessary data

Question 10

Why might an organisation choose a hybrid architecture?

A. To guarantee that no network failure can occur

B. To satisfy data-residency requirements while using cloud elasticity for permitted workloads

C. To eliminate all operational complexity

D. To avoid defining recovery objectives

Correct Answer: B. To satisfy data-residency requirements while using cloud elasticity for permitted workloads