CCNA Study Plan: A Practical Six-Week Revision Method

What the CCNA requires you to practise

The CCNA Certification Exam is a timed, computer-based exam. It includes multiple-choice and multiple-response questions, drag-and-drop tasks, and simulation or lab-style questions. The questions test both understanding and practical application across:

• networking fundamentals
• IP connectivity and services
• security fundamentals
• automation and programmability
• common operational tasks

Many questions are scenario-driven. You may need to interpret command output, choose the next troubleshooting step, or correct a configuration. That means a study plan based only on reading or memorising definitions is incomplete. You need a repeatable process for moving from evidence to a safe technical decision.

Before starting, check Cisco's official CCNA page for the current exam blueprint, registration information, permitted materials and any policy changes. Use the blueprint as your final source for scope. This plan is a method for organising your work, not a replacement for the official documentation.

Set up the plan before week one

Use six weeks if you already have basic computer and networking experience. If IP addressing, Ethernet switching or the command line are new to you, keep the same order but extend the early weeks. The important feature is the sequence: build the mental model first, then practise configuration, then diagnose mixed scenarios under time pressure.

Plan for about 10 hours each week:

• Three 90-minute learning sessions: read or watch one narrow topic, then explain it without notes.
• Two 90-minute practical sessions: configure, inspect and break a small topology.
• One two-hour question session: answer scenario questions and review every wrong answer.
• One 30-minute review: clear due cards and update your error log.

Keep three records:

1. A command and output notebook, with the purpose of each command rather than a collection of syntax.
2. An error log containing the symptom, evidence, diagnosis, correction and verification.
3. A small set of revision cards for facts that must be recalled quickly, such as subnet calculations, protocol behaviour and verification commands.

Do not count time spent passively reading as practical study. For each topic, finish with an observable task: calculate an address range, predict a route, interpret output, write a configuration, or explain the safest next command.

Week 1: Build the network and addressing model

Target: 10 hours.

Spend the first three 90-minute sessions on the purpose and behaviour of common network devices, Ethernet concepts, IPv4 addressing, subnet masks, IPv6 notation and basic network services. Your objective is not to recite every term. It is to identify what a device knows, what it does not know, and which evidence would answer the next question.

In the practical sessions, create a small topology with two switches, two routers and end hosts. Label every interface, address and subnet. Practise calculating network address, usable range and broadcast address for mixed prefix lengths. Include IPv6 addresses and distinguish global unicast, link-local and multicast behaviour.

Finish each practical task by verifying it. For example, inspect interface state, confirm the addressing, test reachability and explain whether a failure is local, routed or service-related. In your error log, record the calculation or assumption that caused the error.

Use the question session for short scenarios involving cabling, duplex or speed symptoms, ARP behaviour, IPv4 subnetting and IPv6 address types. Mark an answer wrong if you guessed correctly without being able to justify it.

Your week-one exit test is simple: given a diagram and an address table, you should be able to describe the path of a packet, calculate the relevant subnets and list the first three pieces of evidence you would collect if the host could not communicate.

Week 2: Switching, VLANs and routing decisions

Target: 10 hours.

Study VLAN purpose, access and trunk behaviour, inter-VLAN routing, MAC address learning, native VLAN considerations and common Layer 2 failure patterns. Practise reading a topology before touching the configuration. Write down the intended VLAN membership, trunk links and gateway for each subnet.

In the lab sessions, configure a small VLAN design, then deliberately introduce one fault at a time: an incorrect access VLAN, a missing VLAN, a trunk mismatch or a wrong default gateway. Use show commands to prove the fault rather than changing several settings at once.

Then move to routing. Practise how a router chooses between routes, including the importance of the longest prefix match and the distinction between a directly connected, static or dynamically learned route. Work with routing tables and predict the forwarding decision before testing it.

A useful troubleshooting sequence is:

1. Confirm the endpoint's address, mask and gateway.
2. Confirm the local interface and VLAN.
3. Confirm the next-hop path.
4. Inspect the routing table.
5. Test the destination and return path.
6. Verify the correction and record a rollback if the change is risky.

The week-two exit test is a diagram-based explanation of why a packet takes one route rather than another, followed by a safe fix for a VLAN or gateway fault.

A due queue keeps the daily review narrow rather than presenting every topic at once. In MySummaries, a queue for this stage could look like this:

Clear the queue before starting new cards, but do not spend the whole session reviewing isolated facts. If a card repeatedly fails, return to the topology or command output that gives the fact meaning.

Week 3: IP services and practical operations

Target: 10 hours.

Cover the behaviour and operational purpose of common IP services in the blueprint, including DHCP, DNS, NAT, NTP, syslog and SNMP where relevant to your materials. For each service, know the problem it solves, what a client or network device must be configured to do, and which evidence confirms that it is working.

Build short scenarios rather than one large lab. For example, test a client receiving an address, resolving a name and reaching a translated destination. Then remove one dependency and predict the visible symptom. A name-resolution fault should not be diagnosed in the same way as a missing default route.

Add device-management tasks to this week. Practise reading interface summaries, routing tables, neighbour information, configuration sections and logs. Be precise about the difference between operational state and configured intent. A configured interface can still be administratively down, physically down or unable to pass traffic because of a Layer 2 problem.

Reserve the question session for output interpretation. For each question, state what the output proves, what it does not prove and what command or test would distinguish the leading alternatives.

A board brings the candidate's own notes, diagrams and error-log entries into one working area. A CCNA board might be organised like this:

Keep sections small enough to test. A page of copied notes is not a useful revision board; a board should make the decision, command or threshold easy to retrieve.

Week 4: Security and automation

Target: 10 hours.

Study security fundamentals alongside configuration practice. Revise authentication, authorisation and accounting, management-plane protection, access control, segmentation, secure remote access and least-privilege thinking as covered by the current blueprint. For each control, ask what risk it reduces and what operational problem it might create.

Practise choosing the least permissive option that still meets the requirement. A question may give you several technically possible changes but only one that limits access appropriately, preserves administrative accountability or avoids exposing a management service unnecessarily.

Use the practical sessions for configuration intent and verification. Before making a security change, write the expected effect and a recovery route. Afterward, test both the permitted and denied cases. Never treat a successful login or ping as proof that the complete security requirement is satisfied.

Introduce automation and programmability through the concepts in your materials: structured data, APIs, controller-based management, repeatability and the difference between a manual command and an intended state. You do not need to turn every study session into software development. You do need to identify what information is being exchanged, how it is structured and what operational advantage automation provides.

Week 5: Mixed scenarios and troubleshooting

Target: 10 hours.

This week changes the type of work. Stop studying domains in isolation for most sessions. Use mixed scenarios that combine addressing, switching, routing, services and security. Give yourself a stated constraint, such as restoring access without changing unrelated VLANs or diagnosing the fault with read-only commands first.

Use this six-part response structure for every scenario:

1. Goal and constraints: what must work, and what must not be disturbed?
2. Topology and assumptions: which devices, interfaces and paths are involved?
3. Evidence: which outputs, logs or tests support the diagnosis?
4. Diagnosis: what is the most likely root cause, and why are alternatives less likely?
5. Fix: what configuration or operational change is justified?
6. Verification and rollback: how will you prove success and undo the change safely?

This structure prevents a common error: jumping from a symptom to a command. It also trains you to prioritise the fault most likely to restore service or reduce risk.

At the end of each question session, classify errors as knowledge, calculation, output interpretation, command choice, reading accuracy or time management. The classification determines the next study action. A knowledge error needs a concise note and cards. An output-interpretation error needs another worked scenario. A reading error needs slower extraction of constraints before answering.

A weekly weakness report should show where marks are actually being lost, not just which topics feel difficult. For example:

Use the lowest section to plan the next two practical sessions. Do not automatically reread the entire subject because one narrow skill is weak.

Week 6: Timed practice and final consolidation

Target: 10 hours.

Complete two timed mixed papers or equivalent timed question sets during the week. Use the question types represented in the exam: multiple-choice, multiple-response, drag-and-drop and simulation or lab-style tasks. Follow the instructions in your practice environment carefully; the aim is to practise selecting, configuring and verifying under a time limit.

After each paper, spend at least as long reviewing as answering. For every missed or uncertain item, write a one-line rule, one supporting example and one verification method. Separate a wrong answer caused by missing knowledge from one caused by misreading a constraint.

Do not spend the final days learning a large new topic from scratch unless the current official blueprint or your diagnostic work identifies a clear gap. Instead, rehearse:

• subnet calculations and route selection
• common show-command outputs and what they prove
• configuration intent and safe verification
• security-first choices and least privilege
• troubleshooting order and likely root causes
• automation terminology and operational benefits

Keep the final review short enough that you can recall rather than recognise. Close your cards, explain a route-selection decision aloud, and diagnose one small topology without notes. Check Cisco's official source again for current exam-day requirements rather than relying on an old study guide.

How to use the plan from this week

Start with a two-hour baseline session. Calculate several IPv4 subnets, read one routing table, interpret one interface or VLAN output, and answer a small mixed set of questions. Record each uncertainty in the error log. That gives you a starting point for week one rather than an abstract timetable.

At the end of every week, ask three practical questions:

• Can I explain the behaviour without copying a definition?
• Can I identify evidence before proposing a change?
• Can I verify the fix and describe a safe rollback?

If the answer is no, adjust the next week's practical sessions. More reading is not always the correction; often the missing step is a small topology, a command-output exercise or a scenario with explicit constraints.

How MySummaries helps

MySummaries lets you build a revision board from your own CCNA notes, slides, diagrams and lab records, then turn weak points into review cards, written mock exams and spoken troubleshooting practice. For this plan, use the board to organise the weekly domains, the due queue for daily retrieval, and the weakness record to choose the next practical scenario.