14. Doctoral Research and Emerging Cloud–Edge Futures

Introduction and Research Context

Cloud and edge computing have moved beyond the question of where computation should occur. Contemporary research asks how computational resources, data, intelligence, trust, and control should be distributed across cloud regions, access networks, devices, satellites, and specialized accelerators. This shift creates a rich doctoral research domain because cloud–edge systems are simultaneously technical infrastructures, organizational arrangements, economic platforms, and sociotechnical systems.

A useful research problem is rarely expressed simply as “how to improve edge computing.” It is instead formulated in terms of a measurable tension: latency versus energy consumption, sovereignty versus elasticity, privacy versus observability, autonomy versus human control, or specialized performance versus portability. Doctoral work must convert such tensions into research questions, operational definitions, artifacts, experiments, and defensible evidence.

This chapter presents a research-oriented framework for investigating cloud–edge architectures and evaluates several emerging directions: WebAssembly, edge serverless computing, autonomous operations, confidential AI, disaggregated infrastructure, 5G and 6G, satellite edge computing, and quantum–classical cloud integration. The objective is not to predict a single technological future, but to develop the intellectual tools needed to study alternative futures rigorously.

Learning Objectives

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

1. Formulate doctoral research problems for cloud–edge systems and distinguish research questions from engineering objectives.

2. Select and justify experiments, prototypes, simulations, testbeds, formal methods, design science, and case-study approaches.

3. Design reproducible evaluations using appropriate metrics, baselines, workloads, and statistical techniques.

4. Critically assess emerging cloud–edge technologies and identify their architectural assumptions and limitations.

5. Evaluate ethical, governance, security, and sustainability implications of distributed intelligent infrastructure.

6. Develop a defensible research agenda for future cloud–edge systems.

From Architecture Problems to Doctoral Questions

A doctoral investigation begins with a phenomenon, not a preferred tool. For example, the observation that edge applications experience unpredictable latency may lead to questions about placement, workload migration, network variability, or resource contention. The research contribution may be a new algorithm, a measurement method, a reference architecture, a formal model, an explanatory theory, or a validated design principle.

A strong research question has four characteristics. It identifies a phenomenon or relationship, specifies a context, allows evidence to be collected, and makes a plausible contribution beyond routine implementation. “Can a Kubernetes cluster run at the edge?” is primarily an engineering question. “Under what resource and network conditions does decentralized orchestration reduce tail latency without unacceptable control overhead?” is a researchable question.

Research questions may be classified as follows:

• Descriptive: What performance and failure patterns occur in geographically distributed edge deployments?
• Explanatory: Why does a particular placement strategy fail under mobility or bursty demand?
• Constructive: Can a new orchestration mechanism improve a defined objective?
• Comparative: Which architectural approach performs better under specified conditions?
• Predictive: Can workload, mobility, or failure behavior be forecast accurately enough to support control decisions?
• Evaluative: Does an artifact provide a significant improvement over credible baselines?

The unit of analysis must also be explicit. It may be a function invocation, service chain, node, cluster, network slice, application session, organization, or multi-domain ecosystem. Confusing these levels produces invalid conclusions—for example, inferring organizational resilience from the availability of one service.

Research Paradigms and Method Selection

No single method is adequate for all cloud–edge questions. Method selection should follow the claim being made.

Experimental and Benchmark Research

Experiments manipulate independent variables and observe dependent variables under controlled conditions. In cloud–edge research, independent variables may include node count, placement policy, bandwidth, packet loss, workload intensity, accelerator type, or security mechanism. Dependent variables may include median and tail latency, throughput, energy per request, availability, migration time, cost, and accuracy.

A credible experiment defines the workload, environment, intervention, baseline, repetitions, and stopping criteria. It distinguishes warm-start from cold-start behavior, separates control-plane overhead from application execution, and reports distributions rather than only averages. Tail latency is particularly important because an architecture that improves mean latency while worsening the 99th percentile may be unsuitable for real-time services.

Prototype-Based Research

A prototype makes an architectural idea concrete. It may implement a scheduler, a confidential inference pipeline, a WebAssembly runtime, or a cross-layer policy engine. Prototypes are valuable because they expose integration problems that abstract models omit. However, prototype results are not automatically generalizable. Researchers should document which components are production-grade, which are simplified, and which assumptions constrain interpretation.

A useful prototype evaluation has three layers: functional correctness, system performance, and comparison with alternatives. Releasing source code, configuration files, deployment manifests, and representative workloads substantially increases research value.

Simulation and Emulation

Simulation is appropriate when the target system is too large, expensive, or dangerous to construct. A simulator can explore thousands of nodes, mobility patterns, failure rates, or scheduling policies. Emulation executes real software in a controlled representation of the target environment, often using network shaping, virtual machines, or containers.

Simulation results depend on model validity. A mobility model that ignores building density, handover behavior, or user correlation may produce precise but misleading results. Validation should compare simulated behavior with measurements from a real testbed or published traces. Sensitivity analysis is essential: if a small change in an assumed parameter reverses the conclusion, the claim must be stated cautiously.

Testbeds and Field Studies

Testbeds provide evidence under realistic conditions. A cloud–edge testbed may include public cloud instances, local micro-data centers, embedded devices, programmable networks, and wireless links. Field studies add environmental and organizational realism, but reduce experimental control. They are especially useful for studying operational practices, failures, governance, and user behavior.

A doctoral researcher should record topology, hardware, software versions, network conditions, clock synchronization, telemetry configuration, and external disturbances. Reproducibility does not require every researcher to reproduce the exact physical environment; it requires sufficient information to understand, rerun, and critically evaluate the study.

Formal Methods

Formal methods are appropriate when correctness, safety, or compliance is central. Temporal logic, model checking, process algebra, theorem proving, and formal refinement can specify properties such as “a workload containing restricted data is never placed on an unauthorized node” or “a safety actuator cannot receive conflicting commands.”

Formal verification is powerful but bounded by the model. A verified policy may not remain safe if identity management, sensor assumptions, or network behavior are abstracted incorrectly. Thus formal methods should be connected to implementation evidence and threat modeling rather than presented as universal proof of system security.

Design Science and Case Study Research

Design science treats the creation and evaluation of an artifact as a research contribution. The artifact may be a method, architecture, algorithm, platform, or governance model. Its evaluation must demonstrate utility and explain design knowledge: why particular mechanisms were selected, what contexts they fit, and where they fail.

Case study research investigates cloud–edge phenomena in their real organizational context. A case may concern a hospital, factory, logistics network, or public agency. Case protocols should define the case boundary, evidence sources, interview procedures, analytical concepts, and rival explanations. A single case can support analytical generalization when it reveals a mechanism or boundary condition, but it should not be presented as statistically representative without appropriate sampling.

A Framework for Rigorous Evaluation

A defensible evaluation connects claims, metrics, workloads, baselines, and threats to validity. The following sequence is useful:

1. State the claim in measurable terms.

2. Define the target context and assumptions.

3. Select baselines that represent current practice and strong alternatives.

4. Identify independent variables and possible confounders.

5. Choose metrics aligned with user, system, and organizational objectives.

6. Repeat trials and quantify uncertainty.

7. Analyze failure cases, not only successful runs.

8. Publish artifacts and explain limitations.

Metrics should be multidimensional. Performance includes latency, throughput, jitter, and startup time. Resource efficiency includes CPU, memory, bandwidth, and energy. Dependability includes availability, recovery time, fault tolerance, and degraded-mode behavior. Security evaluation may include attack success probability, isolation strength, key exposure, and detection delay. Economic evaluation may include infrastructure cost, operational labor, egress cost, and cost per completed transaction.

Researchers should avoid metric substitution. A reduction in response time is not necessarily an improvement if it increases energy consumption, violates privacy, or causes unstable autoscaling. Multi-objective evaluation can use Pareto frontiers, weighted utility functions, or constrained optimization. The chosen method should be justified rather than selected because it produces a visually attractive result.

Statistical practice matters. Report sample sizes, dispersion, confidence intervals or credible intervals, and effect sizes. Randomization may reduce ordering effects; blocking can control for hardware or time-of-day differences. When repeated measurements are correlated, simple tests assuming independence are inappropriate. Reproducibility also requires controlling randomness in workload generation, documenting seeds, and distinguishing exploratory from confirmatory analysis.

Threats to validity commonly include construct validity, internal validity, external validity, and conclusion validity. Construct validity asks whether the metrics represent the concept of interest. Internal validity asks whether the intervention caused the observed effect. External validity concerns transfer to other hardware, workloads, or organizations. Conclusion validity concerns whether the data support the stated inference.

Emerging Architectural Directions

WebAssembly at the Edge

WebAssembly (Wasm) is a portable binary instruction format and execution environment originally associated with browser applications but increasingly used for server-side and edge workloads. Its appeal derives from compact deployment artifacts, language diversity, isolation mechanisms, and potentially rapid startup. Wasm can support policy filters, request transformation, event processing, and selected application functions close to users.

The research questions are more nuanced than portability alone. Researchers must examine runtime startup, memory limits, system-call access, networking, persistent state, observability, and compatibility with accelerators. Wasm isolation is not identical to a complete security guarantee; runtime configuration, host interfaces, dependencies, and supply-chain integrity remain critical. A meaningful evaluation compares Wasm with containers or virtual machines under equivalent workloads and security assumptions.

Edge Serverless Computing

Serverless computing abstracts infrastructure management and often uses event-driven functions. At the edge, serverless platforms promise rapid deployment across distributed locations and proximity to users. They also introduce cold starts, constrained execution, fragmented state, difficult debugging, and complex consistency requirements.

An important research issue is state placement. Stateless functions are easier to migrate, but practical applications require sessions, caches, durable records, or stream state. Replicating state across edge locations can reduce latency but increases coordination traffic and consistency complexity. Research should therefore evaluate complete workflows rather than isolated function execution. Questions of fairness also arise when providers use opaque placement policies that determine service quality across geographic regions.

Autonomous Cloud–Edge Operations

Autonomous operations use monitoring, machine learning, policy engines, and automated control loops to detect anomalies, predict demand, place workloads, and remediate faults. A control loop usually includes sensing, analysis, planning, execution, and feedback. The loop must be evaluated as a dynamic system: delayed or noisy telemetry can cause oscillating scaling, repeated migrations, or cascading failures.

Autonomy should be graduated. Advisory systems recommend actions; approval-based systems execute low-risk actions; fully autonomous systems act within predefined boundaries. Safe autonomy requires explainability appropriate to the decision, rollback mechanisms, policy constraints, audit trails, and human escalation. Reinforcement learning may optimize under changing conditions, but exploration in safety-critical environments requires a controlled environment or a conservative policy envelope.

Confidential AI

Confidential AI combines privacy-preserving computation with machine-learning workloads. Trusted execution environments can protect code and data from parts of the host operating system, while encryption, secure aggregation, differential privacy, or federated learning can reduce exposure during training and inference.

Confidentiality is not equivalent to privacy. A protected model may still reveal information through outputs, membership inference, or side channels. Confidential AI research should specify the adversary, trust boundary, leakage model, hardware assumptions, and performance cost. Edge deployment can improve data locality, but resource-constrained devices may lack suitable accelerators or secure key-management infrastructure. Governance must also address model provenance, consent, retention, and the right to challenge automated decisions.

Disaggregated Infrastructure

Disaggregation separates compute, memory, storage, and accelerators so that resources can be pooled and composed dynamically. High-speed interconnects and emerging memory technologies make it possible to treat resources as a fabric rather than as fixed servers. This can improve utilization and enable specialized allocation, but introduces network dependence, placement complexity, contention, and new failure domains.

Research should examine whether the performance benefits survive realistic congestion and failure. A disaggregated architecture may lower stranded capacity while increasing latency variance. Its operational model also differs from conventional virtualization: telemetry must capture resource-fabric behavior, and security policies must follow data and computation across composable components.

5G, 6G, and Integrated Connectivity

5G supports lower latency, higher capacity, mobility management, and programmable network functions, while research toward 6G explores tighter integration of communication, sensing, intelligence, and heterogeneous access technologies. Network slicing and multi-access edge computing can align connectivity with application requirements, but service-level guarantees depend on coordination among operators, cloud providers, and application owners.

Claims about ultra-low latency should be treated as conditional. End-to-end latency includes sensing, radio scheduling, transport, processing, queuing, and response transmission. A fast radio link cannot compensate for poor application placement or overloaded edge nodes. Research should measure the complete path and include mobility, handovers, coverage variation, and policy conflicts.

Satellite Edge Computing

Satellites can provide connectivity and, increasingly, onboard processing for remote or mobile environments. Satellite edge systems are attractive for maritime operations, disaster response, environmental monitoring, and geographically isolated communities. Their constraints include propagation delay, intermittent visibility, limited energy, radiation exposure, bandwidth scarcity, and difficult maintenance.

Architectures may divide processing among devices, satellites, ground stations, and cloud regions. Delay-tolerant protocols, content caching, data summarization, and disruption-aware scheduling are central research topics. Sustainability and orbital governance are also relevant: additional infrastructure produces environmental and regulatory consequences that cannot be reduced to application latency.

Quantum–Classical Cloud Integration

Quantum computing is likely to be accessed through cloud services integrated with classical control, optimization, storage, and analytics. Hybrid workflows may send selected subproblems to a quantum processor and use classical systems for orchestration and post-processing. The practical challenges include queueing, calibration drift, limited qubit quality, data-transfer overhead, programming abstractions, and verification of probabilistic outputs.

Doctoral research should resist treating quantum integration as automatically advantageous. The appropriate comparison is against the best classical baseline for the same problem, including data preparation and communication costs. Promising areas include hybrid optimization, scientific simulation, cryptographic transition planning, and quantum-resource scheduling. Evidence must distinguish theoretical speedup, algorithmic potential, and demonstrated end-to-end advantage.

Illustrative Case Study: A Distributed Clinical Monitoring Platform

Background

The following is an illustrative case constructed for research-method training. A regional healthcare network wants to monitor cardiac patients using wearable sensors, hospital edge nodes, and a cloud analytics platform. The system must detect urgent events quickly while preserving sensitive health data.

Situation and Problem

The initial design sends all sensor data to a central cloud. This produces acceptable average performance but poor tail latency during network congestion and creates concerns about data exposure and bandwidth cost. The proposed research artifact is a policy-driven architecture that performs preliminary feature extraction at the device, inference at a hospital edge node, and longitudinal analysis in the cloud. Confidential execution is proposed for selected inference workloads.

The research questions are: (1) under what network and workload conditions does hierarchical placement improve urgent-event latency; (2) what accuracy and energy costs result from local feature extraction; and (3) whether confidential execution provides a meaningful privacy benefit at acceptable performance cost.

Analysis and Approach

The researchers define three baselines: cloud-only processing, edge inference without confidentiality, and the proposed hierarchical confidential design. They use replayed physiological traces, synthetically generated congestion patterns, and a testbed containing wearable-class devices, an edge server, and cloud instances. Metrics include detection latency, 99th-percentile latency, false-negative rate, energy per observation, bandwidth consumption, and inference overhead.

The study also specifies an adversary who can inspect the host operating system but cannot break hardware-protected execution. Threats outside that model, such as malicious sensors or compromised clinicians’ accounts, are analyzed separately rather than silently excluded. The researchers preregister primary hypotheses, repeat trials across several workload intensities, and release deployment scripts and anonymized traces.

Outcome

The proposed design reduces network dependence for urgent decisions and lowers bandwidth usage, but confidential execution increases inference time and complicates debugging. Under severe edge overload, the policy engine transfers selected workloads to the cloud, creating a privacy–latency trade-off. The study therefore does not claim universal superiority. Instead, it produces a placement policy and identifies boundary conditions under which each architecture is appropriate.

Learning Points

The case illustrates the value of complete workflow evaluation, explicit threat models, credible baselines, and boundary-condition analysis. It also demonstrates that a research contribution may be a validated decision policy rather than a single architecture claimed to dominate all alternatives.

Professional, Ethical, and Governance Considerations

Cloud–edge infrastructures distribute responsibility. A failure may involve a device manufacturer, connectivity provider, edge operator, cloud provider, application developer, and data controller. Contracts and technical controls should define ownership of logs, incident response, patching, model updates, and service-level commitments.

Data minimization, purpose limitation, retention controls, access management, and regional processing requirements are central when edge systems handle personal or industrial data. Researchers must obtain appropriate approvals, protect participant data, and avoid publishing configurations that expose operational systems. Fairness evaluation is necessary where placement, admission control, or AI decisions affect communities differently because of connectivity, geography, or resource availability.

Environmental assessment should include embodied equipment impacts, network energy, cooling, data movement, and device replacement—not merely server utilization. Professional judgment also requires acknowledging uncertainty. A benchmark result obtained in a controlled laboratory should not be represented as evidence of universal operational benefit.

Common Research Errors and Better Practice

Frequent weaknesses include selecting metrics after seeing results, comparing against weak baselines, ignoring cold starts, reporting only mean values, omitting failed experiments, and treating a prototype as production evidence. Other errors include unclear threat models, unvalidated simulation assumptions, uncontrolled software versions, and claims of scalability based on a small deployment.

Better practice includes maintaining an experiment ledger, using infrastructure-as-code, capturing provenance for data and models, separating training and test workloads, conducting ablation studies, and publishing negative findings. Researchers should explain why an approach fails, because failure boundaries often provide more transferable knowledge than a best-case demonstration.

Research Agenda for Cloud–Edge Futures

Several themes warrant sustained doctoral attention. First, multi-domain orchestration needs economic and governance models, not only scheduling algorithms. Second, autonomous operations require rigorous safety cases and mechanisms for contesting automated decisions. Third, confidential and federated intelligence needs integrated evaluation of privacy, accuracy, latency, and energy. Fourth, emerging connectivity requires end-to-end models that include mobility, satellite links, and intermittent operation. Fifth, disaggregated and quantum–classical infrastructure demands new abstractions for resource identity, provenance, verification, and cost.

Across these themes, the central research challenge is coordination under uncertainty. Cloud–edge systems cannot be understood solely as collections of faster servers. They are adaptive infrastructures whose behavior emerges from software policies, networks, people, institutions, and physical environments. Doctoral contributions should therefore combine technical rigor with contextual explanation and transparent evidence.

Best Practices for Doctoral Cloud–Edge Research

• Begin with a precise phenomenon, context, and claim.
• Match the method to the type of knowledge sought.
• Define baselines, threat models, workloads, and metrics before experimentation.
• Measure tail behavior, resource cost, failures, and recovery—not only average speed.
• Use multiple forms of evidence when claims span architecture and organization.
• Validate simulations and report assumptions and sensitivity.
• Treat reproducibility as an architectural and documentation concern.
• Publish artifacts, configuration, data-generation procedures, and limitations where ethically possible.
• Evaluate security, privacy, fairness, sustainability, and governance alongside performance.
• State boundary conditions rather than claiming universal superiority.

Chapter Summary

Cloud–edge computing provides a substantial domain for doctoral research because it combines distributed systems, networking, artificial intelligence, security, operations, and governance. Rigorous research begins by transforming architectural tensions into precise questions and selecting methods that fit the intended claim. Experiments, prototypes, simulations, testbeds, formal methods, design science, and case studies each provide different forms of evidence and require explicit treatment of validity.

Reliable evaluation depends on credible baselines, realistic workloads, multidimensional metrics, statistical discipline, reproducible artifacts, and analysis of failure conditions. Emerging technologies—including WebAssembly, edge serverless platforms, autonomous operations, confidential AI, disaggregated infrastructure, advanced mobile networks, satellite edge systems, and quantum–classical integration—offer opportunities but also introduce new assumptions and risks. The future of cloud–edge research will depend less on technological novelty alone than on the ability to design systems that are measurable, trustworthy, governable, sustainable, and useful within real contexts.

Key Terms

Cloud–edge continuum: A distributed computing environment spanning centralized cloud regions, edge sites, networks, and end devices.

Research construct: An abstract concept, such as resilience or privacy, defined so it can be investigated through evidence.

Unit of analysis: The entity examined in a study, such as a node, request, service, organization, or ecosystem.

Experimental baseline: A reference implementation or condition against which a proposed approach is compared.

Tail latency: High-percentile response time, commonly used to represent poor experiences affecting a minority of requests.

Prototype: An implemented artifact used to explore, demonstrate, or evaluate a research idea.

Simulation: Computer-based representation of system behavior under specified assumptions.

Emulation: Execution of real software in an environment that reproduces selected properties of a target system.

Formal method: A mathematically based technique for specifying, verifying, or proving system properties.

Design science: A research paradigm centered on constructing and evaluating artifacts to produce design knowledge.

Threat model: An explicit description of adversaries, capabilities, assets, and trust assumptions.

Reproducibility: The ability of others to repeat a study using its documented methods, artifacts, and data procedures.

WebAssembly: A portable binary execution format supporting compact and sandboxed deployment across environments.

Edge serverless computing: Event-driven execution of managed functions or services near data sources and users.

Confidential AI: Artificial intelligence designed to protect data, models, or computation through hardware or cryptographic mechanisms.

Disaggregated infrastructure: Architecture that separates and pools compute, memory, storage, or accelerators for dynamic composition.

Network slicing: Logical partitioning of network resources and policies for differentiated service requirements.

Satellite edge computing: Processing and storage performed on or near satellite communication systems.

Hybrid quantum–classical computing: Workflows combining quantum processing with classical orchestration and computation.

Review Questions

Short Answer Questions

1. Why must a doctoral researcher distinguish an engineering objective from a research question?

2. What is the importance of reporting tail latency in cloud–edge evaluations?

3. State two limitations of simulation-based research.

4. Why is a threat model necessary when evaluating confidential AI?

5. What is meant by disaggregated infrastructure?

Long Answer Questions

1. Compare experiments, prototypes, simulations, testbeds, formal methods, design science, and case studies as approaches to cloud–edge research.

2. Explain how a researcher can design a reproducible and statistically credible cloud–edge evaluation.

3. Critically examine the benefits and limitations of edge serverless computing.

4. Discuss the architectural and governance challenges of autonomous cloud–edge operations.

5. Analyze the research opportunities and risks associated with satellite edge and quantum–classical cloud integration.

Analytical / Application Questions

1. Design an evaluation plan for a workload-placement algorithm operating across mobile devices, 5G edge nodes, and a cloud region. Specify research questions, baselines, metrics, workloads, and threats to validity.

2. A proposed confidential-AI system reduces data exposure but doubles inference latency and energy consumption. Develop a decision framework for determining whether it should be deployed in a healthcare edge environment.

3. A simulation reports that disaggregated infrastructure improves utilization by 30 percent. Identify the additional evidence required before claiming that it improves real-world application performance and operational value.

22. Multiple Choice Questions with Answers

Question 1

Which research question is most suitable for a doctoral investigation of edge orchestration?

A. Can an edge cluster run a container?

B. How many lines of code are in the scheduler?

C. Under what network and workload conditions does decentralized orchestration reduce tail latency without excessive control overhead?

D. Which programming language is most popular for edge applications?

Correct Answer: C. Under what network and workload conditions does decentralized orchestration reduce tail latency without excessive control overhead?

Question 2

Why should a cloud–edge study report tail latency in addition to mean latency?

A. Mean latency cannot be calculated in distributed systems

B. Tail latency reveals poor responses affecting a high-percentile subset of requests

C. Tail latency automatically measures energy consumption

D. Tail latency eliminates the need for baseline comparisons

Correct Answer: B. Tail latency reveals poor responses affecting a high-percentile subset of requests

Question 3

What is a central validity concern in simulation-based cloud–edge research?

A. Simulations cannot represent any network behavior

B. Simulation conclusions depend on whether model assumptions reflect the target system

C. Simulations always require more hardware than testbeds

D. Simulation results cannot be repeated with the same parameters

Correct Answer: B. Simulation conclusions depend on whether model assumptions reflect the target system

Question 4

Which statement best characterizes WebAssembly at the edge?

A. It guarantees complete security regardless of host configuration

B. It provides a portable execution format, but host interfaces and runtime configuration remain security concerns

C. It is designed only for quantum processors

D. It eliminates the need for persistent state management

Correct Answer: B. It provides a portable execution format, but host interfaces and runtime configuration remain security concerns

Question 5

What is a major research challenge in edge serverless computing?

A. The impossibility of event-driven execution

B. The absence of any possible workload migration

C. Managing application state, cold starts, consistency, and observability across distributed locations

D. The requirement that every function run in a centralized cloud

Correct Answer: C. Managing application state, cold starts, consistency, and observability across distributed locations

Question 6

Which feature is most important for safe autonomous cloud–edge operations?

A. Unrestricted automated experimentation in production

B. Removal of human escalation paths

C. Rollback mechanisms, policy boundaries, audit trails, and controlled autonomy

D. Use of machine learning without monitoring

Correct Answer: C. Rollback mechanisms, policy boundaries, audit trails, and controlled autonomy

Question 7

Why is confidential AI not identical to privacy-preserving AI in every respect?

A. Confidential execution may protect computation while outputs can still leak information

B. Confidential AI cannot use hardware protection

C. Privacy is unrelated to model outputs

D. Confidential AI applies only to networking

Correct Answer: A. Confidential execution may protect computation while outputs can still leak information

Question 8

What is the defining idea of disaggregated infrastructure?

A. Replacing all cloud services with personal devices

B. Separating and pooling resources such as compute, memory, storage, and accelerators

C. Using only one server for every application

D. Removing networks from data-center architectures

Correct Answer: B. Separating and pooling resources such as compute, memory, storage, and accelerators

Question 9

Why should claims about 5G or 6G latency be evaluated end to end?

A. Radio latency is the only component of application response time

B. End-to-end latency also includes processing, queuing, transport, and application placement

C. Wireless networks do not affect cloud applications

D. End-to-end measurement prevents mobility testing

Correct Answer: B. End-to-end latency also includes processing, queuing, transport, and application placement

Question 10

What is the most appropriate comparison when evaluating a quantum–classical cloud workflow?

A. Compare it only with an ideal theoretical quantum computer

B. Compare it with the strongest classical alternative, including preparation and communication costs

C. Compare only the quantum processor's execution time

D. Assume a quantum workflow is superior if it uses fewer source-code lines

Correct Answer: B. Compare it with the strongest classical alternative, including preparation and communication costs