Practical exam-day approach
The companion to the Scenario intake checklist: that note runs one scenario; this one runs the whole 8-hour day and gives the reusable thinking pattern for every question.
The day arc (8 hours, four 2-hour scenarios)
- First three scenarios = Core; the fourth = your elective (AI Infrastructure). Each is independent - reset between them.
- Time can't be banked: finishing early gains nothing, so spend any surplus validating, not racing ahead - but don't chase "perfect" either, since unused minutes are lost regardless.
- No backward navigation: an answer is final once you advance. Decide deliberately, then commit.
- Closed book, but cisco.com is available: look up facts (syntax, defaults, feature specifics) there; bring your own reasoning for the design call - docs won't make the judgment for you.
- Energy management: four back-to-back design problems is a stamina test. Use the short break between scenarios as a real reset - clear the previous context completely.
The per-question design pattern (the spine of every answer)
Every note in this vault is built on one chain - run it in your head for each decision: Requirement -> constraints -> options -> tradeoffs -> recommendation -> justification -> what would change it -> validation. Lead with the business/technical driver, name the real options, state the tradeoff you're accepting, then justify against the requirement. Partial credit follows intent, so the visible reasoning chain matters as much as the final pick.
Scenario-execution tactics
Tactical habits practitioners credit for surviving the day, complementing the design pattern above:
- Budget the read. A scenario is roughly 20 pages; spend the first 15-20 minutes reading all of it before answering. Constraints and hints are deliberately buried - in topology diagrams, footnotes, and appendices - and the exam is built so that everything you need is supplied, so a single missed constraint poisons every downstream answer.
- Lean notes, no diagrams. Capture only the critical constraints and requirements (the four-bucket capture in Scenario intake checklist); do not redraw the topology - it burns time and adds nothing.
- Name the scenario type early. Most scenarios are one of four task shapes - merge/divest, add a technology, replace a technology, or scale - which are the design use cases in Business Strategy Design. Spotting which one you are in frames the right trade-offs fast.
- Work branching questions backward-safe. Some questions chain - a design choice, then its justification, then follow-ons built on it - so a wrong first branch cascades. Eliminate wrong options methodically before committing, and note that business and technical justifications are asked separately. If a question asks what you still need from the customer but the answer is already in the brief, that option is wrong - you were expected to have read it.
- Decompose grid questions. Chart / drag-and-drop items are a stack of independent yes/no cells - judge each row x column on its own merits, and accept that a few cells are legitimately arguable (scored either way); hunting for one "correct pattern" burns minutes.
- The customer can overrule you. Mid-scenario updates may adopt the option you argued against - that decision is now canon, so design forward from it rather than relitigating; and mine every supplied answer or email, because facts that matter two questions later are often buried in them.
- Spend time where the points are. Drawing and table questions carry more weight than a single multiple-choice item, so do not rush them to save time elsewhere - a careless table error costs more than a wrong single-choice answer.
Note your assigned role, and let it prune the option space. Each scenario casts you (enterprise architect, provider consultant, and so on), and the role decides which remedies you own - the enterprise side of an MPLS service can only re-mark at its own ingress, while the provider side could change the tunnel mode itself. And when the scenario level-sets - announcing the customer chose differently than you recommended - adopt their choice as the new baseline and move on; the next questions test the world as it now is, not your preferred one.
Pre-answer reflex check
Before committing each answer, sanity-check it against the cross-cutting reflexes (one per lens):
- Least-disruptive adequate option, not the most elaborate - Business Strategy Design.
- Read the data/telemetry first; don't design from assumptions - Control, data, and management plane and operational design.
- Size to the stated tolerance (RPO/RTO/convergence), not a reflex maximum - Network Design.
- Design to the actual SLA of the service, not a generic gold standard - Service Design.
- Proportional controls - security matched to the stated risk, not blanket lockdown - Security Design.
- Then scan for the tempting-but-wrong patterns in Common design traps.
Final preparation (using this vault to revise)
- Flashcards (
#flashcards) across every note are the fastest active-recall pass - drill the spaced-repetition blocks, don't just re-read. - Rebuild the matrices from memory: for each scorecard (tunneling selection, IGP choice, firewall modes, QoS classes, storage protocols, AI fabric Ethernet-vs-InfiniBand...), try to reproduce the green/amber/red verdicts before checking - if you can defend each cell, you own the tradeoff.
- Walk the MOCs (CCDE Core - MOC, AI Infrastructure - MOC, Exam Topics (Design Lenses) - MOC) and, for each note title, say the one-line design call out loud. Gaps are your revision list.
- Readiness bar: for any Core or AI-Infra topic you can state the requirement it answers, two or three real options, the tradeoff, and a defensible recommendation - in dual-stack terms - without notes.
Spaced repetition
Why spend surplus time validating rather than advancing early in a Practical scenario?
Unused time can't be banked for later scenarios and there's no backward navigation, so extra minutes are best spent checking the current answers - which can't be revisited once you move on.
The reusable per-question design pattern is
requirement -> constraints -> options -> tradeoffs -> recommendation -> justification -> what-would-change -> validation (lead with the driver; partial credit follows intent).
The fourth (elective) scenario can sink the whole exam, so
treat AI-Infrastructure depth as mandatory - you must clear each scenario's minimum as well as the aggregate pass.
On the Practical, how long should you spend reading a scenario before answering, and why?
~15-20 minutes reading all ~20 pages first - constraints and hints are deliberately buried in diagrams, footnotes, and appendices, and everything you need is supplied, so a missed constraint poisons downstream answers.
Why handle branching questions with extra care, and what is the 'information already in the brief' trap?
Questions chain (decision -> justification -> follow-ons), so a wrong first branch cascades - eliminate methodically before committing; and if a question asks what you still need from the customer but it is already in the documentation, that option is wrong.
What do you do when the scenario adopts an option you recommended against?
Treat the customer's decision as canon and design forward from it - the exam models real consulting - and re-read the supplied update, since later-relevant facts are often buried in it.
Related
Sources
- Z. Zsiga, Non-Technical Guide to the CCDE Practical v1.4 (Zigbits, 2020) - role-prunes-options and the level-set rule (durable, v3-valid technique); full pass 2026-07-26.
- CCDE v3.1 Written and Practical Exam format and scoring (Cisco); final-preparation methodology adapted from the CCDE Official Cert Guide.
- Scenario-execution tactics adapted (paraphrased) from a practitioner exam-day write-up (J. Tissieres, jtnetwork.io).