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!