200-301 CCNA practice questions: Automation and Programmability

Answer: C. Topic 6.1. Automation moves the unit of work from a device to a definition: the same rendered configuration reaches every target from one control host, so the differences that accumulate when 400 devices are edited by hand largely disappear, and because the file states what the devices are meant to look like, re-running it is at the same time a correction and a compliance report. What does not come with it is atomicity or self-healing on the device: a run iterates and reports per-device results, an unreachable switch fails its own task rather than blocking the rest, and nothing on the switch re-applies the definition by itself after a reload. Cisco frames the same idea for controller-based operations, describing intent APIs that provide policy-based abstraction of business intent, allowing an operator to focus on an outcome to achieve instead of struggling with the mechanisms that implement that outcome. What never changes is the engineer's responsibility for the content of the change. Source: Cisco 200-301 CCNA v1.1 Exam Topics - Section 6: Automation and Programmability

Answer: D. Topic 6.3.b. Cisco states that the intent API is a northbound REST API that exposes specific capabilities of the controller platform and that the RESTful intent API uses HTTPS verbs (GET, POST, PUT and DELETE) with JSON structures to discover and control the network. On the other side, a device package enables the controller to communicate with a device by encapsulating the southbound protocol used to communicate with it. The simple rule that survives the exam room: applications and orchestration systems live above the controller and talk to it northbound; switches, routers and access points live below it and are reached southbound. Source: Cisco 200-301 CCNA v1.1 Exam Topics - Section 6: Automation and Programmability

Answer: B. Topic 6.3. Cisco's VXLAN BGP EVPN design and implementation guide describes the distributed anycast gateway: a network shares the same gateway IP and the globally assigned gateway MAC address, and every VTEP is assigned the same MAC address for every Layer 2 VNI switched virtual interface. The guide then states the consequence for mobility: as the endpoint attachments to the network are moved from one VTEP to the other, the ARP entry for the gateway MAC does not need to be resolved again in the endpoint's ARP cache, as the gateway MAC and IP remain consistent across VTEPs provisioned with the same VLAN. The endpoint therefore sends to the same gateway address and the same gateway MAC after the move, and the leaf it now sits behind answers locally instead of forwarding to a distant gateway. The underlay's job in the same design is narrower: it advertises the reachability of the tunnel endpoints so that the encapsulated traffic can cross the fabric between them. Source: Cisco 200-301 CCNA v1.1 Exam Topics - Section 6: Automation and Programmability

Answer: B. Topic 6.6. Terraform is declarative: the configuration describes what should exist and the state file records what Terraform manages. HashiCorp's procedure for destroying a single resource is the sequence in the stem - delete the resource block from the configuration, delete any references to its attributes, run terraform apply - after which Terraform destroys the actual infrastructure resource and removes it from the state. To stop managing an object without destroying it, the block is replaced by a removed block: by default Terraform removes the resource from state and destroys the actual resource, and setting destroy to false removes it from state without destroying it, which HashiCorp describes as the way to hand management over to another tool or team. The habit this item tests comes from procedural tools, where a task deleted from a playbook simply stops running and the device keeps what it already has. Source: Cisco 200-301 CCNA v1.1 Exam Topics - Section 6: Automation and Programmability; destroy procedure verified at HashiCorp, 'Destroy a resource managed by Terraform' ('Delete the resource block from your configuration ... Run a terraform apply command'), https://developer.hashicorp.com/terraform/language/resources/destroy and removed block default at https://developer.hashicorp.com/terraform/language/block/removed

Answer: A. Topic 6.6. Check mode is Ansible's dry run, and the documentation separates two kinds of module. For one kind: 'Modules that support check mode report the changes they would have made.' For the other: 'Modules that do not support check mode report nothing and do nothing.' A task can leave the simulation, but only explicitly: 'To force a task to run in normal mode and make changes to the system, even when the playbook is called with --check, set check_mode: false.' This task sets no such keyword, so it neither changes the switches nor predicts a change, and the play continues with the next task. The practical consequence is that a silent task in a --check run is not evidence that the real run will leave the device untouched. Source: https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_checkmode.html Source: Ansible documentation, Playbook Guide, 'Validating tasks: check mode and diff mode' ('Modules that do not support check mode report nothing and do nothing.'), https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_checkmode.html