CCNA Automation common mistakes
CCNA Automation · Understand the traps and how to avoid them.
Assuming that because a topic is under 'Automation and Programmability', it is only about Python syntax, and skipping the data formats and API mechanics that most automation questions actually test. Candidates memorise `for` loops and `if` statements, then freeze on a question that shows a JSON object and asks which value a given key path returns, or that shows a YAML snippet and asks whether it is valid.
Candidates coming from a scripting background over-index on the language they already know, while candidates coming from a routing/switching background assume automation means 'write code' and deprioritise the whole domain. Both groups under-invest in the structural comparison of JSON, XML and YAML (brackets vs tags vs indentation, how each represents lists, strings, nulls and nesting) and in reading a REST response body.
What to do instead
Build a one-page comparison table of JSON, XML and YAML covering: how an object/mapping is delimited, how an array/list is delimited, how a string is quoted, how null/empty is written, and whether comments are allowed. Then practise reading five small payloads in each format and answering 'what is the value at this path' and 'is this syntactically valid'. Treat the domain as data literacy plus API mechanics plus a small amount of Python, not as a programming test.
Confusing the roles of northbound and southbound interfaces, and of the controller versus the device, when answering SDN architecture questions. A candidate will describe the controller as 'configuring the CLI of each device' or claim the southbound interface is where a script talks to the controller.
The terms are defined relative to the controller, not relative to the operator, and many candidates learn them as 'in' and 'out' without anchoring the reference point. Vendor marketing also blurs the line by bundling management portals with the controller.
What to do instead
Anchor the definition physically: draw the controller in the middle of a page. Everything above it (scripts, orchestration tools, the human, business applications) is northbound; everything below it (the network devices being programmed) is southbound. Then memorise that southbound protocols include NETCONF, RESTCONF, OpenFlow and gRPC/gNMI, while northbound is typically REST-based APIs. Re-derive the answer from the drawing on every practice question rather than recalling a label.
Treating configuration management tools as interchangeable and being unable to state what makes one declarative versus procedural, or push versus pull. A candidate picks 'Ansible' for every question mentioning automation, including questions where the scenario explicitly describes agents polling a central server.
Candidates memorise tool names from a list without attaching the two or three defining characteristics that distinguish them. Because all the tools 'automate configuration', the names feel like synonyms, and exam questions that hinge on architecture (agent-based vs agentless, push vs pull, declarative vs imperative) become coin flips.
What to do instead
Memorise a three-column table with one row per tool (Ansible, Puppet, Chef, SaltStack plus a generic controller-based SDN tool) and columns for agent requirement, push or pull, and declarative or imperative. Learn the single sentence that pins each one: for example, agentless and push for Ansible, agent-based and pull with a declarative manifest for Puppet. When a scenario mentions an installed agent or periodic convergence, that phrase should select the tool before you read the options.
Answering REST API questions by guessing HTTP verbs and status codes instead of deriving them. Candidates will say a configuration change uses GET because 'you are getting the device to change', or treat 200 and 201 as interchangeable, or assume a 404 means the server is down.
The verbs are English words with everyday meanings that conflict with their HTTP semantics, and status codes are learned as a vague block ('2xx good, 4xx bad') rather than as specific outcomes. Candidates also rarely practise mapping a described operation onto a verb–URL–status triple.
What to do instead
Drill the mapping until it is automatic: GET reads and is safe and idempotent; POST creates a subordinate resource and is neither safe nor idempotent; PUT replaces a resource at a known URL and is idempotent; PATCH partially modifies; DELETE removes and is idempotent. Then learn the codes you will actually see: 200 success with body, 201 created, 204 success with no body, 400 malformed request, 401 unauthenticated, 403 authenticated but not permitted, 404 resource not found, 500 server error. For each practice scenario, write the verb, the URL and the expected status before looking at the options.
Reading a Python or pseudocode snippet and predicting what it prints by skimming, without tracking variable state line by line. Candidates assume a list is modified in place when it is reassigned, miss that a loop variable is reused, or assume a function mutates its argument when it returns a new value.
Under time pressure, candidates pattern-match on familiar keywords rather than simulating execution. The most common technical trap is the difference between rebinding a name and mutating the object it points to, plus off-by-one errors in slicing and range boundaries.
What to do instead
On any code question, physically annotate the snippet: write the value of each variable after each line, and mark the boundary values of every range or slice (does it include the end index?). For anything involving a function call, write the argument value going in and the returned value coming out. If the snippet involves a list passed to a function, explicitly ask 'was the list mutated, or was a new list returned and assigned?' before choosing.
Confusing the management-plane access methods and their ports and security properties when answering questions about how a device is configured or monitored. Candidates mix up NETCONF over SSH with RESTCONF over HTTPS, or assume SNMP is a configuration protocol because it can write values.
The protocols overlap in purpose, several run over the same transport, and the port numbers (22, 830, 443, 161/162) are learned as an undifferentiated list. SNMP's SET operation makes it look like a configuration tool even though it is designed for monitoring.
What to do instead
Build a table with columns for transport, default port, encoding (XML, JSON, YANG-modelled data, BER), and intended purpose. Fix the key facts: NETCONF uses SSH on TCP 830 and XML; RESTCONF uses HTTPS on 443 and JSON or XML; SNMP uses UDP 161 for queries and 162 for traps and is primarily monitoring. Then note which ones are candidate replacements for the CLI and which are read-mostly telemetry.
Assuming a controller-based or intent-based network removes the need to understand the underlying forwarding and routing behaviour. Candidates answer 'the controller handles it' for questions that ask what path traffic will take, or they cannot explain why an underlay must be configured before an overlay works.
The automation narrative suggests abstraction replaces fundamentals, so candidates deprioritise routing and switching while studying. In reality, exam questions frequently combine domains - for example, asking how a change pushed by automation affects STP, VLAN membership or a routing adjacency.
What to do instead
Study automation as a layer on top of the fundamentals, not a replacement. For every automation concept you learn, ask 'what is it actually changing on the device?' A VLAN push changes switchport configuration and VLAN databases; a routing change affects adjacencies and the routing table. Practise cross-domain questions that require you to trace a configuration change through to its forwarding effect.
Misreading subnet and wildcard-mask questions by applying the subnet mask where a wildcard mask is required, or by miscounting the number of usable hosts. A candidate will see an ACL or OSPF statement with 0.0.0.255 and interpret it as a /24 subnet mask.
Subnet masks and wildcard masks are bitwise inverses, and both appear in the same kinds of configuration lines. Candidates learn the mask notation first and then read wildcard masks with the same reflex. The usable-host off-by-two (network and broadcast addresses) is a second, independent slip.
What to do instead
Before computing, identify which mask type the question uses: if the value appears in an ACL, OSPF network statement or route-map match, it is almost certainly a wildcard. Convert deliberately: invert each octet (255 minus the value) to get the equivalent subnet mask, or invert the mask to get the wildcard. For host counts, always subtract two for a standard subnet and state explicitly whether the question is asking for addresses or usable hosts.
Treating VLAN configuration as complete once the VLAN is created and ports are assigned, without verifying trunk allowance and native VLAN consistency. Candidates troubleshoot an inter-switch connectivity problem by re-checking access-port assignments instead of the trunk's allowed VLAN list and encapsulation.
The access-port configuration is the visible, intuitive part of VLANs, so candidates stop there. The trunk carries the traffic, and its allowed list, native VLAN and encapsulation type are the usual causes of a VLAN that exists on both switches but does not pass traffic.
What to do instead
Adopt a fixed verification order for any VLAN reachability question: (1) does the VLAN exist in the VLAN database on both switches, (2) is the access port assigned to it, (3) is the uplink a trunk with matching encapsulation, (4) is the VLAN in the allowed list on both ends, (5) do native VLANs match, (6) does the router or switch virtual interface have the correct gateway. Walk that list rather than guessing at the most familiar command.
Confusing first-hop redundancy protocols and their roles - treating HSRP, VRRP and GLBP as interchangeable, or assuming a redundancy protocol provides load balancing when it only provides failover. Candidates also mix up the virtual MAC address conventions and the meaning of preemption.
The three protocols solve the same problem with similar terminology, and the differences that exam questions test (vendor ownership, standards status, load-sharing behaviour, default priority and preemption behaviour) are exactly the details that are easy to skim.
What to do instead
Learn one distinguishing sentence per protocol: HSRP is Cisco-proprietary with an active/standby pair and preemption disabled by default; VRRP is the open standard with a master/backup pair and preemption enabled by default; GLBP is Cisco-proprietary and can load-share across multiple forwarders. Add the virtual MAC conventions and the default priority values. When a question mentions load sharing across gateways, that word alone should point to GLBP.