7. Resource Management and Intelligent Orchestration

Introduction and Context

Cloud and edge computing are often described as a continuum rather than as isolated deployment models. At one end are centralized hyperscale data centres with abundant compute, storage, and network capacity; at the other are constrained edge devices, gateways, access networks, and micro-data centres located close to users and physical processes. Between them lie regional clouds, telecom sites, enterprise clusters, and fog nodes. This continuum creates opportunities for lower latency, improved locality, resilience, privacy, and reduced backhaul traffic. It also makes resource management substantially more difficult.

In a conventional cloud, a scheduler may select among a large number of homogeneous virtual machines in a single administrative domain. In a cloud–edge system, decisions must account simultaneously for heterogeneous processors, intermittent connectivity, mobility, energy budgets, service-level objectives, data gravity, sovereignty, and changing workloads. A placement that minimizes monetary cost may violate latency requirements; a placement that maximizes performance may exhaust an edge site's energy budget; and a placement that is technically feasible may be unacceptable under a data-residency regulation.

Resource management is therefore not merely the allocation of CPU, memory, storage, and bandwidth. It is a control problem involving observation, prediction, decision-making, actuation, and feedback. Intelligent orchestration extends this control loop by using optimization, heuristics, machine learning, and sometimes game-theoretic mechanisms to coordinate applications and infrastructure across multiple tiers.

Learning Objectives

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

1. Distinguish provisioning, scheduling, placement, autoscaling, admission control, migration, federation, and workload offloading.

2. Formulate resource-management decisions as constrained, multi-objective optimization problems.

3. Compare centralized, hierarchical, distributed, heuristic, game-theoretic, and reinforcement-learning approaches.

4. Design orchestration workflows for cloud–edge applications with latency, energy, cost, reliability, and privacy requirements.

5. Evaluate the operational, ethical, governance, and security implications of intelligent orchestration.

6. Critically identify limitations in current research and formulate suitable doctoral research questions.

The Resource-Management Problem Across the Continuum

A resource is any computational, storage, networking, sensing, or energy capability that can support a workload. Resources may be physical, virtual, or logical. A workload is a set of tasks, services, containers, functions, data objects, or workflows requiring resources over time. Orchestration is the coordinated process of deploying, configuring, connecting, scaling, monitoring, and retiring these workload components.

Several distinctions are essential. Provisioning makes resources available, for example by creating virtual machines, reserving accelerator capacity, or allocating an edge node to a tenant. Scheduling determines when tasks execute and in what order. Placement determines where components execute. Offloading transfers computation or data processing from a device or edge tier to another node, often the cloud. Autoscaling changes allocated capacity in response to demand. Admission control decides whether a new request can be accepted without violating existing commitments. Migration moves a running or restorable workload between nodes. Federation enables cooperation across independently operated domains.

These decisions are coupled. Admission control affects future utilization; placement affects network latency and energy consumption; migration affects service continuity and bandwidth; autoscaling affects cost and the feasibility of subsequent placements. Treating each decision independently can produce locally reasonable but globally poor outcomes.

A useful abstraction represents a workload as a directed acyclic graph or, for long-running services, as a service graph. Each component has resource demands and dependencies. Edges in the graph represent data flows with bandwidth, latency, ordering, or reliability requirements. The infrastructure is represented as a graph of nodes and links, each with capacities and attributes. Orchestration maps the workload graph onto the infrastructure graph while respecting constraints.

Important objectives include:

• response time and tail latency;
• throughput and deadline satisfaction;
• energy consumption and carbon intensity;
• financial cost and resource utilization;
• reliability, availability, and recovery time;
• privacy, trust, and data-sovereignty requirements; and
• fairness among tenants or applications.

These objectives are frequently conflicting. A multi-objective formulation may minimize a weighted function such as

J = w_l L + w_c C + w_e E + w_r R + w_p P,

where L denotes latency, C cost, E energy, R a reliability penalty, P a privacy or policy penalty, and the weights express organizational priorities. A weighted sum is convenient but can hide important trade-offs. In safety-critical systems, reliability may be a hard constraint rather than merely another weighted objective. A Pareto formulation is often more appropriate: a solution is Pareto-optimal when no objective can be improved without worsening at least one other objective.

A Control Architecture for Intelligent Orchestration

A robust orchestration system normally contains five logical functions. First, telemetry collectors observe resource utilization, queue lengths, network conditions, temperatures, failures, and workload-level indicators. Second, a state-estimation layer cleans and aggregates observations and may infer hidden conditions such as imminent saturation. Third, a decision engine selects actions such as placement, scaling, migration, or rejection. Fourth, an execution layer applies actions through cloud, cluster, network, and edge controllers. Fifth, a policy and governance layer constrains decisions according to security, compliance, tenancy, and business rules.

The control loop may be centralized, hierarchical, or distributed. A centralized controller has global visibility and can solve broad optimization problems, but it may become a scalability bottleneck and a single point of failure. A hierarchical design allows local edge controllers to make fast decisions while regional or cloud controllers coordinate longer-term capacity and policy. Distributed control improves locality and autonomy but introduces incomplete information, coordination overhead, inconsistent state, and the possibility of oscillation.

The time scale of a decision matters. Capacity planning may operate over weeks or months; infrastructure provisioning over minutes; service autoscaling over seconds; and device offloading over milliseconds. Combining all decisions in one controller is usually impractical. Multi-timescale orchestration separates slow strategic decisions from fast tactical reactions.

Provisioning, Scheduling, and Placement

Provisioning can be static, elastic, or predictive. Static provisioning reserves capacity in advance and is suitable for stable workloads or strict guarantees. Reactive elastic provisioning adds or removes resources after observing demand. Predictive provisioning uses forecasts to prepare for expected peaks. Predictive methods can reduce cold-start and queueing delays, but inaccurate forecasts may cause waste or service degradation.

Scheduling policies differ in their assumptions and goals. First-come, first-served is simple but may penalize short jobs behind long ones. Shortest-job-first improves mean completion time when job sizes are known, although it can starve large jobs. Priority scheduling supports differentiated services but requires carefully governed priority classes. Fair-share scheduling distributes capacity among tenants, while deadline-aware scheduling emphasizes completion constraints. In edge systems, scheduling must also consider mobility, data locality, wireless conditions, and device availability.

Placement is a constrained mapping problem. A service may require a particular processor architecture, accelerator, operating-system feature, trusted execution environment, or geographic location. Affinity rules place related components together to reduce communication overhead; anti-affinity rules separate replicas to improve fault tolerance. Data locality reduces network traffic, but excessive locality can create hot spots. Placement must therefore consider both current state and expected future demand.

A common formulation uses binary variable x_ij, equal to one when workload component i is placed on node j. Capacity constraints ensure that the sum of resource demands assigned to a node does not exceed its capacity. Additional constraints express link bandwidth, latency, affinity, geographic boundaries, replica separation, and policy restrictions. The resulting mixed-integer problem is often NP-hard, so exact optimization is usually limited to small instances or planning horizons.

Autoscaling and Admission Control

Autoscaling changes the number or size of resources supporting a service. Horizontal scaling adds or removes instances; vertical scaling changes the resources assigned to an instance; and functional scaling changes the execution path, such as moving a processing stage from a device to an edge node. Scaling signals may include CPU utilization, queue length, request rate, response-time percentiles, event intensity, or application-specific indicators.

Threshold policies are easy to operate but can oscillate when demand changes rapidly. Hysteresis, cooldown periods, and minimum replica lifetimes reduce such oscillations. Predictive scaling can anticipate demand but must account for forecast error. Reinforcement-learning controllers can learn policies for complex environments, yet they require safe exploration and careful reward design.

Admission control protects existing services from overload. It can reject, defer, degrade, or reroute a request. A useful decision evaluates the marginal resource demand and the probability that accepting the request will violate service-level objectives. In real-time systems, admission control may be based on schedulability tests; in cloud services, it may use capacity reservations, queueing models, or learned risk estimates. Graceful degradation is often preferable to binary rejection: a video analytics service might reduce resolution, sampling frequency, or model complexity when resources become scarce.

Autoscaling and admission control should be coordinated. Scaling without admission control can create runaway cost, while admission control without scaling can unnecessarily reject feasible demand. A controller should distinguish transient overload from structural undercapacity and should include stabilization mechanisms to prevent feedback loops.

Migration, Replication, and Workload Offloading

Migration transfers a workload from one execution location to another. Live migration attempts to maintain service continuity while state is transferred; cold migration stops the workload and restores it elsewhere. Migration can relieve overload, follow a mobile user, improve energy efficiency, or move computation closer to data. Its cost includes state-transfer bandwidth, CPU overhead, cache disruption, reconnection delay, and the risk of failure during transition.

Migration decisions should be based on expected net benefit rather than utilization alone. A simple criterion compares the predicted benefit of migration with its transfer cost and service risk. Migration is attractive when the destination provides sustained improvement, not merely a short-lived reduction in load. Stateful applications require special attention to consistency, session affinity, and in-flight transactions.

Replication improves availability and can reduce latency, but it consumes additional resources and creates consistency obligations. Strong consistency may increase coordination delay, whereas eventual consistency may be unsuitable for financial or safety-critical operations. Placement of replicas should account for correlated failures: replicas in the same rack, edge site, power domain, or network segment may not provide genuine independence.

Offloading is especially important for mobile and IoT devices. A device may execute locally, send a task to a nearby edge node, or transmit it to a regional or central cloud. The decision depends on device energy, computation time, communication delay, privacy, network reliability, and the size of input and output data. Offloading is not always beneficial: sending a small task over a congested wireless link may consume more energy and time than local execution. Partitionable applications can divide a workflow, retaining latency-sensitive or privacy-sensitive stages locally while exporting computationally intensive stages.

Federation and Inter-Domain Orchestration

Federation allows workloads to use resources belonging to multiple providers or administrative domains. It can increase capacity, improve geographic reach, and provide resilience against local failures. However, federation introduces trust, identity, accounting, policy translation, and interoperability problems.

A federated broker may select a provider based on price, latency, reputation, carbon intensity, or contractual guarantees. Provider selection can be modeled as a constrained optimization or negotiated through auctions and bilateral agreements. Game-theoretic mechanisms are useful when providers are self-interested and possess private information. A mechanism should seek incentive compatibility, resistance to manipulation, budget balance, and acceptable efficiency. These properties may conflict; no mechanism eliminates the need for governance and contractual enforcement.

Federated orchestration also requires common descriptions of capabilities, workload requirements, service-level objectives, and security properties. Without semantic interoperability, a broker may compare nominally similar resources that differ substantially in performance or trustworthiness. Cross-domain observability is similarly difficult because providers may expose only aggregated metrics.

Optimization, Heuristics, and Learning-Based Decisions

Optimization methods provide explicit models and interpretable constraints. Linear and integer programming are appropriate when costs and capacities can be represented accurately. Constraint programming is useful for complex logical restrictions. Metaheuristics such as genetic algorithms, particle swarm optimization, simulated annealing, and ant-colony methods can find good solutions in large search spaces, but their convergence and solution quality may be difficult to guarantee.

Heuristics are often preferred for operational control because they are fast and robust. Examples include best-fit placement, locality-aware greedy allocation, least-loaded selection, and migration triggered by predicted threshold violations. Their weakness is that performance may depend heavily on workload patterns and tuning assumptions.

Game-theoretic approaches model independent tenants, devices, or providers. Non-cooperative games can represent competition for scarce edge resources; cooperative games can allocate shared benefits or costs. A Nash equilibrium may be stable but inefficient, while a socially optimal allocation may require incentives. Researchers should distinguish mathematical equilibrium from operational desirability: an equilibrium can preserve self-interested behavior while delivering poor latency or energy performance.

Reinforcement learning frames orchestration as a Markov decision process with state, action, transition, and reward. The state may include utilization, queue lengths, topology, workload features, and policy context. Actions may include placement, scaling, routing, migration, or offloading. The reward should reflect service quality, cost, energy, reliability, and penalties for policy violations. Multi-agent reinforcement learning can coordinate distributed controllers, but non-stationarity and communication overhead complicate training.

The major risks of learning-based orchestration are unsafe exploration, distribution shift, reward misspecification, poor explainability, and vulnerability to manipulated telemetry. Safe approaches include offline training, simulation or digital twins, action shielding through hard constraints, conservative policy updates, human approval for high-impact actions, and continuous drift monitoring. A learned controller should be evaluated against strong heuristic and optimization baselines, not only against an unoptimized policy.

Practical Design Method

A disciplined orchestration design begins by defining service objectives in measurable form. “Low latency” should become a percentile bound, such as a maximum acceptable tail latency, while “high availability” should specify an availability target and recovery objective. Next, the architect models the workload graph, resource capabilities, dependencies, mobility, data sensitivity, and failure assumptions.

The third step is to identify decision timescales and authority boundaries. Fast local actions may be delegated to edge controllers, whereas federation and capacity planning may remain under a regional or central authority. Fourth, the architect chooses a decision method: exact optimization for small planning problems, heuristics for predictable operational reactions, or learning methods where repeated interaction and complex dynamics justify their additional risk.

The fifth step is to implement observation and feedback. Metrics should cover both infrastructure and user-visible outcomes. Sixth, the design must specify safeguards: quotas, admission limits, rollback, circuit breakers, migration budgets, and policy enforcement. Finally, the system should be tested under normal, peak, degraded, adversarial, and failure conditions. Evaluation should report not only average performance but also tail behavior, fairness, stability, decision overhead, and the cost of errors.

Illustrative Case: Federated Video Analytics for Urban Mobility

Background

Consider an illustrative municipal system that analyzes camera streams to estimate traffic density and detect incidents. Cameras are connected to neighborhood edge nodes, while a regional cloud stores historical data and trains models. The service has two classes: incident detection requires low latency, whereas periodic traffic forecasting can tolerate delay.

Situation and Problem

During a major event, camera activity increases sharply. Several edge nodes approach capacity, wireless links become congested, and a newly deployed model requires an accelerator unavailable at some sites. Sending all video to the regional cloud would exceed bandwidth and create unacceptable detection latency. The municipality also requires that raw video remain within a specified jurisdiction.

Analysis

The workload is represented as a service graph containing capture, filtering, object detection, event correlation, and archival stages. Filtering and initial detection are placed near cameras. Event correlation may run at a neighboring edge site or regional cloud. Raw video is prohibited from leaving the jurisdiction, while derived metadata may be shared with a federated provider. Admission control distinguishes emergency incident detection from lower-priority analytics.

A placement optimizer first applies hard constraints for jurisdiction, accelerator capability, and latency. A heuristic then selects among feasible sites using predicted queueing delay, link utilization, energy intensity, and migration cost. The system maintains replicas of the correlation service in separate power domains. During overload, it reduces sampling rates for forecasting but preserves the incident-detection path.

Approach and Solution

A hierarchical controller operates at three timescales. Local controllers perform rapid queue-based scaling and offloading among nearby nodes. A regional controller forecasts demand and provisions accelerator capacity. A federation broker obtains temporary capacity from an accredited provider for metadata processing. Admission control rejects nonessential batch jobs when the emergency class approaches its latency boundary. Migration is used only when predicted overload persists beyond the transfer break-even point.

The reward model for an experimental reinforcement-learning policy includes latency and energy terms, but a policy shield prevents actions that violate jurisdiction or minimum replica requirements. The production system initially uses the heuristic controller, while the learning policy is evaluated offline and in a digital-twin environment.

Outcome

The design preserves the low-latency service by prioritizing critical stages, reduces unnecessary backhaul traffic through local filtering, and avoids indiscriminate migration. It also demonstrates that intelligent orchestration is not equivalent to maximizing utilization: capacity is deliberately reserved for urgent events, and some lower-value work is degraded or rejected.

Learning Points

The case illustrates the importance of workload classification, hard policy constraints, multi-timescale control, service-graph placement, and conservative adoption of learning methods. It also shows why federation is valuable only when trust, capability descriptions, and data-sharing rules are explicit.

Challenges, Risks, and Limitations

Resource heterogeneity makes nominal capacity an unreliable indicator of performance. Two processors with the same advertised frequency may differ substantially for a particular model or instruction set. Telemetry may be delayed, incomplete, or manipulated. Controllers can oscillate when scaling and migration decisions react to one another. Prediction errors can cause either waste or violations of service objectives.

Multi-objective weights are often politically and organizationally contested. A low-carbon placement may increase latency; a fair allocation may reduce provider revenue; and a privacy-preserving design may limit analytical value. Researchers should report sensitivity to weights and examine Pareto frontiers rather than presenting one arbitrary composite score.

Learning systems introduce additional risks. Historical data may encode discriminatory allocation patterns. A reward that penalizes cost too strongly may systematically under-serve low-profit users or geographically remote communities. Autonomous migration may cross legal boundaries if policy metadata is incomplete. Explainability is particularly important when orchestration affects healthcare, transportation, emergency response, or other consequential services.

Security threats include resource exhaustion, malicious workload submission, poisoned telemetry, adversarial manipulation of placement signals, and unauthorized cross-tenant inference. Isolation, attestation, least privilege, signed policies, and audit logs should be integrated into orchestration rather than added after deployment.

Governance, Ethics, and Professional Responsibility

An orchestration platform is a socio-technical system. Its decisions distribute performance, cost, energy use, and access to scarce resources. Governance should define who may set objectives, alter weights, approve federation partners, override automated decisions, and investigate failures. Policies should be explicit, versioned, auditable, and testable.

Data minimization and purpose limitation are essential when telemetry includes location, user behavior, or sensitive content. Resource allocation should be assessed for disparate impact, especially where edge infrastructure is unevenly distributed. Environmental reporting should account for embodied infrastructure and workload shifting, not only instantaneous electricity use. Professional practice requires transparency about uncertainty, limitations, and the circumstances under which automation is unsafe.

Emerging Directions and Best Practices

Current research is moving toward intent-based orchestration, in which operators specify outcomes and constraints rather than low-level actions; digital twins for safe experimentation; carbon-aware scheduling that considers temporal and geographic energy variation; serverless and function-level placement; confidential computing; and semantic interoperability across federated domains. Edge intelligence is also becoming more adaptive, with models split across devices, edge nodes, and clouds.

Best practice is to combine explicit constraints with adaptive methods. Establish reliable telemetry, separate hard safety and compliance constraints from soft objectives, use hierarchical control for scalability, and retain rollback and human override capabilities. Evaluate tail latency, fairness, stability, energy, cost, and controller overhead together. Compare intelligent methods with transparent baselines, test under failures and distribution shifts, and make policy decisions auditable. Above all, treat orchestration as a closed-loop management problem whose quality depends as much on observability and governance as on the sophistication of its algorithm.

Chapter Summary

Resource management across the cloud–edge continuum coordinates heterogeneous, distributed, and often independently governed resources. Provisioning, scheduling, placement, autoscaling, admission control, migration, replication, federation, and offloading are interdependent decisions. Their formulation requires workload and infrastructure models, service objectives, hard constraints, and explicit treatment of competing goals such as latency, cost, energy, reliability, privacy, and fairness.

Centralized, hierarchical, and distributed control architectures offer different trade-offs in visibility, scalability, and autonomy. Exact optimization provides structure but may not scale; heuristics provide speed; game theory models strategic actors; and reinforcement learning can adapt to complex dynamics but requires safety controls and rigorous evaluation. Effective orchestration uses multi-timescale feedback, service-aware policies, robust telemetry, and governance mechanisms. Future systems will increasingly combine intent-based policies, digital twins, carbon awareness, confidential execution, and adaptive intelligence while preserving accountability and human oversight.

Key Terms

Resource management: Coordinating computational, storage, network, and energy resources to support workloads.

Orchestration: Automated deployment, configuration, coordination, scaling, and retirement of distributed workloads.

Provisioning: Making infrastructure capacity available for a workload or tenant.

Scheduling: Determining when tasks execute and how execution order is arranged.

Placement: Selecting infrastructure locations for workload components.

Offloading: Transferring computation from one device or tier to another.

Autoscaling: Dynamically changing allocated capacity in response to demand or policy.

Admission control: Deciding whether a request can be accepted without unacceptable impact on existing services.

Migration: Moving a workload or its state between execution locations.

Federation: Cooperation among independently administered infrastructure or service domains.

Service graph: A representation of service components and their communication dependencies.

Affinity: A placement preference that keeps related components together.

Anti-affinity: A placement rule that separates components to improve resilience or reduce interference.

Pareto optimality: A condition in which no objective can improve without worsening another objective.

Digital twin: A computational model used to represent and experiment with a physical or operational system.

Markov decision process: A formal model of sequential decisions using states, actions, transitions, and rewards.

Reward misspecification: Designing a learning objective that encourages unintended behavior.

Tail latency: A high-percentile response-time measure, such as the 95th or 99th percentile.

Policy shield: A mechanism that prevents an automated controller from taking prohibited or unsafe actions.

Resource fragmentation: Unusable capacity caused by the distribution or shape of remaining resources.

Review Questions

Short Answer Questions

1. Differentiate scheduling from placement in a cloud–edge environment.

2. Why can migration based only on current utilization be harmful?

3. What is the purpose of admission control?

4. Define Pareto optimality in resource management.

5. Identify two risks associated with reinforcement-learning orchestration.

Long Answer Questions

1. Explain how provisioning, autoscaling, admission control, and placement should be coordinated in a multi-tenant edge platform.

2. Compare centralized, hierarchical, and distributed orchestration architectures.

3. Discuss the principal trade-offs involved in computation offloading from mobile devices.

4. Explain how federation changes the technical and governance requirements of orchestration.

5. Critically compare optimization, heuristics, game-theoretic methods, and reinforcement learning for resource-management decisions.

Analytical / Application Questions

1. Design a placement strategy for a healthcare workload containing latency-sensitive inference, archival storage, and privacy-restricted patient data. State the hard constraints and soft objectives.

2. An edge service repeatedly scales up and down during fluctuating demand. Diagnose possible causes and propose a control design that reduces oscillation while preserving latency objectives.

3. Construct an evaluation plan for an intelligent orchestrator. Specify baseline methods, workload scenarios, metrics, failure conditions, and safeguards against unsafe learned actions.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes placement from scheduling?

A. Placement determines where a component runs, while scheduling determines when or in what order it runs.

B. Placement controls pricing, while scheduling controls data sovereignty.

C. Placement rejects requests, while scheduling encrypts workloads.

D. Placement is used only for storage, while scheduling is used only for networks.

Correct Answer: A. Placement determines where a component runs, while scheduling determines when or in what order it runs.

Question 2

Why should migration decisions consider a break-even point?

A. Migration is always free once a destination has capacity.

B. The sustained benefit must justify state-transfer cost, overhead, and service risk.

C. Migration eliminates the need for admission control.

D. The break-even point measures only processor utilization.

Correct Answer: B. The sustained benefit must justify state-transfer cost, overhead, and service risk.

Question 3

In a multi-objective placement problem, a Pareto-optimal solution is one that:

A. Maximizes every objective simultaneously.

B. Uses the greatest possible number of resources.

C. Cannot improve one objective without worsening at least one other objective.

D. Always minimizes monetary cost.

Correct Answer: C. Cannot improve one objective without worsening at least one other objective.

Question 4

Which action is most appropriate when an edge platform is overloaded but contains lower-priority analytics?

A. Reject all traffic regardless of priority.

B. Remove all replicas to reduce management overhead.

C. Apply graceful degradation or admission control to lower-priority work.

D. Disable telemetry so the controller cannot detect overload.

Correct Answer: C. Apply graceful degradation or admission control to lower-priority work.

Question 5

What is a major advantage of hierarchical orchestration?

A. It provides unlimited global visibility without coordination overhead.

B. It combines fast local decisions with broader regional or cloud coordination.

C. It eliminates all policy conflicts between providers.

D. It guarantees optimal placement for every workload.

Correct Answer: B. It combines fast local decisions with broader regional or cloud coordination.

Question 6

A reinforcement-learning orchestrator assigns excessive resources because its reward heavily penalizes latency but barely penalizes cost. This is an example of:

A. Anti-affinity.

B. Reward misspecification.

C. Strong consistency.

D. Static provisioning.

Correct Answer: B. Reward misspecification.

Question 7

Which condition is a hard placement constraint rather than a soft objective?

A. Reducing energy consumption when possible.

B. Minimizing provider cost.

C. Keeping raw data within a legally specified jurisdiction.

D. Improving average utilization.

Correct Answer: C. Keeping raw data within a legally specified jurisdiction.

Question 8

Why may local execution be preferable to offloading a small task?

A. Offloading never consumes bandwidth.

B. The communication delay and energy cost may exceed the cost of local computation.

C. Cloud processors cannot execute small tasks.

D. Local devices always have greater capacity than clouds.

Correct Answer: B. The communication delay and energy cost may exceed the cost of local computation.

Question 9

What is a principal concern in federated orchestration?

A. The absence of any need for identity or accounting.

B. Trust, policy translation, and interoperability across independent domains.

C. The impossibility of using geographic constraints.

D. The fact that federation always reduces resilience.

Correct Answer: B. Trust, policy translation, and interoperability across independent domains.

Question 10

Which evaluation practice is most suitable for a learned orchestration policy?

A. Compare it only with an unoptimized baseline under average load.

B. Evaluate it against strong baselines under normal, peak, failure, and distribution-shift conditions.

C. Allow unrestricted exploration directly in a safety-critical production system.

D. Measure only average CPU utilization.

Correct Answer: B. Evaluate it against strong baselines under normal, peak, failure, and distribution-shift conditions.