VCAP-VCF Architect · Exam 3V0-12.26 · VMware Cloud Foundation 9

Nothing hands-on is tested in exam 3V0-12.26. Read its blueprint and all twenty objectives sit in architecture, products and design, with the install and troubleshoot sections marked as having no testable objectives at all. Lab time is not what prepares you for this one. Written design work is, which is what this workbook of 146 exercises asks you to do.

FirstWhat this exam actually is

Facts from the published exam guide, last updated 18 August 2026:

Source: the official exam guide for 3V0-12.26, published by Broadcom. Read it yourself before you book. Everything below is written against the objectives in that document.

SecondWhy lab practice will not save you here

VMware uses one standard five-section frame for every exam blueprint, and each exam fills only the sections its objectives belong to. Put the two advanced VCF 9 exams side by side and they are mirror images of each other:

If you have spent your career building and running VCF, that table should give you pause. Everything you are good at sits in the row this exam does not test. Being able to configure a stretched cluster is a different skill from deciding whether the design needs one, justifying it against a requirement, and writing down what it costs.

ThirdWhere the real marks are

Counting the twenty objectives by subject tells you where the weeks should go:

Section 1 is where experienced engineers lose marks, and it is only five objectives. It asks you to tell a requirement from a constraint from an assumption from a risk, to use availability, manageability, performance, recoverability and security as a working vocabulary, and to write a design decision that traces back to something. None of that is VCF knowledge. All of it is examinable, and all of it can be learned in a weekend if you actually sit down and do it.

FourthHow to practise a design exam

You cannot practise this one by building things. Three approaches that do work:

• Re-document a design you already built. Take a real project, extract the requirements from memory and from the email trail, then write the design properly: conceptual, logical, physical, every decision justified and traced. You will find decisions you cannot defend. That is the point of the exercise.
• Work from scenario briefs. One page of customer prose, out of which you extract numbered requirements. The exam hands you exactly this, so practise the extraction until it is quick.
• Write under a clock. Design work expands to fill whatever time it is given. Section T below is a full design broken into timed pieces, and it is the closest thing to real exam pressure.

Where an exercise asks for a scenario you do not have, use a real customer from your own work and change the names. A real brief is messy in ways an invented one never is, and that mess is the thing you are practising on.

Workbook146 exercises, in design order

Sections A to D build the vocabulary: requirements and their classification, the five quality attributes, design decisions, and validation. Sections E to G cover the product and architecture choices. Sections H to S walk the design itself, from discovery through conceptual, logical and physical, then once through each quality objective. Section T is a full design against the clock. Numbers in grey at the right are the objectives.

Every exercise produces something written. If you finish one with nothing on paper, you have not done it.

Everything in this exam rests on telling these four apart. Do this section before any other.

1. 1Take a real project you worked on and write ten statements the customer actually made, in their words.1.1›
2. 2Classify each of those ten as a business requirement or a technical requirement, and defend any you found hard to place.1.1›
3. 3Write the test you used to decide: a business requirement says what the organisation needs, a technical requirement says what the solution must do.1.1›
4. 4Now classify the same ten as requirement, constraint, assumption or risk. Several will move.1.2›
5. 5Write the one-line test for each of the four, so you can apply it under time pressure.1.2›
6. 6Take three constraints and write what each one removes from the design space.1.2›
7. 7Take three assumptions and write what happens to the design if each proves false.1.2›
8. 8Convert one assumption into a risk, and write the mitigation that would let you close it.1.2›
9. 9Find a statement in your list that is really two requirements joined by “and”, and split it.1.1›
10. 10Find a statement that sounds like a requirement but is actually a solution, and rewrite it as the need behind it.1.1›
11. 11Write a requirement that is not measurable, then rewrite it so it can be verified.1.1›

Availability, manageability, performance, recoverability and security. The exam uses these five as its vocabulary, so you should too.

1. 12Write one sentence defining each of the five qualities, without using the word itself in the definition.1.3›
2. 13For each quality, write the question you would ask a customer to elicit it.1.3›
3. 14Take one design decision and write its effect on all five qualities, including the ones it harms.1.3›
4. 15Find a pair of qualities that conflict in a real design, and write how you would resolve the conflict.1.3›
5. 16Classify twenty requirements from a scenario against the five qualities, and note any that belong to none of them.1.3›
6. 17Write what distinguishes availability from recoverability, with an example of a design that has one and not the other.1.3›
7. 18Write what distinguishes manageability from monitoring, since the exam treats them as different objectives.1.3›

A design decision without a justification is an opinion. This is the single most examinable skill in the blueprint.

1. 19Write a design decision in a fixed structure: the decision, the justification, the implication, and the requirement it satisfies.1.4›
2. 20Take ten decisions from a past design and rewrite them all in that structure.1.4›
3. 21For each decision, trace it back to a specific requirement, constraint or assumption. Delete any that trace to nothing.1.4›
4. 22Write three decisions where the justification is a trade-off rather than a best practice.1.4›
5. 23Take one decision and write the alternative you rejected, with the reason you rejected it.1.4›
6. 24Find a decision in your own past work that was actually a default nobody questioned, and justify it properly or change it.1.4›
7. 25Write a decision whose implication is a new risk, and record that risk in the register.1.4›
8. 26Produce a one-page decision register for a small design, with every decision numbered and traced.1.4›

How you prove the design meets the requirements before anyone builds it.

1. 27Write what a design validation strategy contains and who it is for.1.5›
2. 28Take ten requirements and write the test that would prove each one is met.1.5›
3. 29Separate the tests that can only be run after build from the ones that can be checked on paper.1.5›
4. 30Write a validation plan covering functional verification, performance testing and failure testing.1.5›
5. 31Define the entry and exit criteria for validation, so there is an agreed definition of done.1.5›
6. 32Write what you do when a validation test fails: change the design, change the requirement, or accept a risk.1.5›
7. 33Produce a requirement to test traceability matrix for one small design.1.5›

Section 2 asks you to choose between architectures from a scenario. Build the comparison before you need it.

1. 34List the VCF deployment architectures available in VCF 9 and write one line on what each is for.2.1›
2. 35Write the difference between a consolidated and a standard architecture, and the point at which you move from one to the other.2.1›
3. 36Write what a VCF instance, a fleet and a region mean, and how they nest.2.1›
4. 37Given a single-site scenario with 200 workloads, choose an architecture and justify it in three sentences.2.1›
5. 38Given a two-region scenario with a data residency requirement, choose an architecture and justify it.2.1›
6. 39Write what changes in the design when a second region is added later rather than planned from the start.2.1›
7. 40State the management domain sizing drivers, and what grows it as the estate grows.2.1›
8. 41Write when you would separate workload domains and when you would add clusters to an existing one.2.1›

A design can be supported and still be wrong. The exam tests whether you know the difference.

1. 42Write the difference between a supported configuration and a recommended one, in one sentence.2.2›
2. 43Find three configurations that are supported but not recommended, and write why you would avoid each.2.2›
3. 44Write where you would check support status for a given combination, and how current that source is.2.2›
4. 45Take a design where a constraint forces a supported but not recommended choice, and write the risk you record.2.2›
5. 46Write what you do when the customer demands a configuration that is not supported at all.2.2›
6. 47Write how the interoperability matrix and the compatibility guide differ, and when you use each.2.2›
7. 48Produce a short list of version and interoperability checks you would run before signing off any VCF design.2.2›

Knowing which service answers which need, and when none of them do.

1. 49List the VCF Advanced Services and write the use case for each in one line.2.3›
2. 50Given a requirement for self-service application deployment, say which service answers it and why.2.3›
3. 51Given a requirement for container workloads alongside virtual machines, say which service answers it.2.3›
4. 52Given a requirement for private AI workloads, say which service answers it and what it demands of the physical design.2.3›
5. 53Write what each Advanced Service adds to the management domain in resource terms.2.3›
6. 54Find a requirement that sounds like it needs an Advanced Service but does not, and justify leaving it out.2.3›

Section 3 begins here. Everything downstream is only as good as this.

1. 55Write the ten questions you would ask in a first discovery workshop, in the order you would ask them.3.1›
2. 56Take a one-page customer brief and extract every requirement from it, numbered.3.1›
3. 57Identify what the brief does not say that you must ask about before designing.3.1›
4. 58Separate the stated requirements from the implied ones, and get the implied ones confirmed in writing.3.1›
5. 59Write the business objectives behind the requirements, in the customer language rather than yours.3.1›
6. 60Prioritise the requirements as must, should and could, and record who agreed the priority.3.1›
7. 61Find two requirements that conflict, and write the question you would ask to resolve them.3.1›

The layer most people skip. The exam does not.

1. 62Write what a conceptual model contains, and what it deliberately leaves out.3.2›
2. 63Produce a conceptual model for a scenario: entities, their relationships, and the qualities required of each.3.2›
3. 64Map every business objective to an element of your conceptual model.3.2›
4. 65Write why the conceptual model contains no product names, and what breaks if you put them in.3.2›
5. 66Take a conceptual model and write the questions it raises that the logical design must answer.3.2›
6. 67Present the model as one diagram a business sponsor could read without help.3.2›

What the solution does, still without deciding what it is built from.

1. 68Write the difference between logical and physical design, with an example of each for the same component.3.3›
2. 69Produce a logical design for compute: clusters, their purpose, their sizing drivers, with no hardware named.3.3›
3. 70Produce a logical design for storage: policies, tiers, protection levels, with no vendor named.3.3›
4. 71Produce a logical design for networking: segments, routing boundaries, isolation requirements, with no device named.3.3›
5. 72Produce a logical design for management and operations components.3.3›
6. 73Trace every element of the logical design back to the conceptual model.3.3›
7. 74Find a logical design element that has crept into physical detail, and move it to the right layer.3.3›

The layer that gets built. Every number here needs a reason.

1. 75Turn your logical compute design into a physical one: host specification, host count, cluster layout.3.4›
2. 76Show the calculation behind the host count, including the failure capacity you reserved.3.4›
3. 77Turn your logical storage design into a physical one: architecture, policies, capacity with overhead shown.3.4›
4. 78Turn your logical network design into a physical one: switches, uplinks, VLANs, gateways, address allocation.3.4›
5. 79Size the management domain and list every appliance in it with its deployment size.3.4›
6. 80Write the physical design decisions that were forced by a constraint rather than chosen.3.4›
7. 81Produce the bill of materials implied by your physical design.3.4›
8. 82Check every physical number against a published maximum, and record where you are close to one.3.4›

The first of the five quality objectives, each examined in its own right.

1. 83Write the availability requirement as a number, and state what it is measured against.3.5›
2. 84Design cluster sizing and admission control to meet that number, showing the capacity cost.3.5›
3. 85Decide where you need stretched clusters and where you do not, and justify both.3.5›
4. 86Write the single points of failure remaining in your design, and whether each is accepted or mitigated.3.5›
5. 87Design availability for the management components, not only the workloads.3.5›
6. 88Write what your design does when a whole site is lost, step by step.3.5›
7. 89Record the availability design decisions with their trade-off against cost.3.5›

How the thing is run after you leave.

1. 90Write what manageability covers in this blueprint, and how it differs from monitoring.3.6›
2. 91Design the lifecycle approach: how components are patched and upgraded, and in what order.3.6›
3. 92Design for configuration consistency, including how drift is detected and corrected.3.6›
4. 93Design the operational model: who does what, and which tasks are self-service.3.6›
5. 94Write the manageability cost of each major design decision you have made.3.6›
6. 95Find a decision that improved performance and made the design harder to run, and record the trade.3.6›

Numbers, and the evidence behind them.

1. 96Write the performance requirements as measurable figures, not adjectives.3.7›
2. 97Design compute sizing to meet them, stating the consolidation ratio you assumed and why.3.7›
3. 98Design storage to meet a stated latency and throughput requirement.3.7›
4. 99Design the network to meet a stated throughput requirement, including east-west traffic.3.7›
5. 100Identify the first bottleneck your design would hit under growth, and at what point.3.7›
6. 101Write what you would measure after build to prove the performance requirements are met.3.7›
7. 102Record where you traded performance for cost, and get it agreed.3.7›

What happens after something is lost, and how long it takes.

1. 103Write the recovery point and recovery time objectives, per workload tier, as numbers.3.8›
2. 104Design backup for the workloads to meet those numbers.3.8›
3. 105Design backup and restore for the management components, including the restore order.3.8›
4. 106Design disaster recovery between regions, and state what is replicated and what is rebuilt.3.8›
5. 107Write the recovery runbook at a level a second engineer could follow.3.8›
6. 108Write how you would test recovery, and how often.3.8›
7. 109State the difference between your availability design and your recoverability design in one sentence.3.8›

Security as a design layer, not a checklist at the end.

1. 110Extract the security and compliance requirements from a scenario, including the ones implied by the industry.3.9›
2. 111Design network segmentation and the firewall model, and say where each rule is enforced.3.9›
3. 112Design encryption: what is encrypted at rest, what in transit, and where the keys live.3.9›
4. 113Design certificate management across the fleet, including renewal.3.9›
5. 114Design role separation so that no single administrator can act unobserved.3.9›
6. 115Design logging and audit retention to meet the compliance requirement.3.9›
7. 116Write the residual security risks and who accepted them.3.9›

Its own objective in this blueprint, so treat it as its own design.

1. 117Write the identity requirements: who signs in, to what, and from where.3.10›
2. 118Design the identity provider topology and its availability.3.10›
3. 119Design group to role mapping across the fleet, by group and never by user.3.10›
4. 120Design multi-factor authentication and state where it applies and where it cannot.3.10›
5. 121Design the break-glass path for when the identity provider is unavailable.3.10›
6. 122Write what happens to access when a person leaves, and who performs it.3.10›

How the platform is actually used by the people it was built for.

1. 123Write who consumes this platform and in what units: virtual machines, namespaces, applications.3.11›
2. 124Design the tenancy model: organizations, projects, namespaces, and the boundaries between them.3.11›
3. 125Design the self-service catalogue and what a consumer may and may not change.3.11›
4. 126Design quotas and the policy for what happens when one is exhausted.3.11›
5. 127Design the chargeback or showback model and the figures it rests on.3.11›
6. 128Design the request and approval flow, including where it should not apply.3.11›
7. 129Write how consumption changes the capacity plan, since self-service makes demand unpredictable.3.11›

The last design objective, and the one that tells you whether the rest worked.

1. 130Write what the monitoring strategy must answer, and for whom.3.12›
2. 131Design what is collected, at what interval, and how long it is retained.3.12›
3. 132Design alerting: which conditions page someone, which raise a ticket, and which are informational only.3.12›
4. 133Design capacity monitoring and the lead time it must give you before you run out.3.12›
5. 134Design cost monitoring and who receives it.3.12›
6. 135Design the dashboards for three audiences: the operator, the service owner, and the sponsor.3.12›
7. 136Write how monitoring proves each AMPRS quality is being met in production.3.12›

Do this section twice in the final week, from a scenario you have not seen before.

1. 137From a one-page brief, extract and number every requirement, constraint, assumption and risk. 25 minutes.1.2›
2. 138Produce the conceptual model from those requirements. 20 minutes.3.2›
3. 139Produce the logical design for compute, storage and network. 40 minutes.3.3›
4. 140Produce the physical design with sizing shown. 40 minutes.3.4›
5. 141Write twenty design decisions with justification, implication and traceability. 35 minutes.1.4›
6. 142Write the availability and recoverability design against stated numbers. 25 minutes.3.5›
7. 143Write the security and identity design. 25 minutes.3.9›
8. 144Write the consumption and monitoring strategy. 25 minutes.3.11›
9. 145Produce the validation plan and the traceability matrix. 20 minutes.1.5›
10. 146Present the whole design in ten minutes to someone who will challenge it.1.4›

How to use itFour weeks, if that is what you have

One piece of advice for every section. When an item gives you a scenario and asks for the best answer rather than a correct one, it is testing whether you can tell which requirement wins. Go back to the requirement list, find the highest priority one the options affect, and answer against that. Design exams reward the person who reads the requirements twice and the options once.

Exam details are from the published Broadcom exam guide for 3V0-12.26, last updated 18 August 2026, and are accurate at the time of writing. Broadcom revises blueprints regularly, so confirm the current version before you book. Exercises here are my own, written from the published objectives; they are not exam content.