Study notes list dial-in and dial-out transport names from IOS XE model-driven telemetry docs. For a DEVCOR-style item on telemetry consumption and storage, what should remain the scored focus?
Select an answer to reveal the explanation.
Short Explanation
Know the bus routes (dial-in vs dial-out) just enough to board the right one—then focus on who listens, what you ask for, and how you keep it. Transport trivia is not the destination.
Full Explanation
For DEVCOR-style items on telemetry consumption and storage, the scored focus is how subscriptions are consumed and stored: receiver capability, YANG path selection, cadence versus on-change, and retention—using dial-in and dial-out transport names only to place subscription style. Study notes that list transport names from IOS XE docs should not displace that operational focus for civic fleets.
Writing a complete gNMI Subscribe RPC and gNOI service implementation from memory overscopes relative to consumption and storage design questions on this blueprint area. Memorizing every protobuf field in the dial-out encoding as the primary objective misses what the collector must do with the data after transport succeeds. Replacing all telemetry design with Expert-level transport internals as the “correct 5.1 answer” fails the blueprint emphasis on consumption and storage considerations operators actually use.
Exam caveat: know dial-in versus dial-out at a conceptual level, then spend study time on path, cadence, collector fit, and retention. Platform encoding details matter only insofar as the receiver must accept and decode them.
Operational check: for each civic use case, write four bullets—paths, cadence or on-change, receiver decode support, and retention—before debating transport brand names in design reviews.