2V0-13.25 is not an installation exam, but practical preparation still matters. The hands-on work should support architecture: inspect a VCF environment, understand topology, measure capacity, trace dependencies, build design artifacts, and validate assumptions. Broadcom’s current guide says Sections 4 and 5 have no testable objectives, so labs should strengthen design judgment rather than become configuration drills.
Use the current VCF 9.0 Architect objectives as the lab map. A useful exercise always ends with a design decision and its implication.
Lab one: inventory a small VCF environment
Document management components, workload domains, vSphere clusters, vSAN, NSX, Aria or operations tooling, DNS, NTP, and external dependencies. Draw both the logical relationship and the physical placement.
The goal is to see how product components become architecture layers.
Lab two: translate a business brief into requirements
Create a one-page stakeholder brief with growth, availability, performance, security, recovery, and operational goals. Convert each into technical requirements.
Mark assumptions, constraints, dependencies, and risks separately so they do not become hidden requirements.
Lab three: create a conceptual model
Draw users, workload groups, management capability, major external systems, recovery expectations, and trust boundaries without overloading the diagram with implementation detail.
Ask a non-specialist whether the model communicates the intended solution clearly.
Lab four: create the logical design
Choose fleet topology, management/workload domains, network structure, automation, and operations relationships. Write a short decision record for each major choice.
Link each decision to a requirement and list one implication.
Lab five: create the physical design
Add concrete sites, hosts, clusters, capacity, network placement, and failure domains. Verify prerequisites and core services such as DNS and NTP.
Compare the physical design with the logical model and identify any assumption that became invalid.
Lab six: run an AMPRS review
Review availability, manageability, performance, recoverability, and security one by one. For each characteristic, identify one strength, one risk, and one possible improvement.
This exercise turns AMPRS into a repeatable architecture-quality check.
Lab seven: perform capacity and scalability planning
Estimate current workload demand and a plausible growth scenario. Determine which resource—compute, storage, network, management, or licensing/operational capacity—reaches a limit first.
Document how the design scales and which changes would be required at the next threshold.
Lab eight: design business continuity and disaster recovery
Choose a workload and define recovery requirements. Design continuity for management components and workloads, considering availability zones, backup, replication, network, identity, and recovery sequence.
Then test the design on paper against a specific failure scenario.
Lab nine: design migration and self-service consumption
Create a workload onboarding path into VCF and a self-service pattern for requesting or consuming infrastructure. Include governance, automation, approvals, and monitoring.
The architecture should make adoption easier without giving up control.
Lab ten: validate and defend the design
Use a checklist that covers requirements, risks, constraints, assumptions, AMPRS, VCF architecture, capacity, migration, consumption, and monitoring. Ask another engineer to challenge one decision and defend it using documented evidence.
Add a requirements workshop exercise. Ask another person to play the stakeholder and provide vague goals. Your task is to ask clarifying questions until availability, performance, recovery, security, growth, operations, and constraints are measurable enough to design against. This is more valuable for an architect exam than memorizing configuration commands.
Add a risk register to the conceptual model. For each risk, record probability or qualitative likelihood, impact, mitigation, owner, and validation. Include at least one dependency risk such as DNS, NTP, external identity, network uplinks, or facility capacity. This connects architecture artifacts to the Section 1 risk objectives.
Add a design-decision record to the logical lab. Use fields for requirement, decision, alternatives, rationale, implication, and validation. Keep it short enough that another architect can review it. The purpose is to create traceability, not paperwork for its own sake.
Add a dependency matrix to the physical design. List management components, workload domains, storage, network, automation, operations, DNS, NTP, and any external services. Mark which components depend on which others. This can reveal hidden single points of failure that are not obvious in a high-level diagram.
Add a lifecycle-management tabletop. Assume a VCF component must be upgraded while critical workloads remain online. Identify compatibility, sequencing, maintenance, rollback, monitoring, and staffing requirements. Even though the exam does not test administration steps, the exercise exposes whether the design is actually manageable.
Add a performance-validation plan. Choose a business-critical workload and define the metrics, test pattern, baseline, acceptance criteria, and observation tools you would use to validate the design. Performance is a requirement that should be proven, not assumed from hardware specifications.
Add a capacity-growth scenario. Double one workload dimension—VM count, storage, network throughput, or automation demand—and determine which part of the physical design reaches a threshold first. Document the expansion action and whether it causes another dependency to become the new limit.
Add a security-boundary review. Mark management plane, workload networks, administrative access, automation credentials, operations tooling, and external connectivity. For each boundary, state the threat or requirement that justifies it and the operational consequence introduced.
Add a monitoring-design artifact. Define what management components and workloads must be observed, which health and capacity signals matter, who receives alerts, and how trends support future capacity planning. Monitoring should be tied to requirements rather than built as a generic dashboard.
Close the lab by presenting the design to a small peer review. Ask reviewers to challenge one assumption, one capacity decision, one recovery choice, and one security decision. Update the design only when the challenge reveals a requirement gap or stronger trade-off. Architect skill grows through defensible review, not through avoiding criticism.
Add a conceptual-versus-logical redraw exercise. Take the same business brief and create both diagrams. The conceptual view should show capabilities and major relationships, while the logical view should introduce VCF-specific domains, networking, automation, and operations. Comparing them side by side makes the abstraction boundary memorable.
Add a logical-versus-physical redraw next. Convert the logical VCF design into specific sites, clusters, capacity, uplinks, and physical dependencies. Then mark which physical details could change without invalidating the logical architecture and which would require a design revision.
Add a failure-domain tabletop for host, rack, availability-zone, and site loss. For each failure, identify which workloads and management services remain available, which recovery mechanism activates, and which requirements are still met. This turns availability and recoverability into distinct, testable design properties.
Add a self-service governance review. Define what a tenant or consumer can request, what is standardized, what requires approval, which quotas apply, and which automation executes the request. Then test whether rapid consumption could exceed capacity or bypass required security.
Add a design-validation matrix with one row per critical requirement. Include validation method, expected evidence, owner, and pass/fail criteria. This artifact makes the architect’s responsibility explicit: the design is not complete until its important assumptions and requirements can be tested.
At the end, archive the requirements, risk register, conceptual model, logical design, physical design, decision records, capacity plan, recovery design, and validation plan as one package. If the documents contradict one another, the lab has found a design problem before implementation. That is exactly the value of architect-level hands-on preparation.
Add a compatibility review to the lab package. Document the VCF 9.0 components, external integrations, hardware or platform assumptions, and version dependencies that need validation. This does not require memorizing every compatibility matrix entry; it teaches that compatibility is a formal architecture constraint.
Add one operations-staffing scenario. Assume the organization has limited after-hours support and compare two designs with different automation and management complexity. Decide whether the more sophisticated topology still fits the people who must operate it.
Add one availability-zone design comparison. Create a design that protects only within one zone and another that spans zones. Record cost, latency, network, capacity, recovery, and management implications. The exercise makes failure scope explicit rather than using “high availability” as a vague label.
Add one workload-migration rehearsal on paper. Identify prerequisites, source compatibility, network path, cutover, validation, rollback, and monitoring. The migration plan should preserve the target architecture intent instead of introducing a permanent exception simply to move the first workload quickly.
Add one self-service capacity test. Model several tenants requesting resources at once and decide how quotas, approvals, automation, and capacity headroom prevent the platform from being exhausted. Consumption strategy should connect user experience with physical capacity.
Finish with a formal architecture review where every major decision has a requirement, implication, risk, owner, and validation method. The point of hands-on preparation is not to prove you can click through VCF; it is to prove you can produce design evidence that survives peer challenge.
As a final exercise, remove one requirement from the brief and decide which design choices can now be simplified. This tests whether decisions are truly requirement-driven or whether features were added by habit. Good architecture should become simpler when constraints disappear.
Document the simplification and update the conceptual, logical, and physical artifacts together. If one document still reflects the removed requirement, the design package is inconsistent and needs another review.
Keep the final package small enough that another architect can review the reasoning, not only the diagrams. Clarity is part of design quality because hidden assumptions are much harder to challenge.
That clarity makes peer challenge faster and improves the quality of every later revision.
Keep it reviewable.
The VMware certification architect path is fundamentally about this skill: translating stakeholder goals into a VCF 9.0 design whose decisions, trade-offs, and validation can be explained clearly.