Implementation and Configuration
Configure to a standard, then prove it works
This domain rewards precision. The examiner is looking for whether you understand evaluation order and scope in device configuration.
Order of operations. ACLs and firewall rules match top-down and stop at the first match, with an implicit deny at the end. Therefore specific permits must precede broad denies. A rule that appears logically correct but is placed after a general deny blocks nothing. Likewise, NAT translation order (inside-to-outside before routing decisions), and routing preference (longest prefix match beats administrative distance beats metric) are frequent traps.
Common misconfigurations to recognize. Trunk native VLAN mismatch; DHCP clients on a remote subnet without a relay/helper address; DNS record types confused (A = IPv4 address, AAAA = IPv6, CNAME = alias, MX = mail with lower preference value preferred, PTR = reverse lookup); SNMPv1/v2c community strings sent in clear text; Telnet left enabled instead of SSH.
Hardening baseline. Rename or disable default accounts, disable unused switch ports, use AAA against RADIUS or TACACS+, synchronize time with NTP (logs without accurate time are unusable), forward logs to syslog, and back up the configuration before and after changes. Wireless: map SSIDs to VLANs deliberately, prefer WPA3 or WPA2-Enterprise over pre-shared keys.
Worked example
You must permit 10.1.1.50 to reach a server on port 443 while blocking the rest of 10.1.1.0/24. Place permit tcp host 10.1.1.50 host <server> eq 443 first, then deny ip 10.1.1.0 0.0.0.255 host <server>. Reversing the two lines makes the permit unreachable - the host is inside the blocked range.
Rule of thumb
Configure one change at a time, verify with a test from the correct source, and save the configuration. If you cannot state the rollback, you are not ready to implement.