What is your plan of attack


As promised in the previous post, here is an attempt at compiling some specific tactics for each CCIE R&S exam module. I tried to order the bullet points with a logical sequence, but it’s not to be considered as a hard-coded process.


Very likely, many of these suggestions will appear quite obvious, but, nevertheless, I really hope that they might prove useful to some candidates. The list is certainly not exhaustive, so if you can think of other effective tactics, please do not hesitate to share them in the comments below.


CCIE R&S Written Exam


  • Carefully read the complete test item, including the question stem, answer choices, and supplementary material, if any.
  • Eliminate the unlikely, improbable, or absurd answer choices and identify the most likely or most plausible choices.
  • Identify differences between pairs of answer choices, if any.
  • Try to understand the technical concept that the item is testing.
  • Evaluate the answer choices you’ve determined to be plausible, attempting to eliminate those that might seem plausible on the surface but are nevertheless “distracters” (incorrect answer choices). In this manner, continue to home in on the correct response!
  • If you can’t find any solution, well, take an educated guess and move on to the next item before you get too bogged down and waste time. But, don’t hesitate to reconsider if you have time, and change your mind.
  • Do not believe myths (like “always pick the longest answer” or “always choose the first or last option”)!


Troubleshooting Module of the CCIE R&S Lab Exam


  • Carefully read all resources, including questions, diagrams, and guidelines.
  • Try to identify the most likely topic being tested in each item (for example, Layer 2, Layer 3, Layer 4, control plane versus data plane, etc.).
  • Identify items with a high point value.
  • Cherry-pick items according to their point value, or those revolving around topics with which you feel comfortable, or even based on the number of hops that might be involved (if applicable). This process is quite personal, but I’d recommend actually starting first with items that have a low point value in order to build confidence and start collecting some points as soon as possible.
  • Focus on the region highlighted by the “mini-diagram” that is provided in each item stem. The only purpose of these diagrams is to help you quickly find the device(s) that the item is referring to. They are not meant to be readable, so keep the main diagram open in a pop-up window and resize it to fit your taste and need.
  • Don’t expect best-practice scenarios or designs. Don’t try to understand the whole scenario, but again, focus on the region highlighted by the mini-diagrams and figure out what the configuration is supposed to do in that region. There is no need to understand the whole topology before getting started.
  • Don’t let yourself get mired with a particular item; manage your time! Set a maximum time per item and move on to the next item if you can’t solve an item within that period. Then, come back to it later on if you have time.
  • Question yourself in order to isolate the issue to as few likely cause(s) as possible by using a logical methodology, starting wide and narrowing down to as few hops as possible. Hopefully, you’ll be able to narrow things down to the one device, interface, or feature that is the most likely culprit.
  • As you attempt to confirm your hunches, keep track of any changes that you make so that you can systematically undo them if your hunch is wrong.
  • Use the option to reload devices to their initial broken configuration if you have any doubts about the changes that you made and you want to revert to the initial situation. Remember that the virtual devices reboot much faster compared to hardware platforms.
  • Review or re-evaluate the guidelines before jumping to configure your final solution.
  • Think of alternate solutions and go for the simplest and/or the least demanding in terms of configuration work.
  • Keep a notepad with the validation tests for each item, and do regression tests when changing anything that could impact previously resolved items.
  • Keep track of which items were resolved, as well as the confidence level you possess in terms of having found the solution.
  • Aim for achieving 80 percent of the total score and use the last few minutes to verify your work rather than attempting a new item. Remember that while you need to achieve the minimum score in all modules, you don’t actually need more than 80 percent in the Troubleshooting Module!
  • Try not to use the optional extra time in the Troubleshooting Module, as you will most likely need that time in the Configuration Module, where the minimum score concept isn’t as important as for Troubleshooting and Diagnostic...


To be continued…