A large enterprise polls 2,000 interfaces every 30 seconds via SNMP and now sees CPU spikes and delayed alarms for link flaps and BGP changes. The team wants timely event detection with lower steady-state load. Which model-driven telemetry publication choice addresses the network load impact?

On-change telemetry is correct because link state and BGP best-path are volatile, event-driven state where polling 2,000 interfaces every 30 seconds wastes CPU and bandwidth while still missing sub-interval flaps, whereas publishing only when the monitored leaf changes keeps steady-state quiet and delivers immediate notification when the event occurs. Periodic telemetry with extended intervals for stable counters is operationally sound for capacity planning and does lower overhead, but it fails the timeliness concept because cadence-based delivery still delays flap and BGP alarms until the next interval arrives. Device-initiated dial-out telemetry is a legitimate scaling practice to avoid collector-maintained sessions, but it fails the publication-timing concept because transport direction of initiation does not determine when updates are generated. On-change telemetry for stable inventory data is also valid design for serial numbers or configuration tracking, but it fails the data-class concept because applying event-driven push to rarely changing objects does nothing for the volatile operational state driving load and delay here. For exams, distinguish publication trigger from transport direction and match periodic collection to baseline trends versus on-change to volatile events. In practice, confirm YANG-push support on platforms, scope on-change subscriptions narrowly to flap and BGP leaves with dampening or flap filters, and compare subscriber CPU and alarm latency before and after to prove lower steady-state load with faster detection.