Start with the exam you are preparing for
The CCNA Certification Exam is a timed, computer-based exam. It uses a mixture of multiple-choice and multiple-response questions, drag-and-drop tasks, and simulation or lab-style questions. Some questions ask you to interpret command output, select the next troubleshooting step, or correct a configuration rather than recall an isolated definition.
The current exam details, including registration information, the official topic outline and any changes to the format, should be checked on Cisco's official certification website before you plan your final week. Do not build your preparation around a question count or pass mark taken from an unofficial source.
A useful CCNA preparation method has four parts:
- Build a board from reliable notes and configuration examples.
- Reduce each topic to facts and decisions you can retrieve quickly.
- Practise questions that make you use outputs, constraints and commands.
- Review errors by cause, then repeat the task in a small lab.
The aim is not to memorise command strings without understanding them. You need to know what a command is intended to change, what evidence supports using it, and how to verify that it worked.
What the CCNA tests in practice
Organise your material around the broad areas named in the exam description:
- Networking fundamentals: models, Ethernet behaviour, switching concepts, IPv4 and IPv6 addressing, wireless concepts and cabling.
- IP connectivity and services: routing decisions, static routes, VLANs, trunks, inter-VLAN routing, DHCP, DNS, NTP and related services.
- Security fundamentals: device access, passwords, secure management, access control, common threats and least-privilege decisions.
- Automation and programmability: controller-based networking, APIs, data formats and the operational difference between traditional and software-defined approaches.
- Operational tasks: interpreting show commands, identifying likely causes, making a controlled change and verifying the result.
Do not study these as five sealed subjects. A scenario may combine VLANs, trunking, an IP address, a default gateway and an access-control decision. Your board should show those connections.
Build a board from your own material
Start by importing your course notes, slides, lab instructions and reliable reference material. If you use photographs of handwritten notes, check the extracted text carefully: a misread subnet mask or command option can create several false flashcards.
Divide the board into sections that reflect decisions you must make, not just chapter titles. For example, “selecting a route” is more useful than a section called “routing chapter”. Keep configuration examples beside the reason for using them and the command used to verify them.
A board on this topic ends up looking like this:
| Prefix | Usable hosts | Typical point-to-point use |
|---|---|---|
| /24 | 254 | Large LAN |
| /30 | 2 | Traditional IPv4 router link |
| /31 | 2 addresses, no network/broadcast pair | Point-to-point where supported |
Use show ip interface brief, show interfaces status, show vlan brief, show interfaces trunk and show ip route to narrow the fault before changing configuration.
- Longest prefix match is considered first.
- If prefix lengths are equal, lower administrative distance is preferred.
- Within the same protocol, lower metric is preferred.
- Prefer SSH to Telnet for remote management.
- Use local authentication or a defined central method, with privilege limited to the task.
- Verify the management path before saving a change.
- Access ports carry one VLAN for end devices.
- 802.1Q trunks carry multiple VLANs and use a native VLAN.
- A native-VLAN mismatch can produce warnings and unexpected traffic handling.
The important feature is the relationship between a fact and an action. “Longest prefix match” should lead to a route-selection exercise. “Trunks carry multiple VLANs” should lead to a task where you inspect allowed VLANs, native VLANs and the operational trunk state.
Make a short core checklist
After your first pass, cut the board down to the facts that must be available under time pressure. Include values, ordering rules and command purposes. Leave longer explanations on the board, but do not force yourself to reread them every time.
A useful core list includes the subnetting process, route-selection order, VLAN and trunk behaviour, common verification commands, IPv6 address types, DHCP roles, basic device hardening and the distinction between control-plane concepts and forwarding behaviour.
The core for this board might look like this:
Read the core aloud and test whether you can explain each item with a small example. For subnetting, do not stop at calculating the number of hosts. Practise identifying the network address, broadcast address, usable range and whether two addresses belong to the same subnet.
Practise the commands as decisions
CLI literacy means more than recognising syntax. Given a problem, decide what you need to know first. If an interface is reported as unreachable, begin with status and addressing evidence rather than immediately applying a configuration command.
For a small fault, a sensible sequence may be:
- Confirm the scope: one host, one VLAN, one link or several networks.
- Check interface state and addressing with
show ip interface brief. - Check VLAN membership and trunk state where switching is involved.
- Check the routing table and relevant next hop.
- Inspect access-control or management settings only after the path is understood.
- Make the smallest justified change.
- Verify with the same test that showed the fault, plus a relevant show command.
A scenario that gives you a route table is testing more than whether you know a command. It is testing whether you apply longest-prefix matching correctly and avoid choosing a route merely because it has a familiar next hop. A scenario showing an interface as administratively down is testing whether you distinguish an administrative state from a physical or protocol failure.
Use marked papers to expose reasoning gaps
Once your board and core exist, complete timed mixed papers. Include enough lab-style work that you have to interpret output and choose a configuration intent. If you only answer definition questions, you will not practise the most important transition: from evidence to action.
In your review, label every lost mark. Useful labels are “misread output”, “subnetting arithmetic”, “protocol behaviour”, “wrong command intent”, “security choice”, “rushed selection” and “failed to verify”. A wrong answer caused by a misread mask needs a different remedy from a wrong answer caused by not knowing what a trunk does.
A marked paper on this board might return like this:
A router has 10.20.0.0/16 and 10.20.32.0/19 routes in its table. It receives traffic for 10.20.40.12. Which route is selected, and why?
3/4The 10.20.0.0/16 route is selected because it is the larger network and covers the address. I would then forward it to that route's next hop.
You identified that both routes cover 10.20.40.12, but selected the less specific route. Route selection starts with the longest prefix match, before administrative distance or metric are considered.
Missed
−10.20.32.0/19 is more specific than 10.20.0.0/16 and is therefore selected.
−State the forwarding interface or next hop only after selecting the route.
Model answerBoth routes cover 10.20.40.12, but 10.20.32.0/19 is selected because /19 is a longer prefix than /16. The router then uses the selected route's next hop or exit interface. If several routes have the same prefix length, administrative distance and then the protocol metric become relevant.
That is a MySummaries paper, filled with CCNA material. Yours is written from your own notes. Start free
The review is more useful than the percentage. Turn repeated misses into a short remediation task. For example, draw three overlapping prefixes, identify the selected route, and explain why the other two lose. Then repeat the task later without looking at the solution.
Do not treat a lab as complete because the configuration was accepted. Check the operational state and the user outcome. For a VLAN problem, inspect the VLAN and trunk, check the endpoint's gateway and test connectivity. For a routing problem, inspect the route table and test the relevant destination. If a security change is involved, consider whether you have locked yourself out and whether a rollback path exists.
Use audio for consolidation, not first exposure
A short spoken explanation is useful after you have attempted the material. Listen while walking through a lab topology, then pause and predict the next command or result. If the explanation simply repeats definitions, replace it with a scenario: a missing route, a mismatched trunk, a failed DHCP request or an unsafe management configuration.
A lecture generated from the board should have a narrow angle. “All of networking” is too broad for one sitting. “How to diagnose a host that cannot reach a remote subnet” gives you a sequence to recall and test.
A focused lecture from this board might be structured like this:
Transcript · tap any word to jump there
Start with the symptom, not the command you happen to remember. If one host cannot reach a remote subnet, first establish whether the failure is local to the host, the access VLAN, the default gateway or the routed path. The scope of the failure is evidence: one host suggests a different set of causes from every host in the VLAN.
Next, inspect the interface and VLAN state. An interface can be physically connected but assigned to the wrong VLAN, or a trunk can be operational while the required VLAN is not allowed across it. Use the relevant show commands and compare the result with the intended topology rather than changing several settings at once.
Once the local path is sound, inspect the routing table. Apply longest-prefix matching to the destination, then consider administrative distance and metric only when the prefix lengths are equal. After the smallest justified change, repeat the original connectivity test and verify the changed state. A fix that has not been tested is only a hypothesis.
Before exam day, practise explaining each troubleshooting case in this order: goal and constraints, topology and assumptions, evidence, diagnosis, fix, then verification and rollback. This structure prevents you from jumping to a command before establishing what problem it is meant to solve.
A workable final revision cycle
In the last part of preparation, rotate activities rather than spending every session rereading notes:
- Session one: timed subnetting and route-selection questions.
- Session two: a short switching or routing lab, including verification.
- Session three: security and services questions, with attention to least privilege and secure management.
- Session four: a mixed paper under timed conditions.
- Session five: remediation of the two weakest sections, followed by a second attempt at the missed tasks.
Keep a final list of traps that are specific to you: confusing administrative distance with metric, forgetting the effect of a native VLAN, treating an interface as up merely because it has an address, or selecting a broad route when a more specific one exists. Read this list briefly, but spend most of the time proving the points in questions and labs.
How MySummaries helps
MySummaries lets you build a CCNA revision board from your own notes, slides and photographed material, then turn that board into spaced-repetition cards, marked written papers and focused audio lectures. For this task, use the board for command purpose and protocol behaviour, the cards for values and ordering rules, marked papers for output-based reasoning, and the lectures for concise troubleshooting walkthroughs. You can start at portal.mysummaries.app.