4. Cloud Infrastructure: Compute, Storage, and Networking

Introduction and Context

Cloud infrastructure is the engineered foundation on which cloud services are delivered. It comprises computational resources, storage systems, networks, control planes, security mechanisms, and operational processes that transform physical data-centre capacity into programmable services. Although cloud computing is often described through service models such as infrastructure as a service, platform as a service, and software as a service, these abstractions depend on concrete architectural decisions concerning processors, memory, persistent data, connectivity, placement, isolation, and failure recovery.

For doctoral-level analysis, infrastructure should not be understood merely as a collection of products. It is a socio-technical system involving hardware design, virtualization, distributed-systems theory, economic allocation, governance, and operational practice. A cloud architecture must reconcile competing objectives: elasticity and predictability, utilization and performance isolation, geographic reach and regulatory control, automation and human oversight, and abstraction and observability.

This chapter examines the major infrastructure building blocks and their relationships. It begins with compute abstraction, then considers storage and data movement, before analysing virtual networking, traffic distribution, content delivery, and interconnection. It concludes by comparing public, private, hybrid, multi-cloud, and sovereign-cloud designs and by examining an illustrative architecture decision.

Learning Objectives

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

1. Explain how virtualization, containers, accelerators, and software-defined infrastructure support cloud elasticity.

2. Distinguish block, file, object, and distributed storage according to semantics, performance, and failure behaviour.

3. Analyse virtual networks, load balancing, content delivery, and dedicated interconnection.

4. Evaluate public, private, hybrid, multi-cloud, and sovereign-cloud architectures.

5. Apply performance, cost, resilience, security, governance, and regulatory criteria to infrastructure decisions.

6. Critically assess contemporary infrastructure trends, including confidential computing, disaggregated systems, and intelligent operations.

From Physical Machines to Programmable Compute

A traditional data centre provisions physical servers for particular applications. This model can provide high performance but commonly produces low average utilization, slow capacity changes, and strong coupling between applications and hardware. Cloud infrastructure introduces a control plane that allocates resources through APIs and an abstraction layer that separates application deployment from the physical machine.

Virtual machines and hypervisors

A virtual machine (VM) is an isolated execution environment that presents virtual processors, memory, storage devices, and network interfaces to a guest operating system. A hypervisor manages this abstraction. Type 1 hypervisors execute directly on server hardware, whereas Type 2 hypervisors operate above a host operating system, although large production clouds predominantly use Type 1 designs or equivalent hardware-assisted virtualization.

Virtualization enables server consolidation, rapid provisioning, migration, snapshots, and policy-based placement. Hardware-assisted virtualization provides processor modes and memory-management mechanisms that reduce the cost of switching between guest and host execution. Nevertheless, virtualization is not free. Translation layers, virtual device processing, noisy neighbours, and oversubscription can affect latency and throughput. Live migration also requires transferring memory state and may be unsuitable for workloads with extreme bandwidth or latency sensitivity.

VMs remain valuable where strong operating-system isolation, legacy compatibility, custom kernels, or predictable resource allocation are required. Their principal limitation is that each instance commonly carries a complete guest operating system, increasing startup time and image size relative to lighter abstractions.

Containers and orchestration

Containers isolate application processes while sharing a host operating-system kernel. Images package application code, libraries, and configuration into reproducible artifacts. Compared with VMs, containers generally start faster and support higher workload density, but their isolation boundary is different: a kernel vulnerability can affect multiple containers on the same host. Container security therefore requires image provenance, least privilege, runtime restriction, patching, and suitable sandboxing.

An orchestrator schedules containers across a cluster, maintains desired state, performs service discovery, manages rolling updates, and replaces failed instances. The desired-state model is important conceptually: operators specify what should exist, while controllers continuously reconcile actual state with that specification. This supports automation but also introduces control-plane complexity, eventual convergence, and new failure modes involving scheduling, networking, persistent volumes, and configuration.

Containers do not eliminate VMs. In many cloud environments, containers run inside VMs to combine operational flexibility with an additional isolation boundary. The choice is therefore architectural rather than ideological.

Accelerated and specialized compute

General-purpose CPUs are not optimal for every workload. Graphics processing units (GPUs), tensor accelerators, field-programmable gate arrays (FPGAs), data-processing units (DPUs), and other specialized processors can improve performance for machine learning, scientific simulation, media processing, encryption, and packet handling. Accelerators introduce concerns about device sharing, memory locality, scheduling, driver compatibility, power consumption, and economic utilization.

For example, a training workload may require large accelerator memory and high-bandwidth interconnects rather than merely a high number of virtual CPUs. A cloud design that reserves accelerators without considering utilization may be technically capable but financially inefficient. Conversely, excessive virtualization of a device can cause interference and make performance difficult to predict. Accelerator-aware scheduling and telemetry are therefore essential.

Software-defined infrastructure

Software-defined infrastructure represents compute, storage, and networking resources through programmable control planes. Infrastructure as code expresses desired resources in declarative templates or code, enabling version control, review, testing, and repeatable deployment. Policy engines can enforce region restrictions, encryption requirements, network segmentation, and approved images before resources are created.

The distinction between control plane and data plane clarifies many cloud behaviours. The control plane makes placement, configuration, and policy decisions; the data plane executes workloads and forwards data. A control-plane outage may prevent new deployments while existing data-plane workloads continue operating. Resilient designs should therefore avoid unnecessary runtime dependence on centralized control services.

Software-defined infrastructure improves agility but can amplify errors. A faulty template, identity permission, or automation pipeline can change thousands of resources. Safe deployment requires versioning, peer review, progressive rollout, policy validation, drift detection, and tested recovery procedures.

Storage as a Set of Semantics

Storage selection should begin with application semantics rather than product names. Important questions include: Is data accessed through blocks, files, or objects? What consistency is required? What are the latency, throughput, and capacity expectations? How are replicas placed? What are the durability, deletion, recovery, and compliance requirements?

Block storage

Block storage presents raw logical volumes to a VM or physical host. The operating system formats the volume with a file system or database storage engine. It is appropriate for boot disks, transactional databases, and applications requiring low-latency random access. Performance is commonly described through input/output operations per second, latency, and throughput.

Block storage may be ephemeral or persistent. Ephemeral disks can provide fast local access but may lose data when an instance is terminated or relocated. Persistent volumes are typically replicated or attached through a networked storage service. The latter improves durability and mobility but introduces network dependency and possible latency variation.

File storage

File storage exposes hierarchical directories and files through shared protocols. It is useful for home directories, content-management systems, analytics pipelines, and legacy applications requiring shared file semantics. File locking, metadata operations, namespace design, and concurrent access often matter more than sequential throughput. Distributed file systems must manage consistency, metadata scaling, and recovery from node or network failures.

Object storage

Object storage manages immutable or replaceable objects identified by keys within namespaces such as buckets. An object includes data, metadata, and an identifier. It is well suited to backups, media, logs, datasets, archival content, and data lakes because capacity scales widely and access is API-based.

Object storage differs from a conventional file system. Applications should not assume low-latency updates, directory semantics, or transactional renaming unless the service explicitly provides them. Object systems commonly prioritize high durability and scalability through replication or erasure coding, while accepting higher access latency than local block devices. Lifecycle rules can move objects among performance and archival tiers, but retrieval delays and fees must be incorporated into design decisions.

Distributed storage and failure models

Distributed storage spreads data across nodes, disks, zones, or regions. Replication maintains multiple copies; erasure coding stores data and parity fragments to achieve durability with less raw-storage overhead than full replication, at the cost of reconstruction complexity and processing overhead. Placement policies should account for correlated failures. Three replicas on the same rack do not provide the same resilience as replicas across independent failure domains.

The end-to-end durability of a storage system is not identical to its availability. A system may preserve data while temporarily refusing requests, or remain available while accepting writes that are later lost under a design flaw. Recovery-point objectives (RPO) specify acceptable data loss measured in time, while recovery-time objectives (RTO) specify acceptable restoration time. These measures should be linked to business processes, not selected solely from provider marketing categories.

Consistency is another architectural choice. Strong consistency makes completed writes immediately visible according to a defined ordering model, simplifying some applications but potentially increasing coordination cost. Eventual consistency allows replicas to converge after updates and may improve scalability or geographic performance, but applications must tolerate stale reads, duplicate processing, or conflict resolution. Modern distributed systems often expose more nuanced guarantees, such as read-after-write consistency for selected operations.

Virtual Networks and Traffic Engineering

Cloud networking converts physical switching and routing into logical constructs. A virtual private cloud or equivalent environment typically includes address spaces, subnets, route tables, security groups, network access controls, gateways, and private endpoints. These components create isolation and traffic policy without requiring an application owner to operate physical switches.

Address planning remains foundational. Overlapping address ranges complicate mergers, hybrid routing, and multi-cloud connectivity. Subnets should reflect failure domains, exposure levels, workload tiers, and routing boundaries rather than arbitrary numerical divisions. Public exposure should be explicit; internal services should use private addressing and authenticated service-to-service communication where practical.

Security groups commonly provide stateful, workload-level filtering, while network access controls or firewalls may operate at subnet or perimeter boundaries. Network security should not rely on a single perimeter. Identity-aware authorization, encryption in transit, micro-segmentation, and service-level policies provide defence in depth.

Load balancing

A load balancer distributes requests across service instances and can perform health checking, connection termination, TLS handling, path-based routing, and traffic shifting. Layer 4 balancing operates on transport connections, whereas Layer 7 balancing understands protocols such as HTTP and can route using hostnames, paths, headers, or application conditions.

Load balancing is not simply an even distribution algorithm. Least-connections, weighted routing, latency-based selection, consistent hashing, and locality-aware policies serve different workloads. Session affinity can simplify stateful applications but reduces flexibility during failure and scaling. A robust design externalizes session state or makes services stateless where possible.

Health checks must measure meaningful service health. A process that responds to a shallow TCP probe may still be unable to access its database or complete useful work. Conversely, an overly demanding health check can remove healthy instances during a dependent-service incident, creating a cascading failure. Timeouts, retry budgets, circuit breakers, and back-pressure are important complements to balancing.

Content delivery and edge placement

Content delivery networks (CDNs) place caches and application functions near users. They reduce latency and origin bandwidth for cacheable content, but cache invalidation, authorization, personalization, and consistency require careful design. Time-to-live values, purge mechanisms, versioned asset names, and cache-control headers determine freshness behaviour.

Edge computing extends processing closer to devices or users when latency, bandwidth, privacy, or intermittently connected operation makes centralized processing unsuitable. Edge sites are usually more constrained than hyperscale regions: power, cooling, physical security, and operational staffing may be limited. Therefore, edge architectures should minimize state, support autonomous operation, and provide delayed synchronization rather than assume uninterrupted connectivity.

Interconnection

Applications that span sites require connectivity between cloud regions, enterprise facilities, edge locations, and providers. Internet VPNs are flexible and relatively quick to deploy, but performance depends on public paths. Dedicated interconnection or private circuits offer more predictable throughput and latency, although they require lead time, provider coordination, diverse paths, and careful routing design.

Hybrid connectivity is often described as a network problem when it is equally an identity and operations problem. A secure link does not automatically provide compatible addressing, DNS resolution, certificate management, monitoring, or authorization. Interconnection planning should include failure of the circuit, provider, route, and control plane.

Choosing an Infrastructure Deployment Model

The deployment model determines who controls infrastructure, where resources are located, and how responsibilities are divided.

Public cloud offers provider-operated, multi-tenant infrastructure with rapid elasticity and a broad service portfolio. It is attractive for variable workloads, global reach, experimentation, and access to specialized services. Trade-offs include dependence on provider APIs, variable costs, data-transfer charges, and reduced control over physical placement.

Private cloud dedicates infrastructure to one organization, either on premises or through a hosted arrangement. It may support specialized governance, predictable workloads, or legacy integration, but the organization bears more responsibility for capacity, hardware lifecycle, platform engineering, and resilience.

Hybrid cloud combines private and public environments with integration across identity, networking, data, and operations. It is useful when regulatory, latency, modernization, or capacity requirements differ across workloads. Hybrid designs often fail when they merely connect environments without defining authoritative data locations, operational ownership, and recovery procedures.

Multi-cloud uses more than one public provider. It can reduce concentration risk, satisfy regional requirements, or access differentiated capabilities. However, portability is frequently overstated. Applications may be portable at the VM or container level while remaining dependent on proprietary databases, identity systems, observability tools, and network services. Multi-cloud should therefore be justified by a specific risk or capability objective rather than treated as an automatic virtue.

Sovereign cloud emphasizes jurisdictional control over data, operations, personnel, infrastructure, and legal access. Sovereignty is multidimensional: storing data within a country does not necessarily ensure that foreign entities cannot administer systems or that encryption keys remain under local control. Sovereign designs may reduce provider choice and increase cost, but they can be necessary for public-sector, defence, critical-infrastructure, or sensitive regulated workloads.

A useful comparison evaluates six dimensions: control, elasticity, portability, resilience, regulatory fit, and total cost of ownership. No deployment model dominates across all dimensions. Workload placement should be determined by data classification, latency, dependency structure, failure tolerance, skills, and exit requirements.

An Architectural Decision Framework

Infrastructure decisions benefit from explicit constraints and measurable objectives. A design team can proceed through the following analytical sequence:

1. Classify the workload. Identify data sensitivity, computational pattern, statefulness, latency, geographic users, regulatory obligations, and availability requirements.

2. Define service objectives. Express RTO, RPO, latency percentiles, throughput, scalability range, and acceptable error rates.

3. Map dependencies. Include identity, DNS, databases, queues, observability, external APIs, and human operational processes.

4. Select abstractions. Decide whether VMs, containers, serverless functions, accelerators, or bare metal best match isolation and performance needs.

5. Design failure domains. Separate replicas across independent zones or sites and test degraded operation.

6. Evaluate economics. Include compute, storage, requests, inter-region transfer, dedicated links, licenses, operations, migration, and exit costs.

7. Validate governance. Apply data residency, retention, encryption, key control, audit, accessibility, and procurement requirements.

8. Prototype and measure. Benchmark realistic workloads, including cold starts, cache misses, failures, noisy neighbours, and recovery.

9. Automate and document. Use infrastructure as code, policy validation, runbooks, ownership records, and tested rollback.

This approach prevents an architecture from being selected solely on peak performance or unit price. It also exposes second-order effects, such as a cheap compute service becoming expensive because of cross-zone data transfer or operational complexity.

Illustrative Case Study: A Regulated Health Analytics Platform

Background

The following is a fictional illustrative case. MedData Research Network is a consortium of hospitals developing an analytics platform for population-health studies. It must process large historical datasets, support interactive queries for approved researchers, and run machine-learning workloads. Patient data is sensitive, and participating institutions operate in several jurisdictions.

Situation and problem

The consortium initially proposed a multi-cloud design to avoid dependence on one provider. However, the proposal placed replicated datasets in several regions, used separate identity systems, and transferred intermediate analytics data between providers. Early tests showed acceptable batch throughput but high query latency and unpredictable transfer costs. Auditors also questioned who could administer encryption keys and whether support personnel outside the jurisdiction could access diagnostic data.

Analysis

The workload was divided into three classes. Curated patient data required strong governance, controlled residency, encryption, and auditable access. De-identified research datasets required high-throughput object storage and elastic processing. Interactive dashboards required predictable latency and a resilient serving layer. The team determined that complete active-active multi-cloud operation would create excessive synchronization and identity complexity. Multi-cloud was retained selectively for disaster recovery and specialized model training rather than for every component.

Approach and solution

The consortium selected a sovereign-compatible primary region operated under contractual and technical controls appropriate to the most restrictive jurisdiction. Sensitive records remained in encrypted object storage with customer-controlled keys. A separate metadata catalog enforced purpose limitation and role- or attribute-based access. Batch analytics used ephemeral containers, while selected machine-learning jobs used scheduled GPU capacity. Interactive results were materialized into a lower-latency database rather than querying raw objects for every request.

Private connectivity linked hospitals to the cloud environment through diverse circuits, with encrypted VPN fallback. A web application firewall and Layer 7 load balancer protected the service tier. Object data was replicated across independent availability domains, and disaster recovery copies were encrypted and placed in a second approved jurisdiction. Infrastructure was deployed through reviewed templates, and policy checks blocked unapproved regions, public storage, and unencrypted volumes.

Outcome

The resulting architecture reduced unnecessary cross-provider transfers, clarified data ownership, and aligned infrastructure controls with data classifications. It did not eliminate multi-cloud, but narrowed its use to cases with demonstrable resilience or capability value. Operational exercises exposed a previously overlooked dependency: the identity provider was hosted in only one region. The team subsequently implemented emergency access procedures and tested cached authorization for carefully bounded read-only functions.

Learning points

The case demonstrates that multi-cloud is not synonymous with resilience. Resilience depends on independent failure domains, tested recovery, and manageable dependencies. It also shows that sovereignty includes administration and key control, not merely physical data location. Finally, storage, compute, networking, and governance decisions must be designed together; optimizing one layer in isolation can undermine the whole system.

Risks, Limitations, and Common Mistakes

Cloud infrastructure can fail through technical, organizational, and economic mechanisms. Common errors include treating availability zones as completely independent when they share dependencies, assuming replicas provide backup against accidental deletion, ignoring restore testing, and selecting storage based only on capacity price. Other mistakes include unrestricted administrative privileges, public management interfaces, hard-coded credentials, unbounded retries, insufficient address planning, and failure to monitor egress traffic.

Abstraction can conceal performance variability. A virtual CPU is not a universal measure of application capacity, and an object-storage request profile cannot be inferred from raw disk throughput. Benchmarking should use representative data, concurrency, access patterns, and failure conditions. Likewise, provider service-level agreements do not replace architectural resilience; an availability commitment may exclude customer configuration errors, dependency failures, or maintenance conditions.

Vendor lock-in deserves nuanced treatment. Proprietary services may provide substantial productivity, security, or performance advantages. Avoiding them at all costs can produce an inferior platform. The appropriate question is whether the organization understands the dependency, values the benefit, and maintains a credible exit or continuity strategy.

Governance, Ethics, and Professional Responsibility

Infrastructure architecture determines who can access data, where it can move, and how long it persists. Governance must therefore address classification, minimization, retention, deletion, lawful access, auditability, and accountability. Encryption is necessary but not sufficient: key custody, rotation, recovery, separation of duties, and access logging are equally important.

Automated placement and resource scheduling can encode organizational bias or create unequal access to scarce accelerators. Cost-optimization systems may terminate resources that appear idle but support accessibility, safety, or research continuity. Engineers should document assumptions, provide human review for high-impact actions, and preserve evidence for audit.

Professional responsibility also includes environmental considerations. Resource efficiency, workload scheduling, right-sizing, hardware lifecycle management, and regional energy characteristics influence the environmental footprint of cloud infrastructure. Sustainability should be evaluated alongside reliability and security rather than treated as a superficial reporting metric.

Current Developments and Research Directions

Several developments are reshaping infrastructure research and practice. Confidential computing uses hardware-supported trusted execution environments to protect data during processing, although attestation, side-channel risk, debugging, and key management remain active concerns. Disaggregated architectures separate compute, memory, and storage pools, potentially improving utilization while making network performance and failure recovery more central.

Composable infrastructure and high-speed fabrics seek to allocate resources dynamically across workloads. Serverless and event-driven systems continue to reduce infrastructure management for suitable applications, but cold starts, state management, observability, and platform dependence remain research topics. AI-assisted operations can detect anomalies, recommend capacity changes, and generate configuration proposals; autonomous changes require strong guardrails because infrastructure errors have broad blast radius.

Edge-cloud continuum architectures distribute computation across devices, local edge sites, regional facilities, and central clouds. Research questions include placement under uncertain connectivity, federated learning, privacy-preserving telemetry, and coordination across heterogeneous administrative domains. Sustainable cloud design is also developing through carbon-aware scheduling, workload migration, and lifecycle measurement, although these techniques must not compromise critical service objectives.

Best Practices for Doctoral and Professional Practice

A defensible infrastructure architecture should:

• begin with workload and data characteristics rather than provider features;
• separate control-plane and data-plane dependencies;
• design failure domains explicitly and test restoration, not merely backup creation;
• use least privilege, private connectivity, encryption, and auditable key management;
• treat infrastructure as code with review, testing, policy enforcement, and drift detection;
• measure latency percentiles, throughput, utilization, error rates, recovery time, and transfer cost;
• make state, consistency, and data movement explicit;
• use accelerators and specialized services only when measured benefit justifies complexity;
• document portability assumptions and maintain practical exit strategies; and
• conduct regular game days, security exercises, capacity reviews, and governance audits.

Chapter Summary

Cloud infrastructure transforms physical compute, storage, and networking into programmable, elastic services. Virtual machines provide strong isolation and compatibility; containers improve packaging and density; accelerators address specialized computation; and software-defined control planes enable repeatable automation. Storage must be selected according to block, file, or object semantics, consistency, performance, durability, and recovery objectives. Distributed storage requires explicit reasoning about replicas, erasure coding, failure domains, RPO, and RTO.

Virtual networks provide address spaces, routing, segmentation, and policy. Load balancers, CDNs, edge sites, and interconnection extend services across users, enterprises, and regions, but each introduces operational and consistency considerations. Public, private, hybrid, multi-cloud, and sovereign-cloud models represent different control, elasticity, regulatory, resilience, and cost trade-offs. Effective architecture uses workload classification, dependency mapping, measurable objectives, failure testing, governance, and economic analysis. Emerging directions include confidential computing, disaggregation, intelligent operations, edge-cloud systems, and sustainable infrastructure.

Key Terms

Virtual machine: An isolated software-defined computer running a guest operating system on virtualized hardware.

Hypervisor: Software or firmware that creates and manages virtual machines.

Container: An isolated application process that shares a host kernel while packaging code and dependencies.

Orchestrator: A control system that schedules workloads and reconciles actual infrastructure with desired state.

Accelerator: Specialized hardware designed to perform particular computations more efficiently than general-purpose CPUs.

Infrastructure as code: The declarative or programmatic management of infrastructure through versioned files and automated tools.

Control plane: Components that make configuration, scheduling, placement, and policy decisions.

Data plane: Components that execute workloads or forward application data.

Block storage: Storage presenting addressable volumes for operating systems and databases.

File storage: Storage exposing hierarchical files and directories through shared file semantics.

Object storage: API-based storage of objects identified by keys and accompanied by metadata.

Erasure coding: A technique that stores data and parity fragments to tolerate failures with reduced redundancy overhead.

Consistency: The guarantees governing when and how updates become visible to readers.

Recovery-point objective: The maximum acceptable amount of data loss, usually expressed as time.

Recovery-time objective: The maximum acceptable time to restore a service after disruption.

Load balancer: A system that distributes traffic among service instances or endpoints.

Content delivery network: A geographically distributed caching and delivery system for reducing user latency.

Interconnection: Network connectivity linking cloud, enterprise, edge, or provider environments.

Sovereign cloud: A cloud design emphasizing jurisdictional control over data, operations, infrastructure, and legal access.

Multi-cloud: The use of services or infrastructure from more than one cloud provider.

Review Questions

Short Answer Questions

1. What architectural benefits and costs are associated with virtual machines?

2. How do object storage semantics differ from file storage semantics?

3. Distinguish the control plane from the data plane.

4. What do RPO and RTO measure?

5. Why does a CDN improve performance for some workloads but not all?

Long Answer Questions

1. Compare VMs, containers, and accelerators as cloud-compute abstractions, including their isolation and operational implications.

2. Explain how replication, erasure coding, consistency, and failure domains influence distributed-storage design.

3. Analyse the roles of virtual networks, load balancers, CDNs, and dedicated interconnection in a global application.

4. Compare public, private, hybrid, multi-cloud, and sovereign-cloud models using control, resilience, cost, and governance criteria.

5. Develop an infrastructure decision framework for a regulated data-intensive application.

Analytical / Application Questions

1. A database experiences unpredictable latency on a shared virtualized platform. Which measurements and architectural alternatives would you investigate before changing providers?

2. An organization proposes active-active multi-cloud replication for every application. Evaluate the proposal and identify conditions under which a narrower strategy would be preferable.

3. Design a failure and recovery exercise for an edge-connected cloud application, including dependencies, metrics, and expected evidence.

22. Multiple Choice Questions with Answers

Question 1

Which characteristic most strongly distinguishes containers from virtual machines?

A. Containers always provide stronger isolation than VMs

B. Containers generally share a host kernel while VMs virtualize complete guest operating systems

C. Containers cannot be orchestrated across multiple hosts

D. VMs cannot run legacy applications

Correct Answer: B. Containers generally share a host kernel while VMs virtualize complete guest operating systems

Question 2

A workload requires hierarchical shared directories and file locking among many application instances. Which storage model is the most appropriate starting point?

A. Object storage

B. Ephemeral local storage

C. File storage

D. Archive storage

Correct Answer: C. File storage

Question 3

Why might erasure coding be selected instead of full replication in distributed storage?

A. It eliminates the need for failure domains

B. It can provide durability with less raw-storage overhead, at the cost of reconstruction complexity

C. It guarantees lower latency for every workload

D. It removes the need for backups

Correct Answer: B. It can provide durability with less raw-storage overhead, at the cost of reconstruction complexity

Question 4

Which statement best describes the relationship between RPO and RTO?

A. RPO measures restoration time and RTO measures data volume

B. RPO measures acceptable data loss and RTO measures acceptable restoration time

C. Both measure network latency

D. Both are measures of storage capacity

Correct Answer: B. RPO measures acceptable data loss and RTO measures acceptable restoration time

Question 5

A Layer 7 load balancer is particularly useful when routing decisions depend on which factor?

A. Only physical cable length

B. HTTP paths, hostnames, or headers

C. Disk sector numbers

D. CPU instruction sets alone

Correct Answer: B. HTTP paths, hostnames, or headers

Question 6

Why can a multi-cloud strategy fail to deliver the expected resilience?

A. Multiple providers always use identical failure domains

B. Applications may retain shared dependencies in identity, data, networking, or operations

C. Multi-cloud prevents encryption in transit

D. Public clouds cannot support disaster recovery

Correct Answer: B. Applications may retain shared dependencies in identity, data, networking, or operations

Question 7

Which design most directly addresses correlated storage failure?

A. Placing all replicas on one rack

B. Using three copies on the same host

C. Placing replicas or fragments across independent failure domains

D. Disabling health monitoring

Correct Answer: C. Placing replicas or fragments across independent failure domains

Question 8

What is a principal reason for using a dedicated interconnection rather than only an Internet VPN?

A. It guarantees that applications need no routing design

B. It can provide more predictable throughput and latency

C. It eliminates all provider outages

D. It makes identity management unnecessary

Correct Answer: B. It can provide more predictable throughput and latency

Question 9

In the illustrative health analytics case, why was multi-cloud not used for every component?

A. The consortium had no sensitive data

B. Cross-provider synchronization and identity complexity outweighed universal multi-cloud benefits

C. Object storage could not be used

D. GPU workloads cannot run in clouds

Correct Answer: B. Cross-provider synchronization and identity complexity outweighed universal multi-cloud benefits

Question 10

Which practice best reduces the blast radius of infrastructure automation errors?

A. Allowing unrestricted production permissions

B. Avoiding version control for templates

C. Using policy validation, peer review, progressive rollout, and tested rollback

D. Deploying all regions simultaneously

Correct Answer: C. Using policy validation, peer review, progressive rollout, and tested rollback