A civic status board needs DNA Center wireless health, Intersight inventory, Webex ChatOps events, and Meraki location observations. How should collection style be matched to each platform?
Select an answer to reveal the explanation.
Short Explanation
Some trucks deliver on a schedule; others knock when something happens. DNA and Intersight are pull-on-a-timer; Webex ChatOps and Meraki location arrive as POSTs—match the style, don’t invent the opposite.
Full Explanation
Collection style must match how each Cisco platform exposes data. DNA Center wireless health and Intersight inventory are typically retrieved on a timer—pull when the civic board needs a refresh. Webex ChatOps events and Meraki location observations arrive as POSTs to your application URL—push when something happens. Matching pull versus push to those families is the construction skill: timers for health and inventory retrieves, webhook endpoints for ChatOps and location.
Polling Webex message events every second while waiting for Intersight to push PhysicalSummaries to a public URL reverses both models: ChatOps is event-driven POST territory, and Intersight inventory is a retrieve you schedule, not a public push you hope arrives. Using only webhooks for DNA wireless health and only timers for Meraki location POSTs flips the natural patterns—DNA health is polled; Meraki location posts into your URL. Requiring every platform to stream MQTT so the dashboard never uses REST or webhooks invents a transport the objective does not demand and ignores the REST/webhook paths these products actually document.
Exam caveat: you are graded on matching retrieve-on-timer versus accept-POST per platform family, not on inventing a single transport for everything. Operational check: verify DNA and Intersight jobs run on an interval against authenticated retrieve endpoints, and confirm Webex and Meraki location hit HTTPS POST handlers on the app URL with payloads that update the status board.