VCDX: Design Scenario

The 75 minutes for the defense section just finished, now a short break while the panelist gets the next part ready, The Design Scenario, where you get to show how you would approach a specific set of business and technical requirements. Fast.

The 45 minutes (Extended from 30 min to 45 min in 2016) alloted to this part go by quick. Quick really isn’t fast enough to begin to describe it. But there is no need to have fully functional environment ready for deployment either.

As far as I know the goal of the defense scenario is not to see how fast you can design, its more about how you approach the design requirements and how you verbalize your thought process. But then again you can cover more ground if you can do it really quick 🙂

The VCDX design scenario will give you access to 1-3 slides containing a set of requirements and constraints, both business and technical. Also you might get access to number for an existing environment that need to be accounted for in the design. Your role is to ask additional questions for more information about the problem that the fictional customer is facing, additional business requirements or even a set of constraints.

The VCDX blueprint explains this section like this:
Respond interactively to a presentation of requirements and constraints to show the ability to produce a design which satisfies a customer’s needs.

Real world design sessions take hours, even tens of hours of different meetings with a different people to be able to fully understand the requirements for a complex environment. This is usually done with a set of specific guidelines in place, what should be asked, who to ask and who will approve the final conceptual design. The design scenario is somewhat that process but only in 30-45 minutes and with less emphasis on a fully designed solution in the end. Process is key here and to be able to cover as much as possible the guidelines need to be become more streamlined as well.

Rene Van Den Bedems blog post about the design scenario is a great resource that has a lot of good recommendations to do just that, and I used them as the basis to create a whiteboard layout to be able to show the process as fast as I possibly could.

Here is a picture of the layout:


On the left there are specific notes and recommendations and below that is the process itself. So the plan was to be able to go through that process as fast possible.

On the right are potential questions to ask regarding a specific technology stack to be able to fulfill any requirements.

The whiteboard layout has several sections:

  • On the left there is the conceptual list with possible design goals, success factors, requirements/constraints/assumptions(if any)/risks. This does not mean that these topics will be on the slides themselves as you might need to ask around for them.
  • Next to that is the design characteristics part where the plan was to use specific markings to be able to mark each design decision taken with a specific characteristic.
  • Below those two were the design decisions themselves and those were supposed to be classified based on blueprint sections. I never even got close to be able to categorize them. Still the logic around it seemed to make sense at the time.
  • The rest of the whiteboard contains a logical design diagram with specific room for storage and network and additional room for management layers. Design choices were located near the corresponding stack.

I practiced drawing the layout on different sizes of whiteboards just to be ready, and so that I could draw it as fast as possible and knew what should go where.

The plan was to have something remotely similar to that during the scenario itself. Due to the nature of the design scenario I got I never got close to being able create it though. But I had a plan in regards for the process and the layout I wanted to use to show my design skills and I think that made a difference.

Practice a design scenario mock with the study group at least 3-4 times before the defense day. Once with the process in front of you, the other time with nothing but a whiteboard. Always a whiteboard. And coffee. Always coffee.

Some additional pointers:

  • Plan for dual site designs as well. Space becomes scarce when drawing everything twice.
  • Not all designs are just about the infrastructure, the workloads are important to.
  • If you have access to two whiteboards please do use them both.
  • Talk, talk, talk. Tell the panelist what you are thinking, and why. Requirement->Design decision with justification and an alternative if applicable. Short explanations, no technology deep dives explaining a specific feature in vSphere.

And finally here are some other helpful resources for the design scenario:

And also many of the VCDX’s post their recommendations and experiences about the design scenario in their “experience post”, so you can find a detailed list of such posts over at Gregg Robertsons blog:

VCDX: Troubleshooting Scenario

***UPDATE*** This section from the VCDX defense has been removed. Instead you will get extra 15 minutes for the Design Scenario.

This is the last part of the journey. Now you only need to troubleshoot a problem as methodically as possible and you have reached the finish line.

Let me explain.

Most real life troubleshooting sessions with customers have a single goal, a solution. And preferably with an analysis on root-causes, and recommendation to mitigate the risk of future incidents. This needs to be unlearned to a degree for the troubleshooting scenario.

The VCDX troubleshooting scenario will give you access to 1-2-3 slides containing a predetermined scenario and on those slide a predetermined amount of information is given. Your role is to ask the right questions to get better information to analyse the fault and explain why you asked about it or addressed with a change request to show expert level knowledge.

The VCDX blueprint has also a pretty good explanation:
Respond interactively to a presentation of a customer problem to show analytical skills and deep product knowledge, especially an understanding of how the components work and interact.

Here is an example:

  • What virtual SCSI controllers does the VM have?
    • The reason I’m asking is it sometimes can account for specific performance degradation on high IO machines as well control how large the IO queue that particular disk has.
  • How is the fiber channel zoning configured? Is it using single initiator-single target or something specific?
    • The reason I’m asking is that arrays that do not have ALUA capabilities tend to experience path thrashing if the zoning is incorrectly configured or the Load Balancing option within the Storage Kernel is misconfigured.

As you can see this will soon become very hard to cover everything so its best to read the slides and decide on a specific technology stack to focus on. Then move to the next even if you went for the “right” one in the beginning. Make sure to propose a plan of action and explain why that specific set of changes should be done.

I found that Rene Van Den Bedems method that he explained in this blog post extremely helpful:

As for the troubleshooting process it worked best for me to start from the VM side and troubleshoot towards the physical infrastructure.

I took the method in Rene post and personalised it to a degree. Since I had to methodically troubleshoot I thought it would be best to create a whiteboard layout to use in the scenario.

Here is a picture of that layout:


I need to explain the picture or it will not make any sense… Not my favorite kind of picture but it is necessary.

On the left there are locations of ESXi and vCenter specific logs (from Rene’s post). Of course this is just to read it again and again over the course of the troubleshooting mock scenarios. This of course can include track (DT-NV-Cloud) specific log locations.

Below that is box including lots of recommendations from various sources (including Rene’s post).

The large box with the colored boxes is the whiteboard diagram. The boxes include the technology stacks of core vSphere, Management, Storage, CPU/RAM Scheduling, Network. A similar layout for other tracks could include a larger management box with the corresponding management components (vCloud/vCNS, Horizon components, vRA components etc). The left hand side included a Q&A for initial questions, Notes if any and Change Log if I requested some changes to be done to the environment.

The plan was to at least have a something similar to that layout during the scenario itself. In my scenario I never had a chance to draw all of the boxes, not even close. But I used the layout during the troubleshooting mocks and I think it helped with the methodology of the process. I also practiced drawing the layout on a smallish whiteboard so I could at least draw it quickly.

The right side included boxes that are again from Rene’s blog (which I hope you have at least read by now since I’ve mentioned it 4 times now 🙂 ) and they include potential investigation paths to follow.

Also I recommend doing at least 3-4 Troubleshooting mocks before the defense cause the first I went through I just froze.  You will not want that to happen on the defense day.

Also reading past experiences and other people recommendations were also extremely helpful:

VCDX: Study Groups

Study group creation is very important step in the VCDX preparations. So many aspects of the defense can be addressed with a study group.

Here is a short list:

  • Presentation Skills
  • Skill Transfer
  • Potential Question creation
  • Feedback in slide layout
  • Technology specific debates (increasing skill in explaining said technology)
  • Presentation Run-Throughs
  • Mock Defenses
  • Troubleshooting and Design Scenario practice
  • Design Feedback

The size of a study group is also important since it can become hard to schedule a time for large group of people. So a group of 3-4 people has been a good number for the VCDX study groups I’ve been in.

The commitment of the people in the study group is also important. It is good, if possible, to create a group with people with the same drive and available time to commit. But even if people have different drive any study group is better than no study group.

Twitter is the best tool to find a group of people who want to be in a study group. Before each VCDX session specific Google+ pages pop up to gather all those that want to be part of a study group.

It is never to late, nor to early, to join study groups. I was in a study group for the VCDX October 2014 defense before I even started creating my design. That actually gave me a lot of motivation and showed be to what caliber I needed to perform at to be successful in the defense. Starting the study groups early also give each of the member time to cover the each of the designs before submission for feedback.

The number of study groups you are a part of is closely related to the time you have to spend on the matter. I was in two separate study groups for my defense so a lot of time went into mock defenses and design/troubleshooting scenarios.

In one of the study groups I was in with Gregg Robertson and Tim Gleed, we created a specific layout to follow for your sessions:

Study Group Proposed session layouts:

  1. General Session – do some questions (Basic, Advanced, Expert) and Skill Matrix discussions – Duration 30-60 minutes
  2. Mock Sessions – Design mocks – Duration 90 Minutes (75 minutes minimum)
  3. Presentation Session – Presentation run-throughs, improve presentation soft skills – Duration 30-60 minutes
  4. Troubleshooting Scenario Sessions – single person goes through a Troubleshooting Scenario. Other panelists need to have one ready before the session – Duration 30-45 minutes (15 minutes minimum)
  5. Design Scenario Session – single person goes through a Design Scenario. Other panelists need to have one ready before the session – Duration 45-60 minutes (30 minutes minimum)

We met every single day (or the plan was to) with the intent to cover a specific session layout. Many of the session actually just ended in just casual conversions about IT. That even helped.

I recommend buying a Webex account while running the study groups, not only will this help with scheduling, it will allow you to record the sessions and give your study group partners access to their sessions. I actually listened to many of my mocks just to find any flaws in the presentation.

For non-native-english speaking candidates the study group is the best way to train your IT specific speaking skills before the defense. You will not get extra time for being from a country where english is not the native language.

And finally, here are a short list of excellent resources for other VCDX study group tips:

Brad Christian, @vHipster

Joe Silvagi, VCDX 175, @VMPrime

Rene Van Den Bedem, VCDX 133, @VCDX133