5.3Reading automation workflows

The exam asks not "what is Ansible" but what the playbook or script in front of you actually does. Even if you cannot write code, if you cannot read it you can neither review nor troubleshoot. This section reads three kinds—Ansible playbook, Python, and bash—from their elements (targets, modules, loops, conditions), so you can judge whether it is idempotent config delivery, information gathering, or backup, and whether a dangerous operation is mixed in.

5.3.1Reading an Ansible playbook

• A playbook's skeleton is hosts: (target group) -> tasks: (work run in order). Each task's module name decides what it does: ios_config = push configuration, ios_command = run a command and capture output, ios_facts = gather device info. name: is a descriptive label, so reading the module name first is the key.
• If ios_config has backup: yes, the intent is to back up the current config before applying the change. A loop: or with_items: means repeating the same work over multiple VLANs/IFs/devices. Many modules are idempotent, reporting changed: false and not double-applying when the desired state already holds.
• when: is conditional execution (e.g., when: ansible_net_version is version('17.3', '<') applies only to older IOS-XE). Read for dangerous operations too: an unconditional save_when: always or a device reload includes an irreversible/high-impact write or reboot, deserving special scrutiny in review.