100-490 RSTECH common mistakes
100-490 RSTECH · Understand the traps and how to avoid them.
Applying the wrong subnet mask or prefix length when calculating host ranges, broadcast addresses, and available host counts, then choosing an answer that is off by two addresses.
Candidates memorize the 2^n-2 formula but forget that point-to-point links, /31 prefixes, and /32 host routes are exceptions, and they rush the binary conversion under exam time pressure.
What to do instead
Before answering any subnetting item, write the block size (256 minus the interesting octet value) and count from the network address. Explicitly check whether the item is a /31 or /32 before subtracting 2. Practice 20 subnetting problems in under 10 minutes until the block-size method is automatic.
Confusing administrative distance with metric when selecting between routes learned from different sources, or assuming the lowest metric always wins.
Both are numeric tie-breakers, and candidates conflate 'which protocol is preferred' with 'which path within a protocol is preferred'. They also forget that floating static routes work by raising administrative distance.
What to do instead
Build a two-step decision model: first compare administrative distance across sources, then compare metric only within the same protocol. Memorize the ordering connected (0), static (1), EIGRP (90), OSPF (110), RIP (120). Redo every route-selection question using that two-step check.
Predicting the wrong spanning-tree port state or root bridge after a topology change, or assuming all non-root ports forward immediately.
Candidates learn the state list but do not trace the root-port/designated-port election per segment, and they forget the role of port priority, path cost, and the tie-breakers (lowest bridge ID, lowest port ID).
What to do instead
For each STP item, draw the topology and elect the root bridge first (lowest priority, then lowest MAC). Then assign one root port per non-root switch (lowest cost to root) and one designated port per segment. Re-derive the answer from that drawing rather than from memory.
Misreading interface status and line protocol in show ip interface brief output, treating 'administratively down' the same as 'down' or assuming a physical up state means the link is usable.
The two-column status is easy to skim, and candidates do not connect 'administratively down' to a shutdown command, or 'up/down' to a Layer 2 mismatch, encapsulation problem, or missing clock rate.
What to do instead
Learn the pairs as a table: administratively down means the interface is shut; down/down means no cable or no carrier; up/down means Layer 2 mismatch or keepalive failure. When a question shows interface output, state the meaning of each column aloud before choosing.
Configuring a VLAN and access port but forgetting to create the trunk, allow the VLAN on the trunk, or set the native VLAN consistently, then blaming routing for the failure.
VLAN creation, port assignment, and trunk allowance are three separate steps, and the native VLAN mismatch is only reported as a CDP warning that candidates overlook.
What to do instead
Use a fixed checklist for every switched-path scenario: VLAN exists, access port assigned, trunk allows the VLAN, native VLAN matches on both ends, and SVI or router-on-a-stick subinterface has the right encapsulation. Verify with show vlan brief, show interfaces trunk, and show interfaces switchport.
Saving configuration to NVRAM only sometimes, or assuming changes survive a reload after configuring in a startup or lab session without copying running-config to startup-config.
The distinction between running-config and startup-config is conceptually simple but easy to drop under time pressure, and candidates confuse the two in output-based items.
What to do instead
Treat 'copy running-config startup-config' as the final step of every configuration task and check show startup-config to confirm. Remember that erase startup-config plus reload returns a device to its initial state, and that show running-config reflects unsaved changes.
Jumping to a conclusion from a single symptom instead of working a structured troubleshooting sequence, such as replacing a cable before checking the interface or blaming DNS before testing by IP address.
Exam items present a symptom and several plausible causes; candidates pick the first familiar cause rather than isolating the layer, and they skip the verification step that would confirm the fix.
What to do instead
Apply a bottom-up or top-down model explicitly: physical layer, then Layer 2, then Layer 3 addressing and routing, then upper-layer services. For each scenario, name the layer the symptom points to and the one command that would confirm or eliminate it before selecting an answer.
Misinterpreting ping and traceroute results, such as treating an asterisk in traceroute as a definite outage or assuming a failed ping always means the destination host is down.
Asterisks can come from ICMP rate limiting or filtering on intermediate hops, and ping failures can stem from ACLs, firewalls, or a missing default gateway rather than a dead host.
What to do instead
Interpret traceroute as hop-by-hop evidence: asterisks on middle hops with successful later hops mean filtering, not failure. For ping, test the default gateway first, then a remote address, then a name. Choose the answer that matches the first point of failure rather than the last symptom.
Confusing standard and extended ACL placement and direction, or forgetting the implicit deny any at the end of an ACL.
Standard ACLs filter on source only and belong near the destination; extended ACLs belong near the source. Candidates also forget that an ACL with no permit statement blocks all traffic, and that wildcard masks are inverted.
What to do instead
Memorize two rules: standard ACLs close to the destination, extended ACLs close to the source, and always end with an explicit permit or deny. Practice converting subnet masks to wildcard masks until it is automatic, and check interface direction (in or out) in every item.
Mixing up port security violation modes, DHCP snooping trusted ports, or the direction of dynamic ARP inspection, and choosing a mitigation that does not match the stated attack.
These Layer 2 security features share vocabulary (trusted, untrusted, violation) but act on different traffic, and candidates learn them as a list rather than as a sequence of what each feature protects against.
What to do instead
Map each feature to its attack: port security stops MAC flooding, DHCP snooping stops rogue DHCP servers, DAI stops ARP spoofing, and BPDU guard stops rogue switches. For each item, identify the attack first, then select the feature and its required trusted-port configuration.