CCDE Practical Tips


Every test has its own “personality,” and the CCDE practical is no different. Here are some assumptions I am going to make when I sit for the test.

1.  The test is by necessity an artificial scenario.  Like watching a science fiction movie, you have to “suspend disbelief” in order to complete it.  Specifically, if a device is described as having certain features, you should accept that as fact, even if you know no such device exists.   If the scenario says a 10-Gig wireless firewall that inspects video traffic is used in the design, then that is in fact the case, and your designs should reflect that fact.

2.  The scenarios are usually described in a series of email messages. You should assume that statements made in the emails are true (unless explicitly stated as an opinion).  If a character in the scenario says that a link is experiencing packet loss, then that is what is happening.  While you may be skeptical of real-world third party observations, that is not the case here.

3.  Remember that the test is not a hardware test, nor a budgeting test.  You are not asked to choose specific models of switches or routers, nor do you need to design the most cost-effective solution.  In addition, your designs should not be based on hardware limitations, unless they are given in the scenario.  You don’t have to worry if a router has enough interface slots or memory.

4.  You are asked to design to requirements of the scenario.  The requirements may be explicit, or may need to be derived from the scenario.   But you shouldn’t assume other requirements if they are not part of the scenario.  You may want to create a fully redundant design, but if the scenario doesn’t call for it, you don’t need to do it. In other words, requirements not stated or implied (derived) should not be assumed.

5.  A lot of what goes into a real design are ‘soft’ requirements that have nothing to do with technology.  In a real design, you may consider such things as market availability of hardware, budget, timelines, software or hardware maturity, skills of the technical staff and perhaps political issues.  Unless these items are specifically mentioned in the scenario, you should not consider them in your designs.

6.  Don’t base your answers to questions on your answers to previous questions.  Instead, refer to the scenario documentation.  Unlike the CCIE lab, where not answering one question can affect the rest of the test, the CCDE practical is designed to stop you from going down the wrong path before you get very far.

7.  If you are asked to choose a technology from a list of choices, assume that list contains the only possible choices.  You may think metro Ethernet is a better solution than a couple of T3’s but if it isn’t listed as a choice, assume it is unavailable.

8.  Some of the questions require you to fill in a table or matrix, comparing technologies with requirements.  These questions are not all or nothing.  You can receive partial credit if you fill out most of it correctly.  In addition, some of the cells in a matrix may not have a valid (or relevant) answer and are not graded at all.

9.  If you believe there is a problem with a question, or the scenario will not work as stated, use the comments to communicate your observations.  The comments are read by the graders, and if you have a valid point, it can influence the score on that question.

10.  Be aware that the multiple choice questions frequently contain “red herrings” or distracters (as they are technically called). Not all the choices are real ones.

11.  On some questions, you can receive partial credit if there are multiple parts to the question.

12.  Drag and drop design questions are scored based on whether your answer meets the requirements of the scenario.  It doesn’t have to be an “optimal” design.

Let me know if you find these tips helpful.   See y’all in Chicago!

5 responses to “CCDE Practical Tips

  1. Ron,

    From personal experience and a brief discussion with one of the test writers, I’d also suggest following the KISS principle (Keep It Simple, Stupid!), especially as it relates to the drag-and-drop mock visio questions. Most network designers go into second and third level thinking (That’s why it’s no fun to play poker with networking peers!). This test should be treated like any other, where your first instinct is probably correct.

    I didn’t attend the Techtorial, so if Russ said anything to contradict these thoughts, disregard my comments.

    Good luck!

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.