Network Management, Telemetry and AI-Driven Analytics

Introduction and Context

Communication networks have evolved from relatively static collections of routers, switches, and transmission links into highly distributed software-controlled systems. Modern networks include cloud platforms, virtual network functions, programmable data planes, wireless access systems, edge nodes, industrial devices, and application-level service chains. Their operational complexity makes manual monitoring insufficient. Network management must now combine configuration control, performance measurement, fault diagnosis, security evidence, capacity planning, and automated remediation.

The traditional FCAPS model remains a useful organizing framework, but it must be supplemented by streaming telemetry, structured logs, flow records, distributed tracing, event correlation, and digital twins. Artificial intelligence and machine learning can extract patterns from these data sources, although their outputs require engineering validation, governance, and human oversight.

This chapter develops an integrated approach to network observability and intelligent operations. It explains how management protocols and telemetry systems work, how faults can be localized, how analytical models are constructed, and how autonomous operations can be designed without sacrificing reliability, explainability, or accountability.

Learning Objectives

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

1. Explain the FCAPS framework and relate it to modern network operations.

2. Compare SNMP, streaming telemetry, logs, flow records, and distributed traces.

3. Design an observability architecture using metrics, events, logs, and traces.

4. Apply correlation and dependency models to fault localization.

5. Explain the role of digital twins in network planning and operations.

6. Select suitable machine-learning methods for anomaly detection, forecasting, and optimization.

7. Evaluate model performance using technically appropriate metrics.

8. Identify risks involving bias, explainability, privacy, security, and unsafe automation.

9. Propose a reliable AI-assisted network-operations workflow.

1. Network Management as an Operational Discipline

Network management is the coordinated process of observing, controlling, maintaining, and improving a communication network. It includes both technical functions and organizational processes. A technically accurate alarm is not operationally useful if it cannot be assigned to an owner, related to a service impact, or resolved within an agreed time.

A useful management loop contains five activities:

• Observe: collect measurements, events, records, and context.
• Interpret: determine the state of devices, links, services, and users.
• Decide: select an action according to policy and risk.
• Act: change configuration, reroute traffic, replace equipment, or notify personnel.
• Learn: evaluate the result and improve models, policies, and procedures.

The control loop may be manual, decision-assisted, or autonomous. Greater automation reduces response time but increases the consequences of incorrect decisions. Therefore, automation should be introduced progressively, beginning with recommendations and low-risk actions before allowing closed-loop control.

2. FCAPS and Its Modern Interpretation

FCAPS, associated with the International Telecommunication Union’s network-management principles, groups management functions into Fault, Configuration, Accounting, Performance, and Security management.

2.1 Fault Management

Fault management detects, isolates, corrects, and records abnormal conditions. Examples include link failure, optical-power degradation, routing adjacency loss, packet corruption, excessive retransmissions, and service unavailability.

Fault management has three distinct questions:

1. Detection: Is there evidence that a fault or degradation exists?

2. Localization: Which component, path, or dependency is responsible?

3. Diagnosis and recovery: Why did it occur, and what action will restore service?

A single physical fault can generate many alarms. Alarm flooding is therefore a correlation problem rather than merely a collection problem. Suppression, deduplication, topology-aware correlation, and root-cause analysis are essential.

2.2 Configuration Management

Configuration management maintains an authoritative view of intended and actual device state. It includes inventory, version control, templates, compliance checking, change approval, backup, and rollback.

The distinction between intended state and observed state is central to software-defined networking. Drift occurs when the actual state differs from approved intent. Configuration systems should use transactional changes, pre-change validation, post-change verification, and controlled rollback. A configuration that is syntactically valid may still be unsafe because it creates routing loops, violates security policy, or exceeds device resources.

2.3 Accounting and Usage Management

Accounting records resource use for billing, cost allocation, capacity planning, and contractual verification. Records may include bytes, sessions, ports, virtual-network usage, cloud egress, or quality-of-service classes.

In modern networks, accounting is often implemented through flow telemetry, subscriber records, cloud billing feeds, and application-level usage data. Accuracy depends on clock synchronization, sampling policy, record completeness, and protection against duplicate or missing records.

2.4 Performance Management

Performance management measures whether the network delivers its intended service. Important metrics include throughput, delay, delay variation, loss, availability, utilization, queue occupancy, retransmission rate, and application response time.

Measurements must be interpreted in context. A link operating at 80% utilization may be healthy if capacity planning expects it, while a lightly utilized path may still have poor performance because of errors, congestion at another point, or excessive latency. Percentiles are often more informative than averages. For example, the 99th-percentile latency describes a user experience at the tail of the distribution that an average can conceal.

2.5 Security Management

Security management includes identity, authorization, vulnerability monitoring, policy enforcement, audit logging, intrusion detection, and incident response. Management-plane interfaces are particularly sensitive because compromise can provide control over many devices.

Security telemetry must be correlated with operational telemetry. A sudden configuration change, authentication failure, and route modification may represent an attack rather than an independent fault. Conversely, a security control may produce performance effects, such as increased latency caused by inspection or rate limiting.

3. Data Sources for Network Observability

Observability is the ability to infer the internal state of a system from its externally available outputs. Monitoring usually asks whether a known condition is present; observability also supports investigation of previously unknown failure modes.

3.1 SNMP

The Simple Network Management Protocol traditionally uses a manager-agent model. Managed objects are organized in a Management Information Base (MIB) and identified using object identifiers. A manager can poll counters and state variables, while agents may send notifications such as traps or informs.

SNMP is valuable because it is widely supported and simple to deploy. Interface octet counters, error counters, operational status, CPU load, and environmental measurements remain useful. However, polling introduces sampling delay, scales poorly at very high frequency, and may miss short-lived events. Counter discontinuities, device-specific MIB behavior, and inconsistent implementations also complicate analysis. SNMPv3 should be preferred where supported because it provides authentication and privacy mechanisms.

3.2 Streaming Telemetry

Streaming telemetry exports measurements continuously or when a condition changes. Common implementations use structured data models and protocols such as gNMI, often transported over secure channels. The device may push updates to a collector, reducing the delay and repeated request overhead associated with polling.

Streaming telemetry supports high-resolution measurements such as queue depth, interface counters, optical parameters, routing state, and hardware-resource utilization. It introduces its own requirements: collector scalability, timestamp quality, back-pressure handling, schema evolution, buffering during outages, and access control.

A telemetry design should specify:

• measurement names and semantic definitions;
• sampling or event-trigger policy;
• timestamps and clock source;
• retention and resolution;
• transport reliability;
• cardinality limits;
• ownership and data-quality checks.

3.3 Logs and Events

Logs are records of discrete observations, such as authentication events, interface transitions, software exceptions, route changes, and configuration commits. Structured logs with stable fields are much easier to correlate than free-text messages. A useful log normally includes event time, ingestion time, device identity, severity, event type, software version, correlation identifier, and relevant attributes.

Logs are not automatically evidence of causality. A message may be emitted after a symptom, may be duplicated, or may reflect a local consequence of a remote fault. Clock synchronization and event ordering are therefore important.

3.4 Flow Records

Flow records summarize conversations rather than storing every packet. Typical fields include source and destination addresses, ports, protocol, interface, timestamps, packet counts, and byte counts. NetFlow, IPFIX, and analogous systems support traffic engineering, capacity planning, anomaly investigation, and accounting.

Flow data provides broad visibility with lower storage cost than packet capture, but it lacks payload detail and may be sampled. Sampling changes the uncertainty of estimates and must be documented. Flow records are especially useful for identifying elephants, unexpected communication pairs, scanning behavior, and traffic shifts after a routing change.

3.5 Traces and Synthetic Measurements

Distributed tracing follows a transaction across services and network boundaries using spans and correlation identifiers. It helps distinguish network delay from application processing delay. Synthetic probes actively measure reachability, latency, loss, DNS resolution, HTTP response time, or path changes. They are valuable when passive data is incomplete and for validating service-level objectives.

4. Metrics, Service Objectives, and Data Quality

A metric is meaningful only when its semantics are clear. For example, “latency” must specify the endpoints, packet or transaction type, measurement method, and aggregation interval. Common service-level indicators (SLIs) include availability, successful request ratio, latency percentile, and packet-loss ratio. A service-level objective (SLO) defines the desired target over a stated period.

For an interval, an availability estimate may be written as

\[

A = \frac{T_s}{T_s+T_d},

\]

where \(T_s\) is the time the service is considered available and \(T_d\) is qualifying downtime. This expression assumes that the classification of available and unavailable time is defined consistently and that the observation interval is known. It does not by itself explain partial degradation or user-level impact.

An error budget is the amount of unreliability permitted by an SLO. If the target availability is 99.9% over a 30-day month of 43,200 minutes, the permitted downtime is

\[

43{,}200(1-0.999)=43.2\text{ minutes}.

\]

The value is a planning quantity, not a guarantee that every outage may safely consume the entire budget.

Data-quality dimensions include completeness, accuracy, timeliness, consistency, uniqueness, and validity. A sophisticated model trained on incomplete or delayed telemetry can be less useful than a simpler rule applied to reliable data.

5. Fault Localization and Root-Cause Analysis

Fault localization seeks to identify the smallest set of components or conditions that explains observed symptoms. It is harder than alarm detection because dependencies create many-to-many relationships between causes and effects.

A practical localization pipeline is:

1. Normalize events and measurements into common identities and timestamps.

2. Remove duplicates and apply maintenance-window context.

3. Group temporally related symptoms.

4. Map symptoms onto a physical, logical, and service dependency graph.

5. Rank candidate causes using topology, propagation direction, and evidence quality.

6. Test the leading hypothesis through additional measurements or controlled action.

Dependency graphs may include physical links, logical adjacencies, virtual tunnels, service chains, applications, and customer services. A link failure may explain interface-down events, routing changes, traffic shifts, and application latency simultaneously. A device reboot may instead be the primary cause, with link and routing alarms as consequences.

Correlation does not prove causation. Stronger evidence comes from temporal precedence, mechanism consistency, repeated observations, controlled experiments, and successful remediation. Probabilistic graphical models, Bayesian inference, causal graphs, and graph neural networks can assist ranking, but they must not obscure the operational evidence behind a recommendation.

6. Digital Twins for Network Operations

A digital twin is a computational representation of a physical or logical system that is connected to relevant data and used for analysis, prediction, or control. In networking, a twin may represent topology, configurations, device capabilities, traffic demands, routing policies, propagation delay, and failure states.

A useful twin has three layers:

• State representation: topology, configuration, inventory, and current measurements.
• Behavioral model: routing, queuing, protocol, resource, or service behavior.
• Experiment interface: tools for simulation, what-if analysis, validation, and comparison with observed behavior.

Digital twins support pre-change validation, capacity planning, failure simulation, maintenance scheduling, and training of operators. They are particularly valuable when real-world experimentation is risky.

A twin is not automatically correct. Model fidelity, parameter calibration, hidden dependencies, software-version differences, and inaccurate traffic assumptions can produce misleading results. The twin should be continuously compared with measured outcomes, and its assumptions should be visible to users.

7. AI and Machine Learning in Network Operations

Machine learning should be selected according to the operational question, not because a sophisticated algorithm is available. The main applications are anomaly detection, forecasting, classification, optimization, and automated control.

7.1 Anomaly Detection

An anomaly is an observation or sequence that differs materially from expected behavior. Methods include:

• threshold and rule-based detection;
• statistical baselines and control charts;
• clustering and density estimation;
• isolation forests;
• one-class support-vector methods;
• autoencoders and other representation-learning models;
• sequence models for temporal behavior.

A baseline must account for seasonality, topology, maintenance, software releases, and workload changes. An unusual value is not necessarily a fault; it may reflect a planned migration or a new but legitimate traffic pattern.

For binary detection, precision and recall are defined as

\[

\text{Precision}=\frac{TP}{TP+FP},\qquad

\text{Recall}=\frac{TP}{TP+FN},

\]

where TP, FP, and FN denote true positives, false positives, and false negatives. Precision measures the fraction of alerts that are correct, while recall measures the fraction of relevant incidents detected. In heavily imbalanced operational data, accuracy can be misleading because normal observations dominate.

7.2 Forecasting

Forecasting estimates future demand, utilization, latency, or failure risk. Methods range from moving averages and exponential smoothing to ARIMA models, state-space models, gradient-boosted trees, and neural sequence models.

Forecast evaluation must use time-ordered validation. Randomly mixing future observations into the training set causes leakage. Useful measures include mean absolute error (MAE), root mean square error (RMSE), and prediction-interval coverage. MAE is

\[

\text{MAE}=\frac{1}{n}\sum_{i=1}^{n}|y_i-\hat y_i|,

\]

where \(y_i\) is the observed value and \(\hat y_i\) is the forecast. It has the same units as the target and treats all absolute errors linearly. RMSE gives greater weight to large errors and is calculated as the square root of the mean squared error.

7.3 Optimization and Reinforcement Learning

Optimization can select routes, capacity upgrades, maintenance times, or energy-saving configurations subject to constraints. The objective may combine delay, loss, cost, resilience, and policy compliance. A mathematically attractive solution is unacceptable if it violates safety, contractual, or operational constraints.

Reinforcement learning can learn policies through interaction with an environment, but direct exploration in a production network is dangerous. A safer approach is offline learning, simulation in a validated digital twin, constrained action spaces, human approval, and gradual canary deployment.

7.4 Autonomous Operations

Closed-loop automation should include sensing, state estimation, policy evaluation, action validation, execution, and post-action verification. High-impact actions should require approval or multiple independent checks. Every automated decision needs an audit record containing the input data, model version, policy, action, authorization, and outcome.

8. Explainability, Bias, and Governance

Explainability is operationally important because engineers must determine whether a recommendation is plausible and safe. Explanations may be local, such as the features supporting one alert, or global, such as the overall behavior of a model. Feature importance, counterfactual explanations, partial-dependence analysis, and example-based explanations are useful, but they are not substitutes for causal proof.

Bias can enter through sensor placement, missing data, sampling, labeling practices, historical incidents, and unequal service visibility. For example, a model trained mainly on backbone telemetry may perform poorly for rural access networks or low-volume enterprise customers. Performance should therefore be evaluated across relevant regions, technologies, service classes, and operating conditions.

Governance should address:

• data ownership, privacy, retention, and access;
• model provenance and version control;
• reproducible training and validation;
• drift detection and retraining criteria;
• human authority to override automation;
• separation of duties;
• incident reporting and post-event review.

Network telemetry can contain identifiers, communication relationships, and sensitive operational details. Collection should follow purpose limitation, least privilege, encryption, retention controls, and applicable data-protection law. Security of the analytics platform itself is critical because poisoning, evasion, model theft, or compromised collectors can manipulate operational decisions.

9. Integrated Observability Architecture

A robust architecture normally contains the following logical layers:

1. Sources: devices, controllers, applications, probes, cloud platforms, and inventory systems.

2. Collection: SNMP, streaming telemetry, syslog, flow export, traces, APIs, and agents.

3. Transport and buffering: secure message buses, queues, time synchronization, and back-pressure control.

4. Normalization: common schemas, identity resolution, timestamp correction, unit conversion, and quality flags.

5. Storage: time-series databases, event stores, log platforms, flow repositories, and feature stores.

6. Analytics: rules, correlation, topology reasoning, statistical analysis, and machine learning.

7. Presentation and action: dashboards, incident platforms, ticketing, change systems, and controlled automation.

The architecture should avoid creating isolated monitoring silos. A service-centric view should connect a customer-facing SLO to applications, virtual functions, paths, devices, interfaces, and physical resources. Open data models and stable identifiers improve interoperability. Cardinality must be controlled: labels such as device, interface, region, service, and tenant can multiply the number of time series dramatically.

10. Illustrative Case: AI-Assisted Localization of Intermittent Service Degradation

Background

A fictional national communications provider operates an IP backbone connecting data centers and 5G aggregation sites. Customers report intermittent increases in application latency, but conventional availability alarms remain normal.

Problem

The operations center receives thousands of interface and routing events during peak periods. SNMP polling shows average utilization below 70%, while application traces show a sharp increase in the 99th-percentile response time. Engineers disagree about whether the problem is congestion, a faulty optical module, or an application defect.

Analysis

The provider integrates streaming queue-depth telemetry, interface error counters, flow records, distributed traces, route-change events, and a dependency graph. Data is aligned using synchronized timestamps. A baseline model represents normal queue behavior separately for weekday, weekend, and maintenance periods.

The anomaly detector identifies a recurring increase in queue occupancy on one class of egress queues, even though aggregate interface utilization is moderate. Flow records show a shift toward a small number of high-volume destinations. Optical telemetry reveals intermittent symbol errors on an upstream link. The dependency graph shows that traffic is rerouted when the link error rate crosses a threshold, concentrating selected flows on the affected egress queue.

Approach and Solution

The system ranks the optical link as the leading candidate because: (1) its error increase precedes route changes; (2) route changes precede queue growth; (3) queue growth coincides with tail-latency degradation; and (4) the pattern repeats across several intervals. The system recommends moving traffic to a protected path and dispatching a technician. A human operator approves the low-risk reroute after a digital-twin simulation confirms that the alternative path has sufficient capacity.

The optical module is replaced. Post-repair telemetry shows normal error levels, stable routing, reduced queue occupancy, and restored latency percentiles. The model is not retrained immediately on the incident without review; engineers first label the event, verify the causal chain, and determine whether the incident represents a new failure mode.

Outcome and Learning Points

The case demonstrates that aggregate utilization alone can conceal queue-specific congestion and that fault localization requires multiple data types. The AI model ranked evidence but did not independently assert causality. Human approval, simulation, audit records, and post-action verification reduced operational risk. It also illustrates the importance of event ordering, topology context, and tail-oriented service metrics.

11. Implementation Best Practices

Effective deployments generally follow these practices:

• Begin with operational questions and service objectives rather than available tools.
• Establish authoritative identity for devices, interfaces, services, tenants, and sites.
• Define metric semantics, units, timestamps, and quality flags.
• Combine push and pull collection according to use case and scale.
• Prefer structured, versioned schemas and maintain backward compatibility.
• Synchronize clocks and preserve both event time and ingestion time.
• Design alert policies around actionability, severity, ownership, and suppression.
• Use topology and service dependency graphs for correlation.
• Validate models using historical replay and time-ordered tests.
• Measure false-alert cost as well as detection performance.
• Separate recommendation from execution until confidence and safeguards are established.
• Maintain rollback, rate limits, change windows, and emergency disablement.
• Monitor model drift, data drift, and automation outcomes.
• Conduct post-incident reviews that improve data, models, and procedures.

12. Challenges and Contemporary Developments

Network management is increasingly affected by multi-cloud architectures, encrypted traffic, network slicing, edge computing, intent-based networking, programmable data planes, and rapidly changing virtual resources. Encryption reduces payload visibility, increasing reliance on metadata, endpoint measurements, and cooperative instrumentation. Edge environments create collection and privacy challenges because connectivity may be intermittent and resources constrained.

Large language models may assist with incident summarization, query generation, runbook retrieval, and natural-language interaction with operational data. They should not be treated as authoritative control systems without grounding, access controls, output validation, and auditability. Digital twins are becoming more capable through integration with configuration systems and real-time telemetry, but their value remains dependent on calibration and transparent assumptions.

Research continues on causal inference for root-cause analysis, federated learning across organizations, privacy-preserving telemetry, graph-based learning, uncertainty-aware automation, and formal verification of network changes. A central research challenge is converting predictive accuracy into trustworthy operational value under changing topology, incomplete observations, and asymmetric failure costs.

Chapter Summary

FCAPS provides a durable framework for fault, configuration, accounting, performance, and security management, but modern networks require a broader observability practice. SNMP remains useful for broad compatibility, while streaming telemetry provides lower-latency and higher-resolution measurements. Logs, flow records, traces, and synthetic probes contribute complementary evidence.

Reliable operations depend on clear metric semantics, synchronized time, data-quality controls, service-level objectives, and topology-aware correlation. Fault localization is stronger when temporal evidence and dependency graphs are combined, although correlation must not be confused with causation. Digital twins support safe experimentation, validation, and planning when their assumptions are calibrated against reality.

Machine learning can detect anomalies, forecast demand, rank causes, and optimize decisions. Appropriate validation, attention to class imbalance and time leakage, explainability, fairness, privacy, security, and human governance are essential. Autonomous operations should be introduced through constrained, auditable, reversible control loops. The most effective systems combine trustworthy data engineering, domain expertise, analytical models, and carefully governed automation.

Key Terms

FCAPS: Framework of Fault, Configuration, Accounting, Performance, and Security management.

SNMP: Protocol for monitoring and managing network devices through managed objects, polling, and notifications.

Streaming telemetry: Continuous or event-driven export of structured device and service measurements.

Observability: Ability to infer system state from externally available outputs.

Flow record: Summary of traffic exchanged between endpoints or network entities.

Distributed trace: Time-correlated record of a transaction across services and components.

Service-level indicator: Quantitative measure of a service property, such as latency or availability.

Service-level objective: Target value or range defined for an SLI over a stated period.

Error budget: Permitted unreliability implied by an SLO.

Fault localization: Process of identifying the component or condition responsible for symptoms.

Root-cause analysis: Investigation of the underlying cause rather than merely visible effects.

Digital twin: Connected computational representation used to analyze or control a real system.

Anomaly detection: Identification of observations that differ from expected behavior.

Precision: Fraction of positive alerts that are true positives.

Recall: Fraction of relevant positives detected by a method.

Model drift: Degradation caused by changes in data, behavior, topology, or operating conditions.

Closed-loop automation: Control process in which sensing, decision, action, and verification are linked.

Explainability: Ability to communicate why a model produced a particular output.

Telemetry cardinality: Number of distinct labeled measurement series generated by an observability system.

Review Questions

Short Answer Questions

1. What are the five FCAPS management functions?

2. State one important difference between SNMP polling and streaming telemetry.

3. Why are percentiles often more useful than averages for latency analysis?

4. Define precision and recall in anomaly detection.

5. What is the purpose of a digital twin in network operations?

Long Answer Questions

1. Explain how logs, metrics, flow records, traces, and topology data can be integrated for fault localization.

2. Discuss the strengths and limitations of SNMP and streaming telemetry in a large multi-domain network.

3. Describe an end-to-end architecture for AI-assisted network operations, including data quality and governance.

4. Explain how bias, privacy, explainability, and model drift affect the deployment of machine learning in network management.

5. Discuss the conditions under which closed-loop network automation should be permitted to execute actions without immediate human approval.

Analytical / Application Questions

1. A service has an SLO of 99.95% over a 30-day month of 43,200 minutes. Calculate its permitted downtime and explain why this value should not be interpreted as a required outage allowance.

2. An anomaly detector identifies 80 incidents, of which 60 are genuine; it misses 20 genuine incidents. Calculate precision and recall, and discuss which metric may be more important when every false alert consumes substantial engineering effort.

3. Design a fault-localization investigation for intermittent latency affecting one customer service. Specify the telemetry sources, dependency relationships, validation steps, and safeguards before applying an automated reroute.

Multiple Choice Questions with Answers

Question 1

Which FCAPS function is primarily concerned with maintaining intended and actual device state?

A. Fault management

B. Configuration management

C. Accounting management

D. Performance management

Correct Answer: B. Configuration management

Question 2

What is a principal advantage of streaming telemetry over conventional polling?

A. It eliminates the need for timestamps

B. It provides continuous or event-driven measurements with lower observation delay

C. It guarantees that all measurements are accurate

D. It requires no collector infrastructure

Correct Answer: B. It provides continuous or event-driven measurements with lower observation delay

Question 3

A detector produces 40 true positives and 10 false positives. What is its precision?

A. 40%

B. 50%

C. 80%

D. 90%

Correct Answer: C. 80%

Question 4

Which data source summarizes conversations using fields such as endpoints, ports, bytes, and timestamps?

A. Flow record

B. Distributed trace

C. Configuration template

D. Digital-twin state

Correct Answer: A. Flow record

Question 5

Why can aggregate link utilization fail to reveal a network performance problem?

A. Utilization is unrelated to traffic

B. Queue-specific congestion or errors may occur despite moderate aggregate utilization

C. Utilization can only be measured in wireless networks

D. Aggregate utilization always measures application latency directly

Correct Answer: B. Queue-specific congestion or errors may occur despite moderate aggregate utilization

Question 6

What is the main purpose of a digital twin in a network-management system?

A. To replace all physical network devices

B. To provide a computational representation for analysis and what-if experimentation

C. To encrypt every telemetry message

D. To guarantee correct machine-learning predictions

Correct Answer: B. To provide a computational representation for analysis and what-if experimentation

Question 7

Which validation practice is most appropriate for time-series forecasting?

A. Randomly shuffle all observations before splitting

B. Train on future observations and test on past observations

C. Use time-ordered validation that prevents future information leakage

D. Evaluate only on the training data

Correct Answer: C. Use time-ordered validation that prevents future information leakage

Question 8

What does recall measure in binary anomaly detection?

A. The fraction of alerts that are true positives

B. The fraction of relevant positive cases that are detected

C. The percentage of all observations classified correctly

D. The average time required to generate an alert

Correct Answer: B. The fraction of relevant positive cases that are detected

Question 9

Which control most directly reduces the risk of unsafe autonomous remediation?

A. Removing all audit records

B. Allowing unlimited action rates

C. Using constrained actions, approval for high-impact changes, and rollback mechanisms

D. Training only on normal traffic

Correct Answer: C. Using constrained actions, approval for high-impact changes, and rollback mechanisms

Question 10

Why is clock synchronization important when correlating network events?

A. It increases interface bandwidth

B. It helps establish the temporal order of symptoms and possible causes

C. It removes the need for topology data

D. It guarantees causal certainty

Correct Answer: B. It helps establish the temporal order of symptoms and possible causes