Final Review and Exam Strategy

This is the final lesson, and it introduces no new networking content. Everything it refers to, you have already been taught. Its job is different: to help you aim what remains of your study. Most people's last two weeks are spent rereading the material they already like, which feels productive and moves the score very little. This lesson is a method for spending that time where it actually pays.

Four things follow. How to weight your review against the exam blueprint. How to find a weak area honestly, and what to do about each kind. How to read a configuration and isolate a fault under time pressure — the two practical skills the exam tests hardest. And how to behave in the exam room once the clock starts.

The exam is blueprint-weighted: each of the six domains contributes a fixed proportion of the questions. A blueprint weight is simply that proportion. It follows that an hour spent on a 25 percent domain is worth two and a half times an hour spent on a 10 percent domain — before you account for the fact that you are probably already better at the small one.

Two numbers dominate that table. Network Access and IP Connectivity together are 45 percent of the exam, and they are also the two most hands-on domains — the ones where questions show you a configuration or a topology rather than asking you to recall a definition. If your practice breakdown is weak there, that is where your first session goes, regardless of what you feel like studying.

A weak area is a domain where your accuracy is below your target, and the only reliable way to find one is a per-domain breakdown — your score split out by domain rather than reported as a single percentage. An overall score hides exactly the thing you need to see.

Consider a 90 percent overall that contains a 60 percent in a 20 percent-weight domain. It reads as ready. It is not: that one domain is quietly costing eight points of the total, which is the difference between a comfortable pass and a fail. Conversely, a 70 percent overall with no domain below 65 is a much healthier position, because it is short of the line evenly rather than broken in one place.

• Score by domain every time. If a practice tool reports only a total, it cannot tell you where to study next.
• Rank by weight × gap, not by gap alone. A 10-point gap in a 25 percent domain outranks a 15-point gap in a 10 percent domain.
• Distinguish a knowledge gap from a speed gap. Getting it right slowly and getting it wrong are different problems with different fixes.
• Retest the same domain after remediating it. An unmeasured repair is a guess.

Rereading notes end to end feels like studying and produces very little. Replace it with a loop that ends where it started, so each session is measured:

1. Diagnose. Take a practice exam or a domain drill and read the per-domain breakdown. The lowest weighted-adjusted domain names your target — you do not choose it, the data does.
2. Repair. Reopen that domain's anchor lessons from the table above and work its tool. Redo the worked examples until you can explain why the answer is the answer, not just what it is.
3. Retain. Close the session with a flashcard pass over that domain's vocabulary, so the repair survives to exam day rather than to Thursday.
4. Integrate. Periodically stop practising the topic in isolation and meet it in context, where a VLAN mistake breaks an OSPF adjacency and an access list breaks DHCP. A mixed-format exam and the Week 3 and Week 4 labs are where that happens in this course.
5. Retest. Re-run the same domain drill. If it moved, the loop worked and you pick a new target. If it did not, the repair was aimed at the wrong thing — usually a knowledge gap treated as a speed gap.

Repeat until every domain clears your target — not until the overall score does.

"Repair" is the step people get wrong, because four different actions all feel like studying and only one of them fits any given weakness. Match the symptom to the action:

A large share of the heaviest-weighted questions put a configuration or a piece of show output in front of you and ask one narrow thing about it. The mistake is to read the whole config. You do not have the time, and you do not need to.

1. Read the actual question first — usually the last line. "Which command is missing?" and "Why is the neighbour stuck?" send you to completely different parts of the same output.
2. Name the two or three lines that could possibly answer it before you start scanning. For an OSPF adjacency question, that is the network statements, the area, the interface addresses, and the timers — not the banner or the line vty configuration.
3. Scan for those lines only. Everything else on the page is there to cost you time.
4. Check the cheap disqualifiers first: is the interface shut down, is the mask a mismatch, is the VLAN in the allowed list, is there an access list on the path.
5. Commit. If you have found something that fully explains the symptom, that is the answer; do not keep reading for a second one.

The other practical skill is fault isolation, and there is one rule that does most of the work: check things in the order they depend on each other, from the bottom up. Higher-layer functions are built on lower-layer ones, so a break low down surfaces as a symptom high up. Dependency order simply means testing each layer only once everything it relies on is known good.

That gap between what is reported and what is broken has a name worth holding on to: symptom versus cause. The symptom is what the user or the show output tells you — no address, no route, no reachability. The cause is the thing that has to change for it to stop. They are frequently at different layers, and a question that asks for the cause will always offer the symptom as a tempting wrong answer.

Work upward and each stage narrows the next. Start in the middle and you can spend ten minutes proving a routing protocol is healthy while the real fault is a shut interface underneath it.

Two assessments follow this lesson, and confusing them is the fastest way to walk into the real exam with a false sense of readiness.

You face a fixed clock — roughly two hours — and roughly a hundred questions, and on the CCNA you generally cannot return to a question once you have moved past it. That single rule drives everything else.

• Work out your per-question time budget before you start — total time divided by question count, which lands at about a minute per question — and checkpoint yourself against the clock: roughly a quarter of the questions done at each quarter of the time. If you are behind, make up the difference on recall items, not on the hard ones.
• Never leave an answer blank. There is no penalty for a wrong answer, and you cannot come back, so a committed guess is strictly better than nothing.
• Do not overspend early. A simulation or a drag-and-drop item can swallow ten minutes. If it is not converging, give it your best committed answer and protect the many easy points still ahead of you.
• Read the last line of the question first. The actual ask is usually there — which command, what is the cause, which is the first step — and knowing it before you read the scenario tells you what to look for.
• Eliminate, then decide. Two options are usually clearly wrong; killing them turns a guess into a coin flip or better.
• Watch the qualifiers: best, most likely, first step, not. CCNA items frequently offer two correct-sounding answers where only one satisfies the qualifier.
• Trust prepared reflexes. On subnetting and route selection, compute once and commit — second-guessing a clean calculation costs time and usually changes a right answer into a wrong one.

• Aim by weight: IP Connectivity 25 percent, Network Access 20, Network Fundamentals 20, Security Fundamentals 15, IP Services 10, Automation 10.
• Find weak areas from a per-domain breakdown, and rank them by weight multiplied by gap.
• Match the remediation to the symptom: notes for a knowledge gap, a tool for a fluency gap, a repeated quiz for a reading gap, a lab or mixed exam for an integration gap, flashcards for a retention gap.
• Read the question before the configuration, scan only the lines that could answer it, and commit once you have an explanation that fits.
• Isolate faults upward in dependency order: physical and data link, Layer 2 topology, Layer 3 routing, services, then policy. The symptom is rarely the cause.
• The Week 10 Checkpoint diagnoses; the full practice exams rehearse. You need both, in that order.
• On the day: about a minute a question, never blank, do not overspend early, read the last line first, eliminate, respect qualifiers, commit.