How to tell the five apart, what each obliges the architect to do, and worked classifications.
From Ultra Transcenders 2V0-13.25 by Tony Rough
Objective 1.3 and the candidate description expect you to separate five kinds of statement, because each one obliges the architect to do something different.
| Term | What it is | What the architect must do |
|---|---|---|
| Requirement | Something the solution must do or achieve | Meet it; prove it in validation |
| Constraint | A fixed limit on design choices, set outside the architect’s authority | Design within it; record its effect |
| Assumption | Something believed true but not yet proven | Validate it; give it an owner and date |
| Risk | An uncertain event that would harm the design’s goals | Assess it; choose a response |
| Dependency | Something the design relies on but does not control | Confirm delivery; track it |
Five quick tests separate them:
They are linked. An assumption that proves false becomes a risk, a new constraint or a changed requirement; until it is validated it is itself a risk. A dependency that might arrive late or not at all is a risk. A constraint often creates a risk: one data centre is a certainty, and the risk is what a site-wide outage would do.
| Statement | Classification | Reason |
|---|---|---|
| The shop must be recoverable in another region after a regional disaster | Business requirement | Outcome the business needs |
| Only one data centre is available for three years | Constraint | Fixed limit on site choices |
| Existing Fibre Channel arrays must be reused | Constraint | Limits storage options |
| Workload growth stays under 20% a year | Assumption | Unproven; check capacity data |
| The network team will enable jumbo frames on overlay VLANs | Assumption and dependency | Unconfirmed; another team delivers it |
| Corporate DNS holds forward and reverse records for management components | Dependency | Required by VCF; run by another team |
| A rack power failure could stop the whole management cluster | Risk | Possible event with impact |
| The operations team may miss NSX training before go-live | Risk | Uncertain; hurts manageability |
| A stretched vSAN cluster needs a witness site independent of both data sites | Dependency | Third site the business must supply |
| Management budget covers four hosts at most | Constraint | Fixed limit on footprint |
| Management components need statically assigned IPv4 addresses | Constraint | VCF design requirement |
Several rows are grounded in documented VCF facts. The Fibre Channel storage model can use existing arrays, but VCF’s automated workflows do not provision it and extra management tools are needed. Host and edge TEP VLANs need an MTU of at least 1700, with 9000 or larger recommended and configured end to end. The single-rack cluster model gives no protection against a rack failure. The vSAN stretched cluster model needs a third site, with no logical or physical dependency on either data site, to host the witness appliance.
The last row shows a subtlety. The VCF design guide labels some elements Design Requirement: required for VCF to operate, with no deviation permitted. Examples are statically assigned IPv4 addresses and host names, forward and reverse DNS records for all management components, and an internal NTP source for all management components. From the customer’s side these act as constraints on the design, and the DNS and NTP ones create dependencies on external services (Chapter 4: Prerequisites, external services and the physical network).
Common trap: Writing an unvalidated assumption into the requirements as fact, such as “the inter-site link is under 5 ms” - a vSAN stretched design depends on that figure, so it must stay an assumption with an owner until it is measured.
Common trap: Calling a constraint a risk - “only one data centre” is certain, not uncertain; record it as a constraint and record its consequence (a site-wide outage stops the fleet) as the risk.
This note is one section of Ultra Transcenders 2V0-13.25: VMware Cloud Foundation 9.0 Architect, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Broadcom TechDocs.
Free to read with Kindle Unlimited. Opens Amazon in a new tab.
About the book · 2V0-13.25 terms in the glossary · All 2V0-13.25 study notes
What belongs in a conceptual model, what doesn't, and how it traces back to business objectives.
What each design quality means, with example requirements and the VCF 9.0 design choices that serve them.
How to record a design decision so it traces to a requirement and states its implications, the way VCF design elements do.
The requirements that call for a separate workload domain, and when another cluster in an existing domain is enough.
Prerequisites, latency and bandwidth limits, the vSAN witness, host counts and what fails over automatically.
Bulk, vMotion, Replication Assisted vMotion, Cold and OS Assisted Migration compared by downtime, scale and source platform.