hardMultiple Choice
350-401 Practice Question: Writes an Ansible playbook to gather facts from a…
A network engineer writes an Ansible playbook to gather facts from a Cisco IOS device using the ios_facts module:
```yaml --- - name: Gather IOS Facts hosts: ios_devices gather_facts: no tasks: - name: Collect facts cisco.ios.ios_facts: gather_subset: - hardware register: device_facts
- name: Show serial number debug: msg: "Serial number is {{ device_facts['ansible_facts']['ansible_net_serialnum'] }}" ```
What is a potential issue with this playbook?
⚠ Common exam trap
Cisco often tests the requirement for 'connection: network_cli' and 'become: yes' in Ansible playbooks for network devices, as candidates frequently assume the default connection works for all hosts.
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
✓
The playbook is missing 'connection: network_cli' and 'become: yes' to enable network device access.
Ansible network modules like cisco.ios.ios_facts require the connection type to be set to 'network_cli' (or 'ansible.netcommon.network_cli') and privilege escalation with 'become: yes' to interact with network devices. Without these, the playbook will fail to connect to the Cisco IOS device, as the default 'smart' connection is designed for Linux hosts, not network gear.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The 'gather_subset' parameter is misspelled; it should be 'gather_subset' (correct spelling).
Why it's wrong here
The assertion that 'gather_subset' is misspelled is false; it is the correct Ansible keyword for the setup/gather_facts module. In Ansible, the 'gather_subset' parameter limits which subsets of facts are collected, and it accepts values like '!hardware' or 'all'. A true typo, such as 'gather_subsets' or 'gather_subsett', would be ignored by the module and cause a parameter error, not the fact collection issue at hand.
- ✓
The playbook is missing 'connection: network_cli' and 'become: yes' to enable network device access.
Why this is correct
Network modules require the playbook to set 'connection: network_cli' and 'become: yes' so Ansible can interact with the device's CLI over SSH with privilege escalation. Without 'network_cli', the default 'smart' connection attempts to use the general SSH connection, which does not handle device prompts, terminal length, or enable mode correctly. 'become: yes' is needed to enter privileged exec mode on most Cisco IOS/CSR devices, especially for commands like 'show serial number' or 'show version' that require enable privileges.
- ✗
The registered variable 'device_facts' should be accessed as 'device_facts.ansible_facts.ansible_net_serialnum' using dot notation.
Why it's wrong here
This option incorrectly claims dot notation is the only valid way to access the registered variable. In Jinja2 templating, both 'device_facts.ansible_facts.ansible_net_serialnum' and 'device_facts['ansible_facts']['ansible_net_serialnum']' are equivalent and work as expected. The choice between dot and bracket notation is stylistic and does not affect Ansible's ability to retrieve the value. The actual permissive nature of Jinja2 means either access method is valid, so this is not the playbook's problem.
- ✗
The 'hardware' subset is invalid; it should be 'all' to get serial number.
Why it's wrong here
The 'hardware' subset is a legitimate gather_subset value, and it deliberately includes serial number information via the 'ansible_net_serialnum' fact. The 'all' subset would collect every available fact, which is wasteful and slow for a single serial number lookup. In fact, using 'all' could even cause additional overhead or fail if some modules are unsupported, whereas 'hardware' is a focused subset. Therefore the claim that 'hardware' is invalid is factually incorrect.
Go deeper
Related to this question
Learn chapter
SDN Controllers and Cisco ACI
Key term
YAML for Network Config
YAML for Network Config is a human-readable data serialization language used to define, automate, and manage network device configurations in a structured text format.
Key term
REST API for Network Devices
A REST API for network devices is a set of rules that allows software applications to communicate with routers, switches, and firewalls using standard web methods like GET, POST, PUT, and DELETE over HTTP or HTTPS.
About these practice questions
Courseiva writes every 350-401 question from scratch — 1,923 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.