350-401 Automation Practice Question
A company has a large network of 500 Cisco IOS XE routers and switches spread across multiple sites. The network team wants to automate the collection of interface statistics every hour and store them in a central database for historical analysis. The team has a Linux server with Python 3 and access to all devices via SSH with key-based authentication. They have written a Python script using Netmiko to connect to each device, run 'show interfaces', and parse the output to extract key metrics (e.g., input/output errors, packets per second). The script works correctly when tested on a small subset of devices, but when run against all 500 devices, it takes too long (over 2 hours) and sometimes fails due to SSH connection timeouts. The team needs to reduce the execution time and improve reliability. Which approach should they take?
⚠ Common exam trap
Cisco often tests the misconception that switching protocols (SNMP) or tools (Ansible) automatically solves performance issues, when the real root cause is lack of concurrency in the execution model.
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
✓
Implement multiprocessing or multithreading in the Python script to connect to devices concurrently
The primary bottleneck is sequential SSH connections to 500 devices. By using Python's multiprocessing or multithreading (e.g., concurrent.futures.ThreadPoolExecutor), the script can open multiple SSH sessions in parallel, drastically reducing total wall-clock time. Netmiko itself is not the issue; the serial execution pattern causes the 2-hour runtime and timeouts, which concurrent connections resolve by overlapping I/O wait times.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Reduce the collection frequency to every 4 hours
Why it's wrong here
Lowering the collection interval to every 4 hours does not address the underlying cause of the timeout. The script still iterates through 500 devices sequentially within a single run, so the total execution time remains unchanged and will still exceed any fixed timeout threshold. This change merely reduces how often the problem occurs, not the problem itself, and could degrade monitoring granularity.
- ✓
Implement multiprocessing or multithreading in the Python script to connect to devices concurrently
Why this is correct
Implementing multiprocessing or multithreading allows the Python script to open SSH sessions to multiple routers simultaneously, dividing the 500-device workload across parallel workers. This dramatically reduces total wall-clock time, because network latency and device response delays overlap rather than accumulate. Using a ThreadPoolExecutor or multiprocessing pool with appropriate concurrency limits (e.g., 20-50 workers) can bring total runtime well under the timeout while preserving Netmiko's robust CLI interactions.
- ✗
Replace Netmiko with SNMP polling using the pysnmp library
Why it's wrong here
Switching to SNMP polling with pysnmp changes the data-collection paradigm entirely: SNMP requires every router to have an SNMP agent configured with community strings or credentials, and it can only return OIDs defined in MIBs, not arbitrary CLI output or show commands. While SNMP GETs are lightweight and could be parallelized, the missing metrics or the need to rewrite the entire collection logic makes this a non-trivial replacement that does not directly solve the existing timeout issue. It also adds operational overhead for SNMP configuration and security policy.
- ✗
Use Ansible playbooks instead of a custom Python script
Why it's wrong here
Ansible can parallelize device connections using the 'forks' parameter, but a default of 5 concurrent forks is often insufficient for 500 devices, and the control node's SSH connection handling can still hit timeout or performance bottlenecks. The playbook approach also shifts to a different automation framework, requiring inventory management and YAML task definitions, and does not inherently fix the root cause—the need for concurrent connections. If forks are not explicitly increased and connection timeout values not tuned, the same timeout behavior will persist.
Visual reference
Go deeper
Related to this question
About these practice questions
This 350-401 question is part of Courseiva's 1,923-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 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 350-401 exam.