VCAP · VCF Support · Exam 3V0-13.26 · VMware Cloud Foundation 9

This is the exact mirror of the Administrator exam. There, every objective sits under Install, Configure, Administrate and nothing else. Here, every objective sits under Troubleshoot and Optimise and nothing else: sections 1 to 4 of the blueprint have no testable objectives at all. Thirty objectives, every one of them a fault to find. That makes preparation unusually simple to describe and unusually hard to do, because you cannot revise troubleshooting by reading about it.

The examWhat you are signing up for

BreadthWhat a support exam actually covers

Thirty objectives in one section sounds narrow. It is the opposite. Read them and they reach across the entire platform:

Six recommended courses are listed against this exam, one per technology domain, which is more than any other in the set. That is the honest signal: this is the broadest of the advanced exams by subject, narrowed to a single verb.

OverlapIt contains other exams whole

I compared the published blueprints line by line. Two complete troubleshooting sections from other advanced exams appear inside this one:

That is the whole of Storage’s Section 5, and the whole of Networking’s Section 5, carried across. The last two differ only by a “Simulations” suffix in this blueprint. So if you have prepared for either of those exams, nine of these twenty-nine objectives are already done, and the work that is genuinely new is compute, Automation, VKS and the Operations stack.

PracticeYou cannot read your way to this one

Every other exam in the set has objectives you can satisfy by understanding something. This one does not. An objective that says troubleshoot and resolve is only satisfied by having resolved something, under time pressure, when you did not already know the answer.

So the workbook is built on one method, and almost every task uses it: create the fault yourself, then diagnose it as if you had not. A fault you built is one where you already know the answer, which means you can mark your own diagnostic order honestly. That is not possible with a fault you merely read about.

• A lab is close to mandatory here, because most of these tasks break something. Nested works for a great deal of it: hosts, clusters, vSAN, NSX, Supervisor and VKS all misbehave realistically enough to practise on.
• Get somebody else to create the faults for the final run. Section X is written for that, and diagnosing your own work is a much easier exercise than it looks.
• Your own estate, read-only, still covers the monitoring objectives and most of section A, where you are deciding which tool answers which question.

Workbook214 tasks, in build order

Section A builds the method and the toolkit. B to F are compute: hosts, vCenter, clusters, machines and optimisation. G to I are storage. J is Automation, K to N are Supervisor and VKS. O to T are the VCF Operations stack, including Logs and alerts. U to W are NSX, ending with the packet walk. X is a set of timed drills with faults somebody else created. The numbers in grey at the right are the objectives.

Objective 5.5. Know what each tool is for before you need one in a hurry.

1. 1List every tool VCF gives you for troubleshooting, and write one line on each.5.5›
2. 2Record which tool answers what is broken, and which answers what changed.5.5›
3. 3Record which tool answers what is slow, and which answers who did it.5.5›
4. 4Record where each tool gets its data from, and how fresh that data is.5.5›
5. 5Record which tools need something configured before they are useful.5.5›
6. 6Record which require a licence or an edition you may not have.5.5›
7. 7Build one table: the symptom, the first tool, and the second tool.5.5›
8. 8Record what you would use if the management plane itself is down.5.5›
9. 9Write the order you open things in, and keep it where you will see it.5.5›

Objective 5.6. The layer everything else sits on.

1. 10List the ways an ESX host can be unhealthy without being down.5.6›
2. 11Record where host logs live and which log covers what.5.6›
3. 12Disconnect a host from vCenter and diagnose it from the symptoms.5.6›
4. 13Record the difference between not responding, disconnected and isolated.5.6›
5. 14Break host time synchronisation and record what starts failing.5.6›
6. 15Fill a host log partition and record what the host does.5.6›
7. 16Diagnose a host that will not exit maintenance mode.5.6›
8. 17Record how you would check hardware health from VCF.5.6›
9. 18Record what a purple diagnostic screen gives you and what to collect.5.6›
10. 19Record the order you would work a host that is unresponsive but still running workloads.5.6›

Objective 5.7. When the thing you troubleshoot with is the thing that is broken.

1. 20Record the vCenter services and which ones everything else depends on.5.7›
2. 21Record where vCenter logs live and which to read first.5.7›
3. 22Stop a non-critical vCenter service and record what stopped working.5.7›
4. 23Diagnose a vCenter that is up but will not accept logins.5.7›
5. 24Record the certificate problems that present as a login failure.5.7›
6. 25Fill the vCenter database partition in a lab and record the behaviour.5.7›
7. 26Record how to check vCenter health and backup status in VCF.5.7›
8. 27Record what still works in the workload domain while vCenter is down.5.7›
9. 28Record the recovery options, in order of how much you would lose.5.7›

Objective 5.8. HA, DRS, EVC and the things that stop a cluster behaving.

1. 29Record what HA actually protects against, and what it does not.5.8›
2. 30Break HA network heartbeating and record what the cluster reports.5.8›
3. 31Diagnose an HA configuration error on one host.5.8›
4. 32Record what admission control does when it refuses a power-on.5.8›
5. 33Cause an admission control failure deliberately and read the error.5.8›
6. 34Diagnose a DRS cluster that is not balancing, and record why.5.8›
7. 35Record how an affinity rule can prevent a migration, and find one that does.5.8›
8. 36Record what EVC does and the error when a machine cannot move because of it.5.8›
9. 37Record the order you would work a cluster where nothing will power on.5.8›

Objective 5.9. The layer the complaint actually arrives at.

1. 38Record the common reasons a virtual machine will not power on.5.9›
2. 39Cause a power-on failure and read the error to its root cause.5.9›
3. 40Diagnose a machine that will not migrate, and record the reason given.5.9›
4. 41Record what an orphaned or inaccessible machine means and how each happens.5.9›
5. 42Create an inaccessible machine and recover it.5.9›
6. 43Diagnose a machine with no network connectivity, from the virtual side only.5.9›
7. 44Record where a machine logs its own problems, and read one.5.9›
8. 45Diagnose a machine that is slow but shows no alarms.5.9›
9. 46Record what VMware Tools state affects, and what it does not.5.9›
10. 47Record the five questions you would ask the person reporting the fault.5.9›

Objectives 5.10 and 5.11. Where troubleshooting turns into tuning.

1. 48Record the four resources you optimise, and the metric that matters for each.5.10›
2. 49Find the busiest cluster in a workload domain and record what is driving it.5.10›
3. 50Record what CPU ready tells you and at what level it becomes a problem.5.10›
4. 51Record what memory ballooning and swapping each indicate.5.10›
5. 52Record what storage latency figures are acceptable, and where you measure them.5.10›
6. 53Produce one optimisation recommendation for the domain, with evidence.5.10›
7. 54Find an oversized machine and record the evidence that it is oversized.5.11›
8. 55Find a machine that is contending, and identify what it is contending with.5.11›
9. 56Record what you would change on that machine, and what you would not.5.11›
10. 57Make one change, measure before and after, and record whether it worked.5.11›

Objectives 5.1 and 5.2. The same wording appears as 5.30, which is a duplicate.

1. 58List the tools in VCF for monitoring vSAN and record what each shows.5.1›
2. 59Run the vSAN health checks and record every category.5.1›
3. 60Open vSAN performance and record what is available per cluster, host, disk and machine.5.1›
4. 61Record what the vSAN capacity view reports beyond used and free.5.1›
5. 62Record which vSAN metric would exonerate storage from a performance complaint.5.1›
6. 63Monitor a non-vSAN datastore and record the metrics available.5.2›
7. 64Record what you can see about the array from VCF, and what you cannot.5.2›
8. 65Record the visibility boundary, and what you must ask the storage team for.5.2›
9. 66Build one table: the storage symptom, and which tool shows it.5.2›

Objective 5.3. Create each fault, then diagnose it.

1. 67Write your diagnostic order for a vSAN performance complaint.5.3›
2. 68Break vSAN networking on one host and diagnose it blind.5.3›
3. 69Record which health checks turned red, in what order, and how quickly.5.3›
4. 70Create a non-compliant object and resolve it.5.3›
5. 71Cause a resynchronisation and work out why it is running from the evidence.5.3›
6. 72Record how to tell a necessary resynchronisation from a worrying one.5.3›
7. 73Fill a vSAN datastore past a threshold and record what happens, in order.5.3›
8. 74Record what a failed capacity device looks like and the recovery steps.5.3›
9. 75Record what differs between OSA and ESA when diagnosing a device failure.5.3›
10. 76Diagnose an object that is inaccessible, and record the difference from non-compliant.5.3›

Objective 5.4. Different tools, different language, same pressure.

1. 77Break one path to a datastore and record the failover, and how long it took.5.4›
2. 78Record what an all paths down event is and what causes it.5.4›
3. 79Record what permanent device loss is and how the host behaves differently.5.4›
4. 80Record how you would tell those two apart from the logs alone.5.4›
5. 81Diagnose a datastore that will not mount on one host only.5.4›
6. 82Record the usual causes of a host-specific storage fault, in order of likelihood.5.4›
7. 83Record where multipathing state is checked and what healthy looks like.5.4›
8. 84Record the evidence you would bring to the storage team, and what it proves.5.4›

Objectives 5.12, 5.13 and 5.14. Three objectives on watching the tenant platform.

1. 85Confirm VCF Operations is collecting from VCF Automation, and record the last collection.5.12›
2. 86Find the VCF Automation objects in Operations and record what is reported for each.5.12›
3. 87Record which Automation failure would be visible here before a tenant reported it.5.12›
4. 88Monitor Provider Management: record what healthy, degraded and at capacity look like.5.13›
5. 89Record what you would check every morning on the provider side.5.13›
6. 90Monitor an All Apps organization: projects, deployments and quota consumption.5.14›
7. 91Find an organization close to its quota and record what the tenant will see next.5.14›
8. 92Diagnose a failed deployment using Operations rather than the Automation console.5.14›
9. 93Record which question you take to Operations and which to the Automation portal.5.14›

Objective 5.15. Provisioning, connectivity and namespace errors.

1. 94Record the stages a VKS cluster passes through while being provisioned.5.15›
2. 95Record where a stuck provisioning job reports its reason.5.15›
3. 96Diagnose a VKS cluster that never finishes provisioning.5.15›
4. 97Record the usual causes: content library, networking, capacity, class, certificates.5.15›
5. 98Break Supervisor connectivity and record what still works and what does not.5.15›
6. 99Diagnose a namespace that will not accept a workload.5.15›
7. 100Record what to check when kubectl cannot reach the Supervisor at all.5.15›
8. 101Record which logs on which component you would collect for this class of fault.5.15›
9. 102Write the diagnostic order for a cluster that will not provision.5.15›

Objective 5.16. The faults that look like Kubernetes and are not.

1. 103Record what happens, in order, when a pod cannot pull its image.5.16›
2. 104Cause an image pull failure and read the event to its root cause.5.16›
3. 105Record the difference between an authentication failure and a certificate failure here.5.16›
4. 106Configure a registry with an untrusted certificate and diagnose the result.5.16›
5. 107Record where a trusted CA is supplied to the Supervisor and to a VKS cluster.5.16›
6. 108Fix the trust and confirm the pull succeeds.5.16›
7. 109Record what to check when only some nodes can pull an image.5.16›
8. 110Record the three commands you would run first for any container start failure.5.16›

Objective 5.17. Restart or recover, which is its own objective for a reason.

1. 111Record the stages of a VKS cluster upgrade.5.17›
2. 112Record where upgrade progress and failure are reported.5.17›
3. 113Record the usual causes of a stalled upgrade.5.17›
4. 114Record what state a cluster is left in when an upgrade fails partway.5.17›
5. 115Record how to restart a failed upgrade, and what that does.5.17›
6. 116Record when restarting is wrong and recovery is needed instead.5.17›
7. 117Record what you would collect before attempting either.5.17›

Objective 5.18. Optimising with the monitoring you already have.

1. 118Record what monitoring is available for a VKS cluster and where it comes from.5.18›
2. 119Find a cluster under pressure and record which resource is short.5.18›
3. 120Record the scaling options available and what each one changes.5.18›
4. 121Record the difference between scaling the cluster and scaling the workload.5.18›
5. 122Scale a cluster and record how long it took and what it cost.5.18›
6. 123Record what autoscaling needs configured before it will work.5.18›
7. 124Record what you would check before concluding a cluster needs more nodes.5.18›
8. 125Produce one scaling recommendation with the evidence behind it.5.18›

Objective 5.19. Cloud proxies, clusters, availability and adapters.

1. 126Draw the VCF Operations deployment and label every node and collector.5.19›
2. 127Record what a cloud proxy does and what breaks when it cannot reach the cluster.5.19›
3. 128Diagnose a cloud proxy that shows as disconnected.5.19›
4. 129Record what a collector group gives you and what happens when a member fails.5.19›
5. 130Diagnose an adapter instance that has stopped collecting.5.19›
6. 131Record the difference between an adapter that is failing and one that is just slow.5.19›
7. 132Record how high availability behaves in an Operations cluster, and its limits.5.19›
8. 133Record where Operations reports its own health, and what to check first.5.19›
9. 134Record what you would do when Operations itself is the thing that is broken.5.19›

Objective 5.20. The what-changed question.

1. 135Open Config Drift and record what it compares against.5.20›
2. 136Record where the baseline came from and who can change it.5.20›
3. 137Change a setting deliberately and find it reported as drift.5.20›
4. 138Record the detection delay and whether anybody was told.5.20›
5. 139Use Operations to find what changed on an object around a known time.5.20›
6. 140Record what compliance benchmarks add to this picture.5.20›
7. 141Diagnose a problem whose root cause is a configuration change.5.20›
8. 142Record how you would prove a change caused an incident, with evidence.5.20›

Objective 5.21. Flows, paths and the physical world.

1. 143Confirm it is collecting, and record from which sources.5.21›
2. 144Trace the path between two machines end to end.5.21›
3. 145Record what the flow analysis shows that NSX alone does not.5.21›
4. 146Diagnose a connectivity problem using the path view.5.21›
5. 147Record what it tells you about a firewall rule that is never hit.5.21›
6. 148Record what a missing data source makes invisible.5.21›
7. 149Use it to answer one real question about east-west traffic.5.21›
8. 150Record when you reach for this product rather than NSX or Logs.5.21›

Objective 5.22. Starting from the complaint rather than the component.

1. 151Open the Troubleshooting Workbench on a workload and record what it shows.5.22›
2. 152Use it to find what changed around the time of a complaint.5.22›
3. 153Work a real or staged slow-workload complaint using the workbench alone.5.22›
4. 154Record which evidence it gave you and which you had to find elsewhere.5.22›
5. 155Record what a business application view adds when one tier is unhealthy.5.22›
6. 156Diagnose a workload whose problem turns out to be a neighbour.5.22›
7. 157Record how you would prove a workload problem is not the platform.5.22›
8. 158Write the order you would work a slow virtual machine complaint in this tool.5.22›

Objective 5.23. The what exactly happened question.

1. 159Confirm Logs is receiving events and list the sources.5.23›
2. 160Record which VCF components send to it and which do not.5.23›
3. 161Run an interactive query and narrow it to one event type.5.23›
4. 162Take a real incident and find its first error in the logs.5.23›
5. 163Record how you would correlate across two components by timestamp.5.23›
6. 164Install a content pack and record what it added.5.23›
7. 165Create a log event alert query and trigger it.5.23›
8. 166Record what you would check when the logs show nothing at all.5.23›
9. 167Record which question goes to Logs and which to Operations.5.23›

Objective 5.24. The alerts themselves can be the problem.

1. 168Open an alert definition and record its symptoms, impact and recommendations.5.24›
2. 169Record why an alert might fire when nothing is wrong.5.24›
3. 170Record why an alert might not fire when something is.5.24›
4. 171Find an alert that is firing and work it to a root cause or a false positive.5.24›
5. 172Change a threshold in a policy and confirm the alert state changed.5.24›
6. 173Diagnose a notification that was never delivered.5.24›
7. 174Record where delivery failures are visible.5.24›
8. 175Record how you would tune a noisy alert without hiding a real problem.5.24›

Objectives 5.25 and 5.26.

1. 176List the tools available for troubleshooting NSX and what each is for.5.25›
2. 177Record which tool answers is it configured, and which answers is traffic flowing.5.25›
3. 178Record when you would use Traceflow, and what it cannot tell you.5.25›
4. 179Record when port mirroring or a packet capture is the only answer.5.25›
5. 180Build one table: the NSX symptom, and the first tool to open.5.25›
6. 181Record the NSX management and control plane components and what each failure costs.5.26›
7. 182Diagnose a transport node that shows as down.5.26›
8. 183Break the tunnel between two transport nodes and diagnose it from the symptoms.5.26›
9. 184Record what an MTU mismatch looks like, and why it is often found late.5.26›
10. 185Diagnose an edge node that is not forwarding.5.26›

Objective 5.27. The largest class of real support calls.

1. 186Record the path a packet takes between two machines on the same segment.5.27›
2. 187Record the path when they are on different segments behind one Tier-1.5.27›
3. 188Record the path from a workload to the physical world.5.27›
4. 189Break connectivity at the segment level and diagnose it.5.27›
5. 190Break it at the Tier-1 level and diagnose it.5.27›
6. 191Break the Tier-0 uplink or its routing and diagnose it.5.27›
7. 192Diagnose a distributed firewall rule that is silently dropping traffic.5.27›
8. 193Record how you would tell a firewall drop from a routing failure.5.27›
9. 194Diagnose asymmetric routing, and record how it presents.5.27›
10. 195Write the diagnostic order for two machines that cannot reach each other.5.27›

Objectives 5.28 and 5.29. Describe objectives, and simulations.

1. 196Write what ECMP is and the problem it solves.5.28›
2. 197Record what ECMP requires of the Tier-0 and of the physical network.5.28›
3. 198Record how ECMP relates to high availability, and where they differ.5.28›
4. 199Record what happens to an existing flow when a path is lost.5.28›
5. 200Record what stateful services do to ECMP, and why that matters.5.28›
6. 201Narrate the north-south packet walk out loud, in under two minutes, with no notes.5.29›
7. 202Narrate the east-west packet walk between two segments the same way.5.29›
8. 203Draw both walks and mark the point where a failure would be invisible to the guest.5.29›

Do this section twice in the final week, with faults somebody else created.

1. 204Diagnose an ESX host fault you did not cause. 15 minutes.5.6›
2. 205Diagnose a virtual machine that will not power on. 10 minutes.5.9›
3. 206Diagnose a vSAN object that is inaccessible. 20 minutes.5.3›
4. 207Diagnose a datastore that will not mount on one host. 15 minutes.5.4›
5. 208Diagnose a VKS cluster that will not provision. 25 minutes.5.15›
6. 209Diagnose an image pull failure caused by trust. 15 minutes.5.16›
7. 210Diagnose a cloud proxy that has stopped collecting. 15 minutes.5.19›
8. 211Diagnose two machines that cannot reach each other across a Tier-1. 20 minutes.5.27›
9. 212Find the first error of an incident in the logs. 15 minutes.5.23›
10. 213Narrate the north-south packet walk from memory. 5 minutes.5.29›
11. 214Produce one optimisation recommendation with evidence. 20 minutes.5.10›

Four weeksIf that is what you have

Week four is the heavy one and that is deliberate, because it is where the two borrowed sections live and where the drills are. Two pieces of advice. Write your own diagnostic order in section A on day one and keep revising it as you go, because that order is what the exam is really testing. And be able to narrate the north-south packet walk out loud, in under two minutes, with no notes. If you can do that, objectives 5.28 and 5.29 are free marks.

Exam details are from the published Broadcom exam guide for 3V0-13.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. Practice tasks here are my own, written from the published objectives; they are not exam content.