How I prepared for the CCDE practical exam
av Jean-Paul Baaklini, den 23.04.19 09:44
I took the CCDE practical in February. The exam was quite brutal in terms of tempo, complexity and variety. I must admit I hadn’t completely understood how difficult this exam would be when I started preparing. There’s a lot to cover and the approach is very different from a CCIE exam.
I had a really hard time during the exam, and even though I felt I did pretty good (you can more or less tell if your answers are in sync with the “re-anchoring” questions), I immediately started preparing for my second attempt. I recommend not waiting for the results (which can take between 10 and 12 weeks to arrive) before resuming your studies. There are only 3 exam dates per year (about every 12 weeks), you don’t want to start studying one to two weeks before the next attempt, and in case you pass, you’re not going to regret having the knowledge and understanding.
A few days ago, I got to know that I had passed the exam in February in my hometown (Paris). It feels wonderful to have completed this challenge and most importantly, it’s great to have tested successfully the preparation approach I’m going to try and describe here. My CCDE number is 2019::3 .
I hadn’t initially planned on taking the CCDE lab. I needed to re-certify my CCIEs by passing any expert-level exam and I wanted to try something new. That’s why I decided to try the CCDE written.
I have worked within the field of networking for over 19 years (13 of which as a network architect). During the years, I developed some skills designing and documenting networks, and a systematic and wholistic approach to network architecture from discovering business needs to constructing the building blocks to enable businesses. Having said that, I found the content of the CCDE study guide presented some new angles and forced me to ask new questions that allowed me to grow as a network architect. I loved the new insights I gained from preparing for the written exam and it felt frustrating to stop there. So with my wonderful wife’s benediction, I started preparing for the lab.
Looking at the blueprint, the exam was heavily based on Routing & Switching, Service Provider and Datacenter architectures. I therefore felt quite confident that my CCIEs in each of these areas would allow me to quickly re-certify and maybe even learn something new. I was up for a serious reality check. The biggest difficulty, for me, was to understand the structure and philosophy of the practical exam. How does it differ from the written exam when there’s no hardware to configure? What exactly is being tested and how? How do I know if my answers are correct? In a CCIE lab, when you’re supposed to conditionally inject specific routes into a VRF, a quick Show command can let you know if you did good or if you need to troubleshoot.
Structure of the CCDE exam
Before I get started, I wish to clearly state that this article does not cover the content of the exam itself (I will honour the NDA), nor it is an announcement that BlueTree will be providing CCDE training or creating CCDE materials. The only CCIE and CCDE trainings we will be offering are reserved for BlueTree consultants. This is merely a description of my experience preparing and taking the exam.
The practical exam is composed of four sections with approximately 2 hours per section. 4 hours in the morning and 4 hours in the afternoon. Sections are grouped in pairs: 1 & 2 in the morning, 3 & 4 in the afternoon. You may not start a section before the previous section is completed. I used 2,5 hours on section 1 and was left with only 1,5 hours to complete section 2.
In each section, you are faced with design challenges such as add/replace a technology/service, merge, divest or scale networks, design new networks or fix design failures. As an example, you may be hired as a design consultant by a made up company to help them with an urgent failure scenario, you then get an email saying something like “thanks, we loved what you did, we have something else we want you to look into”. The next few questions might be about a merge or divest (the opposite of merge) project, followed by a new service addition, and so on for about two hours.
Once you answer a question, there’s no return button. Some questions are “branching” questions. I do not know all the details but I expect that answering these questions incorrectly would take you down a “wrong branch”. Once you’re there, you’re presented with a few questions from the wrong branch. I heard that you don’t get points for answering these questions. You don’t necessarily fail the entire section for entering a “wrong branch”: at the end of each branch, you get what I call a re-anchoring question to put you back on the correct path. If your previous answers are in sync with these questions, it’s a very good sign!
Philosophy of the exam
The blueprints of the practical and written exams are similar, that’s why I would recommend spending more time preparing for the CCDE written than we would normally use on preparing for a CCIE written exam. I would also recommend not waiting too long between passing the written and attempting the practical.
For me, the main difference between the CCDE written and practical exams can be summarized in one single Keyword: context.
During the written exam, each question is self-contained; you might get a very direct question such as: "Which overlay technology is not compatible with NAT?"
Or a question with a brief context such as:"Company ABC has 50 locations, 30 connected via an MPLS WAN, 10 connected over the internet..., which of the technologies below would allow you to...?"
In the practical exam, the context is built throughout each section. You start by reading some customer/project background documents, maybe some emails. These documents contain all the information you need to answer the questions correctly. They also contain a lot of useless information
Important to clear your RAM before starting the next section. Each section has its own context and micro-contexts. The last thing you want is to assume requirements that were not stated in the current context because they were stated in the previous context.
Here is an example of micro context: “Assuming for a moment that optimal routing isn’t so important for company XYZ, which BGP design would allow for the best scalability”. I call this a micro context because it temporarily suspends a set of requirements important for the context while maintaining all other requirements of the context.
There’s no typing during the exam. You are provided with the answers to choose from, some are optimal, some are sub-optimal and some are simply wrong. I guess I would classify the questions types in 5 categories:
- Drag and drop /tables: fairly similar to the written exam but in the context established this far in the section. There are two sub types in this category:
- Select all the characteristics describing correctly the solution/protocol
- Describe the correct implementation steps in the correct order (like an implementation runbook)
- Ask the right question. When designing networks, you need to select the right solution based on the context, and you also need to know what information is missing. This type of questions tests your ability to figure out when you are missing information and ask the right question. You should not ask for information already, directly or indirectly, provided to you. For example, if you’re told that multicast routing relies on PIM sparse mode, don’t ask which PIM mode is running (the information was directly provided) and don’t ask if the solution includes a Rendez-vous point (the information was indirectly provided). Sometimes the right answer is to say, “there’s nothing I need to ask at this stage”.
- Select the solution (Guess who). This type of questions reminds me of the game “Guess who?”. Each player starts the game with images of 24 people and their first names with all the images standing up. The goal of the game is to deduct which card our opponent has chosen. You do this by asking various yes or no questions to eliminate candidates, such as "Does the person wear a hat? glasses? have hair?" You then eliminate candidates by flipping those images down until all but one is left. You’re not technically guessing but deducting from the answers you get. Similarly, in the CCDE practical exam, you’re not guessing. All the information allowing you to eliminate the “wrong” protocols/solutions and select the correct ones are presented somewhere in the context. I guess we could call these decisional questions since they result in a design decision/selection.
- Describe a consequence or characteristic of the chosen solution or layers of solutions (reverse guess who??) With this type of questions, your job is to analyse the consequences of the design choices you or your customer made. It often introduces a decisional question. As an example, think of a design in which you have multiple IGP autonomous systems all running the same BGP AS (iBGP). Knowing that during an earlier question, you decided to summarise routing information in the IGPs, which process will detect the failure of the BGP neighbour relationship?
- Diagram: the only type of question that can be compared to an “type your own answer” question, are the network diagram creation. You still are limited to a set of devices, physical and logical links and protocols, but you are presented with many more options than you need, and there are fairly free to place those devices, physical and logical links and protocols pretty much anywhere on the diagram.
I followed a similar approach to the one I follow for a CCIE lab preparation: I spent the first two thirds of my preparation time on mastering the modules independently, and the last third on practicing putting everything together and understanding the modules interactions. For the CCIE, modules are protocols such as an IGP and the final third of the preparation time is spent on full scale labs. When preparing for the CCDE, modules are groups of solutions/protocols (ex: VPN technologies, Multicast protocols, IGPs, …), and putting everything together means practicing contexts.
Spend some time understanding the trade-offs of each solution. Every solution/protocol has trade-offs and costs (memory and/or CPU usage, delays, “loss of information”, SPOF, instability, and so on). Understand how failures are detected in each case instead of only learning magical fits-all protocols like BFD. Then learn how some characteristics of each solution can contradict others. For example, BFD and Non-stop forwarding.
Create tables (create them, don’t inherit them)
When studying modules, I created tables per solutions/protocols group: each column listed one of the solutions/protocols of the given group and each row listed a differentiating feature for the group.
Here’s the list of books and materials I consumed in preparation for the exam. I suppose the list could have been longer, but I don’t think I can make it shorter. I experienced an AHA moment with each of these.
- The Art of Network Architecture: Business-Driven Design by Russ White
- CCDE Study Guide by Marwan Al-shawi
- CCDE Practical Exam: Practice Scenarios by Marwan Al-shawi
- CCDE Practical Studies, Practice Labs by Martin J Duggan
- CCIE and CCDE Evolving Technologies Study Guide by Brad Edgeworth, Jason Gooley and Ramiro Garza Rios
- End-to-End QoS Network Design by Tim Szigeti, Robert Barton, Christina Hattingh and Kenneth Briley, Jr.
- Optimal Routing Design by Russ White
- Definitive MPLS Network Designs By Jim Guichard, François Le Faucheur, Jean-Philippe Vasseur
- Traffic Engineering with MPLS By Eric Osborne and Ajay Simha
- MPLS and VPN Architectures By Jim Guichard, Ivan Pepelnjak and Jeff Apcar
- Layer 2 VPN Architectures By Wei Luo, Carlos Pignataro, Dmitry Bokotey and Anthony Chan
- Many (many) CiscoLive registered sessions
I would like to encourage more people to take the CCDE lab as it’s an invaluable source of growth. The knowledge and structure you gain in preparing for the exam are pivotal for your success as a network architect. It’s also completes the CCIE certification(s) perfectly in our quest for designing and building the best networks possible to support businesses and enable them to grow.