Network Engineer exam: what is tested and how to prepare

The ground the questions stand on

• Route selection: longest prefix match, administrative distance and metrics, and how they interact.
• OSPF: areas, the backbone, neighbour relationships, cost, and the designated router on shared segments.
• Switching design: spanning tree root placement, EtherChannel, and the access, distribution and core layers.
• First-hop redundancy: HSRP and VRRP, and what hosts experience when the active gateway fails.
• Addressing plans: VLSM, route summarisation and IPv6 prefixes.
• WAN and remote sites: site-to-site IPsec VPNs, MPLS and SD-WAN concepts.
• Quality of service: why voice needs priority and how traffic is marked.
• BGP basics: what it is for, why providers depend on it, and the difference between internal and external sessions.

How a router really chooses a path

Many engineering questions come down to the order in which a router makes its decision, and getting that order wrong produces confident wrong answers. First, the most specific matching prefix wins, whatever protocol it came from. A /28 learned by RIP beats a /24 learned by OSPF for an address inside the /28. Only when two sources offer the same prefix does administrative distance decide, so a static route (1) beats OSPF (110). Within a single protocol, the lowest metric wins.

When a question gives you a routing table and a destination address, walk that sequence deliberately. Find every entry containing the address, keep the longest, and only then look at distance and metric if a tie remains.

Design questions with more than one workable answer

Design questions often offer several options that would function. The one to choose meets every requirement in the stem, not merely the one you use most at work. If the stem says a branch must stay connected when its main link fails, an answer without a second path is wrong however elegant it looks. If it mentions a tight budget, the most expensive redundant design is unlikely to be the intended answer.

List the requirements from the stem before reading the options, then test each option against that list.

VLSM and summarisation under time

Addressing a network of several sites with different sizes is a staple of engineering tests. Sort the requirements from largest to smallest, give each the smallest subnet that fits, and allocate them in order from the start of the block so the space stays contiguous. That order also makes summarisation possible, because neighbouring subnets can then be advertised as one shorter prefix.

Practise until you can write a VLSM plan for four or five segments in a few minutes, and check that no subnet overlaps the next.

Preparing effectively

Build and break things. A lab with three or four routers running OSPF, a pair of switches with HSRP, and an EtherChannel between them teaches more about failure behaviour than any amount of reading. Shut an interface and watch which path traffic takes, and work out why. Packet Tracer handles most of this; GNS3 or EVE-NG go further when you need real device images.

Alongside the lab, work through questions daily and log the routing and design mistakes you make. Engineering questions punish half-understood rules, and the log shows exactly which rules are still loose.