The VCDX program receives applications containing certain common errors. These errors even appear in otherwise promising applications. Here is a list of common problems that candidates should avoid. The list does not prescribe how to repair these problems; this choice is intentional. A candidate must use knowledge and skill as a vSphere architect and technologist to fix the problems.
If you are applying for VCDX, and you find some of these problems in your draft application, we urge you to rectify these problems before submission. Caution: submitting a perfect application does not guarantee achieving the VCDX credential, because your performance at defense trumps your performance on the application. Nevertheless, avoiding needless errors in your application increases your likelihood of advancing to the defense stage and positions you better for success there.
AVOID THESE PROBLEMS:
- Failure to respond to one or more stated customer requirements.
- Unexplained discrepancies in the submitted documentation: especially, inconsistencies among documents in the submission; also, inconsistencies between text and diagrams.
- Omitting information that is specifically required by the application; or else, failing to make it prominent.
- Avoiding decisions ("here are three choices, Mr. Customer; you pick") or else presenting a decision without explaining its rationale. These are two faces of the same error: missing an opportunity to display relevant knowledge and skills.
- Throwing needless or redundant material into the application. Applications are not evaluated by the kilogram!
- "Name-dropping" VMware products: that is, introducing them into the design in a trivial or tangential fashion. Applications are not evaluated by how many VMware products they might sell.
- Failure to analyze risks facing the design, including those driven by customer constraints, and to show why the risk was accepted or else how it was mitigated.
- The presence of unexplained single points of failure.
- Failure to show critical thinking about security. Customers' security requirements can be implicit in their other requirements and constraints, rather than stated up-front by them.
- Making reference to SLAs without defining them crisply or showing the mapping from the customer's applications to various SLAs.
- Use of unsupported configurations without explaining why, and why this was an appropriate risk for this customer.
- Merely citing "best practices" as a justification for decisions; or else contravening ordinary best practices without explaining why.
- Omitting technical information that an implementer would need. Especially, leaving the configurations of components to the reader's imagination is a missed opportunity to display relevant knowledge and skills.
- Submitting no implementation guidance; or else submitting generic ("boilerplate") implementation guidance that lacks apparent relevance to the customer's requirements.
If you do not know how to rectify these problems in your application, consider advancing in your career before attempting VCDX.
