Objective 1.6 asks you to document decisions so that each one links to the requirement it serves and states its implications.
A design decision record answers four questions: what was decided, why, what it costs or changes, and which requirement or constraint it serves. Useful fields:
- ID, so tests, risks and other decisions can refer to it.
- Decision: one clear statement of the choice.
- Justification: why this option meets the requirement better than the alternatives, not a restatement of the decision.
- Implication: the consequences, good and bad: cost, footprint, effect on other qualities, extra work for operations, dependencies on other teams, and options it closes off.
- Traces to: the requirement or constraint IDs it satisfies.
- Alternatives considered and why they were rejected.
The VCF design guide writes every design element this way: an ID, the requirement or recommendation itself, a justification and an implication. One example, paraphrased:
| Field | VCF-CLS-RCMD-CFG-001 (paraphrased) |
|---|---|
| Type | Design Recommendation |
| Decision | vSphere HA admission control tolerates one host failure, percentage based |
| Justification | Suits VMs with varied reservations; vSphere recalculates the percentage as hosts change |
| Implication | In a four-host cluster, only three hosts’ worth of resources are usable |
Because these elements are generic, they have no “traces to” field. In a customer design you add that link yourself, which is what turns a list of best practices into a justified design. Figure 2.1 follows one requirement through its decision record to the test that proves it.
Each type of VCF design element calls for a different entry in your own design:
| Element type | Architect’s action | What to record |
|---|---|---|
| Design Requirement | Adopt; no deviation permitted | Treat as a constraint the design meets |
| Design Recommendation | Adopt, or deviate for a reason | Any deviation as a decision with justification and implication |
| Design Choice | Select one option | A full decision record traced to requirements |
Decisions in the recurring shape, each driven by a requirement (R) or constraint (C):
| Requirement or driver | Design decision | Justification | Implication |
|---|---|---|---|
| R: management survives a host failure without manual action | High Availability VCF Operations model | Three nodes; rapid recovery of a single node failure | More footprint; an optional external load balancer needs another IP and FQDN |
| C: only one rack available | Single-rack cluster model | Only model that fits; minimal footprint | No rack failure protection; risk recorded |
| R: workloads survive the loss of one metro data centre | Stretched cluster with vSAN stretched storage | Recovers from host and zone failures | Witness in a third site; at most 5 ms RTT between data sites |
| C: reuse existing Fibre Channel arrays | Fibre Channel as principal storage | Uses existing arrays | Provisioned outside VCF workflows; extra tools |
| R: one corporate sign-in across the fleet | Fleet-wide SSO, appliance VCF Identity Broker | One SSO for all instances; three nodes for availability | Single point of failure for fleet sign-in; more footprint |
| R: low latency, high IOPS for databases | vSAN ESA storage architecture | Documented choice for high-performance workloads | NVMe only; 16+ cores and 128 GB+ per node |
Implications deserve the most care, because the exam guide expects you to understand a decision’s effect on the wider VMware estate and the customer’s technology landscape. Documented examples of implications that reach beyond the platform team:
- Jumbo frames must be configured end to end, including every intermediate segment and gateway: a dependency on the network team.
- Layer 3 multi-rack clusters cannot be stretched, and the Layer 3 model is not supported for the management domain default cluster: a decision that closes off future options.
- Moving from an embedded to an external (appliance) VCF Identity Broker requires a reset of VCF Single Sign-On: a choice that is costly to reverse.
- Connected licensing and online depot access need outbound internet from VCF Operations: a firewall and security policy change.
Traceability runs both ways. Every decision traces to at least one requirement or constraint; every requirement traces to at least one decision and at least one validation test. A traceability matrix makes gaps obvious:
| Requirement | Decisions | Validation test |
|---|---|---|
| Management survives a host failure | HA VCF Operations; HA NSX Manager; vSphere HA | Host failure test |
| Survive loss of one metro data centre | Stretched clusters; witness site | Zone failure test |
| Corporate sign-in for administrators | Fleet-wide SSO, appliance Identity Broker | Sign-in test per component |
Common trap: A justification that only restates the decision (“use three NSX Manager nodes because a cluster is needed”) - it must say why the option meets a named requirement better than the alternatives.
Common trap: Writing “Implication: none” for decisions that clearly cost something - the guide’s own elements record costs such as lost capacity, extra VLANs and manual steps; a decision with no stated cost has usually not been analysed.