A network team must stream interface counters from 150 IOS XE switches to a gRPC collector every 30 seconds. Each sample must come from the switches' YANG models, be pushed by the switch itself, and resume on its own after a reload. Which telemetry subscription design meets all three requirements?
Select an answer to reveal the explanation.
Short Explanation
Once you save it, the switch streams on its own and starts again after a reload. A dynamic session dies with its Python client, RESTCONF polling makes your script the sender, and an applet skips the model data. It's like a mailbox the switch keeps emptying on a schedule.
Full Explanation
A model-driven telemetry subscription you configure on the switch is stored in the device configuration, so the periodic stream of the chosen sensor paths starts by itself and returns after a reload whenever that configuration has been saved. The device is the origin of every sample and the payload comes straight from YANG state containers, which is what makes the feed model-driven. A dynamic gRPC subscription delivers push data from the right models, but it exists only inside an open client session, so nothing restarts it when the switch reloads. RESTCONF polling reads the same YANG nodes and survives reboots, yet your script becomes the origin of each sample, so the flow is pull rather than push. The EEM applet is device-side and persistent, but it scrapes CLI output instead of model data, so the collector receives text no model defines. Exam caveat: the configuration must be saved to startup for the stream to return after power loss. Practical check: reload one switch and confirm the collector keeps receiving with every client session closed.