200-901 Infrastructure and Automation Practice Question
An automation team wants to build a custom Slack bot that receives a message when a Cisco IOS XE device sends a syslog event indicating an interface went down. Which combination of technologies should the team use to implement this event-driven workflow?
⚠ Common exam trap
The trap here is choosing a polling method because it feels simpler, when the scenario explicitly requires reacting to an event as it happens.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure the device to send syslog to a collector, and have the collector trigger a webhook to the Slack API.
Syslog is inherently push-based, so configuring the device to send events to a collector is the most direct way to detect an interface-down event. The collector can then invoke the Slack API webhook, creating an event-driven pipeline. Polling approaches add latency and may miss transient events.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Ansible to run a playbook on a schedule that checks interface status and posts to Slack.
Why it's wrong here
A scheduled Ansible playbook is still polling, just at a different layer. It introduces delay between the event and the notification and does not scale well across many devices. The scenario asks for an event-driven workflow, which scheduled checks do not provide.
- ✓
Configure the device to send syslog to a collector, and have the collector trigger a webhook to the Slack API.
Why this is correct
Syslog is a push mechanism, so the device sends events to a collector without polling. The collector can parse the message and call the Slack API webhook to notify the bot. This is a standard event-driven pattern that matches the requirement for near real-time notification.
- ✗
Subscribe to model-driven telemetry on the device and have the bot pull data from the telemetry receiver.
Why it's wrong here
Model-driven telemetry is a valid push technology, but the scenario specifically describes syslog events. Introducing telemetry changes the data source and adds complexity not requested. The bot would also need to pull from the receiver rather than receive an event, which is not the described workflow.
- ✗
Poll the device every minute with NETCONF get_config to detect interface state changes, then call the Slack API.
Why it's wrong here
Polling with get_config is inefficient and may miss brief interface flaps between intervals. It also retrieves configuration rather than operational state; interface up/down is state data. This approach adds latency and load without guaranteeing detection of the event.
About these practice questions
One of 975 original 200-901 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.