A regional planning commission needs a local, sub-second reaction on one router when a tracked object fails, while still using off-box controllers for fleet-wide template changes. How should those tools be split?
Select an answer to reveal the explanation.
Short Explanation
EEM is the firefighter in the station—fast when the local alarm trips. Controllers are the regional dispatch that rolls out policy to every site. Use both for what they are good at instead of photocopying applets across the fleet or waiting for tonight’s batch to save a link.
Full Explanation
Regional planning needing a local sub-second reaction on one router when a tracked object fails, while still using off-box controllers for fleet-wide template changes, should split tools: on-box EEM for the local fast reaction and controller/API automation for coordinated fleet changes. Local events and fleet intent operate on different timescales and blast radii. That split is the sound architectural answer.
Replacing all controllers with EEM applets duplicated manually on every router does not scale fleet policy. Using only overnight Ansible batches for both local failover and region-wide policy is too slow for sub-second local reaction. Disabling EEM because local automation always conflicts with NETCONF invents a false mutual exclusion.
Exam caveat: keep EEM actions narrow and reversible so they do not fight controller reconciliation loops. Operational check: implement a tracked-object EEM on a lab router proving sub-second notify/metric change, and separately apply a controller template change; document ownership boundaries in the planning commission automation RACI. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.