1. Foundations and Evolution of Cloud–Edge Computing

Introduction and Context

Cloud–edge computing is best understood not as a single technology but as an architectural continuum. It connects centralized data centres, regional cloud facilities, telecommunications networks, enterprise infrastructure, local edge servers, gateways, sensors, and end-user devices. The central architectural question is no longer simply where computation should occur. It is how computation, storage, data, control, and intelligence should be distributed across locations with different capabilities, costs, latency characteristics, governance requirements, and failure modes.

The emergence of this continuum reflects a long history of computing. Mainframes centralized processing for reasons of cost and control. Client–server systems distributed interaction between personal computers and servers. The Internet connected autonomous networks, while clusters and grids aggregated geographically distributed resources. Utility computing and virtualization later made computing capacity programmable and rentable. Cloud computing industrialized this model through elastic, measured, and service-oriented infrastructure. More recently, the growth of connected devices, real-time applications, artificial intelligence, and data sovereignty requirements has encouraged computation closer to where data is produced and consumed.

For doctoral study, cloud–edge computing should therefore be examined historically, architecturally, and critically. Its evolution involves not only technical innovation but also changing economic models, institutional arrangements, standards, security assumptions, and research problems. The cloud and the edge are complementary rather than mutually exclusive. Most contemporary systems require both: cloud platforms provide scale, coordination, durable storage, and advanced analytics, while edge resources provide locality, responsiveness, resilience, and context awareness.

Learning Objectives

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

1. Explain the historical progression from centralized computing to cloud–edge continuum architectures.

2. Distinguish cloud, fog, edge, mist, and continuum computing.

3. Relate service models, deployment models, and essential cloud characteristics to architectural decisions.

4. Identify the stakeholders, workloads, standards, and ecosystem components involved in cloud–edge systems.

5. Evaluate the benefits, limitations, risks, and governance implications of distributing computation.

6. Apply cloud–edge concepts to a realistic organizational or industrial scenario.

7. Recognize current research directions and formulate defensible architectural questions.

From Centralized Machines to Distributed Systems

Early mainframe computing concentrated processing, storage, and administration in a controlled facility. Users accessed shared resources through terminals. Centralization simplified management and enabled expensive hardware to be utilized by many users, but it also created dependence on a central site and communication paths. Workloads were typically batch-oriented, and interaction was constrained by the capabilities of terminals and networks.

The personal computer shifted computation toward the user. Client–server architecture subsequently divided responsibilities: clients handled presentation and some processing, while servers managed shared data and services. This arrangement improved interactivity and organizational flexibility, yet it introduced problems of synchronization, administration, software distribution, and inconsistent client configurations.

Distributed systems generalized the idea that multiple networked computers could cooperate while appearing, to some extent, as a unified system. Distributed computing offers scalability and fault tolerance, but it also exposes fundamental difficulties. Network delay is variable; partial failure is normal; clocks are imperfectly synchronized; data may be replicated; and agreement among autonomous components can be expensive or impossible under some failure assumptions. These issues remain central to cloud–edge architecture.

Clusters placed multiple computers in close proximity and coordinated them for high performance or availability. Grids connected resources belonging to different institutions, often across administrative domains. Peer-to-peer systems distributed control among participants. Each model contributed concepts later absorbed by cloud computing: resource pooling, virtualization, scheduling, federation, replication, and automated management.

The Utility and Cloud Computing Shift

Utility computing proposed that computation could be consumed like electricity: users would obtain capacity when needed and pay according to use. The model required reliable networks, resource multiplexing, operational automation, and mechanisms for measuring consumption. Virtualization was particularly important because it allowed several logical machines or environments to share physical infrastructure while remaining sufficiently isolated.

Cloud computing transformed these ideas into commercially operated platforms. A cloud provider owns or manages a pool of configurable resources and exposes them through network-accessible services. Users need not purchase all underlying hardware and can provision resources programmatically. The cloud model changed the unit of infrastructure from a physical server to an on-demand service, and it changed the relationship between organizations and computing assets from ownership toward service consumption—although many organizations retain hybrid or private infrastructure.

A widely used conceptual reference, associated with the National Institute of Standards and Technology (NIST), defines cloud computing through five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. These characteristics are analytically useful, but they should not be treated as a complete definition of every modern platform. Serverless services, managed databases, platform services, and edge offerings may realize the characteristics differently.

On-demand self-service means that consumers can provision capabilities without direct human interaction with the provider. Broad network access means that services are reachable through standard mechanisms from heterogeneous devices. Resource pooling allows provider resources to serve multiple consumers through a multi-tenant model. Rapid elasticity allows capacity to expand or contract in response to demand. Measured service supports monitoring, control, transparency, and usage-based charging.

These characteristics also create tensions. Elasticity can complicate cost prediction. Multi-tenancy introduces isolation concerns. Broad access expands the attack surface. Measurement can support accountability but may enable intrusive surveillance. A doctoral analysis should therefore consider both capability and consequence.

Service Models and Deployment Models

Cloud service models describe the abstraction offered to a consumer. Infrastructure as a Service (IaaS) provides virtual machines, networks, storage, and related infrastructure primitives. The consumer controls operating systems and applications but usually does not control the provider’s physical infrastructure. Platform as a Service (PaaS) offers managed runtimes, databases, development tools, and deployment environments, allowing developers to focus more on application logic. Software as a Service (SaaS) delivers a complete application, with the provider controlling most of the technical stack.

The boundaries are not absolute. Containers, managed Kubernetes, database services, function platforms, and machine-learning services occupy intermediate positions. Function as a Service, often associated with serverless computing, abstracts server management and commonly bills according to execution or resource consumption. Serverless does not mean that servers disappear; rather, their administration is largely hidden from the application consumer.

Deployment models describe ownership, access, and administrative scope. A public cloud is operated for broad external use. A private cloud is dedicated to one organization, although it may be operated internally or by a third party. A community cloud serves organizations with shared requirements. A hybrid cloud combines distinct cloud or non-cloud environments and requires integration, portability, and coordinated governance. Multi-cloud strategies use services from multiple providers, sometimes to reduce dependency or obtain specialized capabilities, but they also increase operational complexity.

These classifications should not be confused. An organization may use a private IaaS cloud, public PaaS, and SaaS applications simultaneously. Similarly, an edge deployment may use IaaS-like virtual machines, PaaS-like application management, or SaaS-like industrial analytics.

Fog, Edge, Mist, and the Computing Continuum

Edge computing places computation, storage, or control near the sources or consumers of data. “Near” is application-dependent. It may mean within a device, on a local gateway, in a factory, at a cellular base station, in a retail branch, or in a regional facility. Edge is therefore a proximity concept, not a single hardware category.

Fog computing emerged as a distributed layer between cloud data centres and end devices. Fog nodes may include routers, gateways, access points, or local servers. The fog concept emphasizes hierarchical or geographically distributed resources, service orchestration, and support for latency-sensitive Internet of Things workloads. In practice, fog and edge terminology overlaps, but fog is often used to emphasize an intermediate, network-aware layer, whereas edge emphasizes the location of computation near data production or consumption.

Mist computing pushes computation further toward constrained devices and sensors. A sensor may perform filtering, anomaly detection, or rule-based control before transmitting data upstream. This reduces bandwidth and can preserve operation during disconnection, but device limitations restrict the complexity and reliability of local processing.

The computing continuum is a broader abstraction. It treats device, edge, fog, cloud, and sometimes high-performance computing resources as a coordinated space in which workloads may be placed, migrated, replicated, or split. Continuum architectures reject a strict binary distinction between cloud and edge. They instead ask which functions should run at which locations, under which constraints, and with what mechanisms for coordination.

A useful conceptual decomposition is:

• Device or mist layer: sensors, actuators, cameras, vehicles, and embedded processors.
• Local edge layer: gateways, industrial computers, branch servers, and on-premises micro-data centres.
• Regional or network edge: carrier sites, metropolitan facilities, and content delivery locations.
• Central cloud: large-scale provider data centres offering elastic compute, storage, analytics, and control services.

The layers are logical rather than universal. A regional edge site may be a cloud for one application and an edge for another.

Workloads and Placement Reasoning

Cloud–edge architecture is ultimately a workload-placement problem. A workload may include data ingestion, stream processing, model inference, training, visualization, storage, coordination, or actuation. Placement should be based on requirements rather than fashionable terminology.

Latency-sensitive control loops generally belong close to the physical process. A robotic safety function cannot depend exclusively on a distant cloud if network delay or disconnection could create unacceptable consequences. Bandwidth-intensive data, such as continuous video, may be filtered at the edge and summarized before transmission. Privacy-sensitive information may require local processing or controlled retention. Large-scale model training, long-term analytics, fleet-wide optimization, and backup are often well suited to centralized cloud resources.

Important placement criteria include end-to-end latency, jitter, bandwidth, energy, availability, mobility, data gravity, privacy, regulatory location, cost, hardware capability, and operational maturity. Placement is also dynamic. A vehicle, user, or workload may move; a network may become congested; an edge node may lose power; or a model may require retraining. Consequently, continuum orchestration must support monitoring, policy-based scheduling, state management, and graceful degradation.

The distinction between control plane and data plane is valuable. The data plane carries application data or performs immediate processing, often locally. The control plane manages configuration, identity, deployment, policy, and lifecycle, and may be centralized or hierarchically distributed. Designing a cloud–edge system requires deciding which control functions can tolerate cloud dependence and which must remain locally available.

Stakeholders and Ecosystems

Cloud–edge systems involve more stakeholders than traditional application deployments. Cloud providers supply infrastructure and managed services. Telecommunications operators provide connectivity, mobile core functions, and increasingly multi-access edge computing facilities. Device manufacturers produce sensors, gateways, and embedded platforms. Software vendors provide operating systems, containers, orchestration, observability, security, and data services. Application owners define business requirements, while systems integrators connect heterogeneous components. Regulators, standards organizations, employees, citizens, and affected communities also have legitimate interests.

Stakeholder incentives may conflict. A provider may prefer proprietary services that increase platform dependence, while an enterprise may value portability. A telecommunications operator may optimize network utilization, whereas an application may require deterministic latency. A public authority may demand local data residency, while a global analytics provider may favor centralized processing. Architecture is therefore partly a technical negotiation among economic, legal, and social objectives.

Major ecosystems include hyperscale public clouds, telecommunications and 5G platforms, industrial automation vendors, open-source container and orchestration communities, content delivery networks, and specialized IoT platforms. Kubernetes and related technologies have encouraged a common operational vocabulary, but they do not automatically solve edge constraints such as intermittent connectivity, limited hardware, heterogeneity, or physical exposure.

Standards, Portability, and Interoperability

Standards reduce ambiguity and support integration, but standardization does not guarantee portability. Relevant areas include cloud reference architectures, virtualization formats, container images, orchestration APIs, identity and access management, network functions, IoT protocols, data models, observability, and security controls. NIST publications provide influential terminology and reference guidance. ETSI has contributed important work on Multi-access Edge Computing (MEC), while standards and industry groups address 5G, IoT connectivity, distributed management, and cloud-native systems.

Interoperability has several dimensions. Syntactic interoperability concerns whether systems can exchange messages. Semantic interoperability concerns whether they interpret data consistently. Operational interoperability concerns whether services can be deployed, monitored, secured, and recovered across environments. Policy interoperability concerns identity, authorization, compliance, and contractual obligations.

Open interfaces can reduce lock-in, but portability has costs. A workload designed for a provider-specific database, accelerator, or event service may lose performance when moved to a generic platform. Researchers and architects should distinguish portability of code from portability of behavior, cost, security posture, and operational capability.

A Reference Architecture for the Continuum

A practical reference architecture can be organized into six planes. The device plane senses and acts. The connectivity plane provides wired, wireless, and mobile communication. The edge plane performs local processing and control. The regional plane aggregates resources and supports locality-aware services. The cloud plane supplies durable storage, large-scale analytics, training, and fleet coordination. The management and governance plane spans all layers, providing identity, policy, observability, compliance, deployment, and lifecycle control.

Cross-cutting concerns include security, data management, reliability, energy, and economic governance. Data may be filtered, aggregated, replicated, encrypted, anonymized, or deleted as it moves through the continuum. An architecture should specify ownership and stewardship at every stage, not merely draw arrows between components.

A useful design process is as follows:

1. Characterize the workload and its service-level objectives.

2. Identify data sources, destinations, sensitivity, volume, and velocity.

3. Determine which decisions require local autonomy.

4. Select candidate placement across device, edge, regional, and cloud resources.

5. Define communication, synchronization, and failure behavior.

6. Establish identity, trust, policy, monitoring, and update mechanisms.

7. Evaluate cost, performance, resilience, portability, and environmental impact.

8. Validate the design through representative experiments and operational tests.

Applications and an Illustrative Case

Cloud–edge architectures support industrial inspection, connected vehicles, healthcare monitoring, smart buildings, retail analytics, augmented reality, telecommunications optimization, agriculture, energy systems, and disaster response. Their value is greatest when locality, timeliness, scale, or intermittent connectivity matters.

Illustrative Case: Predictive Maintenance in a Distributed Manufacturing Enterprise

Background. A manufacturer operates several plants in different regions. Each plant has machines fitted with vibration, temperature, and acoustic sensors. The organization wants to predict equipment failure and compare production performance across sites.

Situation and problem. Sending all raw sensor streams to a central cloud produces high bandwidth costs and delays. Some plants have unreliable external connectivity. Maintenance decisions must sometimes be made within seconds, while corporate analysts require historical data over several years. Sensor data may also reveal commercially sensitive production information.

Analysis. The workload contains at least four distinct functions. Immediate anomaly detection is latency-sensitive and must continue during network outages. Short-term plant-level diagnosis benefits from local context. Model training and cross-site comparison require large datasets and centralized computation. Long-term retention requires durable, economical storage. Treating the entire workload as either “cloud” or “edge” would therefore be inappropriate.

Approach. The manufacturer installs industrial edge servers at each plant. They ingest sensor streams, perform signal filtering, and run inference models locally. Only features, alerts, selected diagnostic windows, and governance-approved summaries are sent to a regional cloud service. The cloud retrains models using data from multiple sites and distributes signed model updates. A local policy engine allows safe fallback rules when the cloud or network is unavailable. Device identities are provisioned individually; communications are encrypted; model and software updates are authenticated; and operators receive explanations and confidence information rather than unexplained automated alarms.

Outcome. The architecture reduces unnecessary data transfer and supports rapid local response while retaining enterprise-wide learning. Its success depends not only on placement but also on model lifecycle management, clock synchronization, data quality, asset inventory, and clear responsibility for maintenance decisions.

Learning points. Edge computing does not eliminate the cloud; it changes the division of labor. Data reduction can improve cost and privacy, but it may remove information needed for later investigation. Local autonomy improves resilience but expands the security and management boundary. Finally, technical performance must be evaluated together with operational adoption and accountability.

Challenges, Risks, and Limitations

Cloud–edge systems enlarge the attack surface. Edge nodes may be physically accessible, poorly patched, or deployed in hostile environments. Heterogeneous devices complicate asset management and vulnerability response. Identity must cover devices, workloads, operators, services, and automated agents. Zero-trust principles are relevant because network location alone should not establish trust.

Distributed data creates consistency and lineage problems. A locally generated decision may be based on stale information, while replication may expose sensitive data in additional locations. Designers must choose among strong consistency, eventual consistency, local autonomy, and graceful degradation according to the application’s consequences.

Operational complexity is another major limitation. A centralized cloud may contain thousands of servers, but an edge fleet may consist of thousands of locations with different power, connectivity, hardware, and environmental conditions. Observability must work under partial connectivity. Updates must be staged and reversible. Remote recovery, spare capacity, and physical access procedures require explicit planning.

Economic analysis can also be misleading. Moving computation to the edge may reduce network charges but increase hardware procurement, field support, energy consumption, and software management costs. Latency improvements may be valuable, but only if they change business or safety outcomes. Benchmarking should use realistic workloads, failure conditions, and total cost of ownership rather than isolated laboratory measurements.

Governance, Ethics, and Professional Responsibility

Distributed processing affects privacy, jurisdiction, labor, safety, and accountability. Local processing can minimize transfer of personal data, but it can also make decisions less visible to central auditors. Video analytics, biometric inference, and workplace monitoring require necessity, proportionality, purpose limitation, retention controls, and appropriate consent or legal authority.

When an edge-based AI system influences medical triage, industrial safety, transportation, or access to services, responsibility cannot be delegated to an opaque model or external provider. Organizations need documented decision rights, audit trails, human escalation paths, model validation, bias evaluation, and incident response. Data localization requirements may determine placement, but localization alone does not guarantee privacy or lawful processing.

Professional practice also requires environmental consideration. Replicating computation across many edge sites may increase embodied and operational energy costs. Efficient model design, workload consolidation, renewable-energy availability, device longevity, repairability, and responsible disposal should be included in architecture evaluation.

Current Developments and Research Directions

Several developments are shaping the field. Cloud-native edge platforms seek to extend containerized deployment and service management beyond centralized data centres. 5G and emerging mobile networks support lower-latency connectivity, network programmability, and infrastructure for multi-access edge services. Confidential computing aims to protect data and code during processing through hardware-assisted trusted execution. Federated learning and related privacy-preserving methods seek to train models without centralizing all raw data, although communication, statistical heterogeneity, and verification remain difficult.

Research is also addressing intent-based orchestration, serverless edge functions, digital twins, autonomous systems, deterministic networking, quantum-classical coordination, and sustainable continuum scheduling. Important open problems include placement under uncertainty, dependable AI at the edge, cross-domain trust, resource discovery, reproducible benchmarking, and economic mechanisms for sharing infrastructure.

A critical research perspective is necessary. Terms such as “real-time,” “intelligent,” and “edge-native” can conceal untested assumptions. Claims should be evaluated against measurable latency distributions, availability, energy, security, data quality, and failure recovery. The field still lacks universally accepted benchmarks that represent the diversity of devices, networks, and applications. Doctoral research can contribute by developing models, measurement methods, governance frameworks, or empirical evaluations that make these assumptions explicit.

Best Practices for Architectural Decision-Making

Sound cloud–edge design begins with requirements and failure analysis, not with selecting a vendor. Architects should:

• separate latency-critical control from delay-tolerant analytics;
• minimize and classify data before deciding where to transmit it;
• design for disconnection, degraded operation, and recovery;
• use explicit identity, least privilege, secure boot, encryption, and signed updates;
• automate deployment while retaining staged rollout and rollback capabilities;
• define ownership for data, models, policies, and incidents;
• measure end-to-end performance and total cost rather than component specifications;
• prefer open interfaces where they provide meaningful operational flexibility;
• maintain accurate inventories and observability across every site; and
• test physical, network, software, and organizational failure modes.

Chapter Summary

Cloud–edge computing evolved from centralized mainframes, client–server systems, distributed computing, clusters, grids, utility computing, virtualization, and cloud platforms. Cloud computing provides elastic, measured, network-accessible services through service models such as IaaS, PaaS, SaaS, and serverless, and through public, private, hybrid, and multi-cloud deployment arrangements. Edge, fog, and mist extend computation toward data sources and users, while the computing continuum treats all these resources as a coordinated placement space.

The central architectural task is workload placement under constraints involving latency, bandwidth, energy, privacy, resilience, mobility, cost, and governance. Successful systems divide responsibilities appropriately between local autonomy and centralized scale. They also address interoperability, security, lifecycle management, data consistency, standards, and stakeholder interests. Cloud–edge architectures create substantial opportunities in industry, healthcare, transportation, telecommunications, and intelligent infrastructure, but they introduce operational and ethical risks. Future research must evaluate emerging platforms through measurable evidence rather than terminology alone.

Key Terms

Cloud computing: Network-accessible computing services delivered from pooled, managed resources.

Edge computing: Processing and storage located near data sources or data consumers.

Fog computing: A distributed intermediate layer connecting end devices with centralized cloud resources.

Mist computing: Computation performed very close to or within constrained end devices.

Computing continuum: A coordinated architectural space spanning devices, edge, fog, regional, and cloud resources.

Utility computing: A model in which computing capacity is consumed and measured similarly to a utility.

Virtualization: Abstraction of physical computing resources into isolated logical environments.

IaaS: A service model providing virtualized infrastructure such as compute, storage, and networking.

PaaS: A service model providing managed application runtimes and development capabilities.

SaaS: A service model delivering complete applications to consumers over a network.

Serverless computing: An execution model that hides most server management from application developers.

Resource pooling: Sharing provider resources among multiple consumers through abstraction and allocation.

Elasticity: The ability to expand or contract resources in response to changing demand.

Multi-access Edge Computing: An edge-computing approach associated with telecommunications and network-accessible edge services.

Workload placement: The decision about where computational functions and data should execute.

Control plane: Functions that manage policy, identity, configuration, and lifecycle.

Data plane: Functions that process or transport application data and operational traffic.

Interoperability: The ability of independent systems to exchange and meaningfully use information or services.

Federated learning: Collaborative model training in which raw training data remains distributed across participating sites.

Digital twin: A digital representation of a physical object, process, or system maintained through data and models.

Review Questions

Short Answer Questions

1. What are the five essential characteristics commonly associated with cloud computing?

2. Distinguish fog computing from edge computing.

3. Why is virtualization important to the utility-cloud model?

4. What is meant by workload placement in a computing continuum?

5. State two reasons why edge systems may process data locally.

Long Answer Questions

1. Trace the evolution from centralized mainframes to cloud–edge continuum architectures.

2. Compare IaaS, PaaS, SaaS, and serverless computing, including the implications for responsibility and control.

3. Explain how latency, bandwidth, privacy, resilience, and cost influence cloud–edge placement decisions.

4. Discuss the technical and organizational challenges of managing a large edge fleet.

5. Evaluate the role of standards and interoperability in reducing cloud–edge dependency and operational risk.

Analytical / Application Questions

1. A hospital wants to monitor patients using wearable sensors while also training population-level models. Propose a cloud–edge division of responsibilities and justify it using latency, privacy, and resilience criteria.

2. An autonomous vehicle loses connectivity to its cloud provider during operation. Analyze which functions should continue locally, which may degrade, and what architectural controls are required.

3. A multinational retailer is considering a multi-cloud and edge strategy for video analytics. Develop a decision framework that addresses data governance, total cost, portability, security, and operational complexity.

22. Multiple Choice Questions with Answers

Question 1

Which architectural change most directly enabled computing resources to be offered as elastic, on-demand services?

A. Replacing networks with standalone personal computers

B. Combining virtualization, resource pooling, and automated provisioning

C. Eliminating shared storage from data centres

D. Moving all computation into sensors

Correct Answer: B. Combining virtualization, resource pooling, and automated provisioning

Question 2

A factory must stop a machine within milliseconds even when its external network connection fails. Where should the safety control function primarily execute?

A. A distant public-cloud region

B. A centralized corporate data warehouse

C. A local edge or device layer

D. A long-term archival storage service

Correct Answer: C. A local edge or device layer

Question 3

Which statement best distinguishes a service model from a deployment model?

A. A service model describes ownership, while a deployment model describes latency

B. A service model describes the abstraction offered, while a deployment model describes administrative scope

C. A service model applies only to edge systems, while a deployment model applies only to clouds

D. A service model describes security controls, while a deployment model describes programming languages

Correct Answer: B. A service model describes the abstraction offered, while a deployment model describes administrative scope

Question 4

In the manufacturing case, why were raw sensor streams filtered at the plant rather than all being sent to the cloud?

A. Filtering prevents any future model training

B. Filtering supports local responsiveness and reduces bandwidth and exposure of data

C. Cloud services cannot store time-series information

D. Edge servers always have greater processing capacity than clouds

Correct Answer: B. Filtering supports local responsiveness and reduces bandwidth and exposure of data

Question 5

Which situation most strongly illustrates the need for a computing-continuum perspective?

A. A static document stored on one laptop

B. A workload whose sensing, immediate control, model inference, and long-term training have different placement requirements

C. A calculator application with no network access

D. A printer configured with a fixed local address

Correct Answer: B. A workload whose sensing, immediate control, model inference, and long-term training have different placement requirements

Question 6

What is the principal risk of assuming that code portability automatically guarantees cloud portability?

A. Portable code cannot use encryption

B. A workload may run elsewhere but lose equivalent performance, security, cost, or operational behavior

C. Portability prevents the use of containers

D. Cloud services cannot be monitored after migration

Correct Answer: B. A workload may run elsewhere but lose equivalent performance, security, cost, or operational behavior

Question 7

Which function is most appropriately associated with the control plane?

A. Immediate actuation of a robotic arm

B. Streaming raw camera pixels to a display

C. Identity, policy, configuration, and lifecycle management

D. Physical measurement of machine temperature

Correct Answer: C. Identity, policy, configuration, and lifecycle management

Question 8

A company centralizes all video analytics in the cloud despite expensive links and strict local privacy requirements. Which analysis is most appropriate?

A. Centralization is always superior because cloud resources are elastic

B. Local filtering or inference should be evaluated against privacy, bandwidth, latency, and analytical needs

C. Video cannot be processed at the edge

D. Privacy requirements disappear when data is encrypted in transit

Correct Answer: B. Local filtering or inference should be evaluated against privacy, bandwidth, latency, and analytical needs

Question 9

Which practice best supports safe management of geographically distributed edge nodes?

A. Manual updates without inventory records

B. Unsigned software updates applied simultaneously everywhere

C. Authenticated updates, staged deployment, monitoring, and rollback

D. Allowing every device to use a shared administrative account

Correct Answer: C. Authenticated updates, staged deployment, monitoring, and rollback

Question 10

Why can federated learning be relevant to cloud–edge architectures?

A. It requires all raw data to be moved to one central server

B. It can support collaborative model training while keeping training data distributed, although coordination remains difficult

C. It eliminates the need for model validation

D. It guarantees that edge devices have unlimited computation

Correct Answer: B. It can support collaborative model training while keeping training data distributed, although coordination remains difficult