1V0-642 · Question #92
What are the two main limitations of a vSphere Standard Switch? (Choose two.)
The correct answer is A. Centralized management D. Scalability. Exam Questions, Study Guides, Practice Tests. Lead the way to help you pass any IT Certification exams, 100% Pass Guaranteed or Full Refund. Especially Cisco, Microsoft, CompTIA, Citrix, EMC, HP, Oracle, VMware, Juniper, Check Point, LPI, Nortel, EXIN and so on. Our Slogan…
Question
What are the two main limitations of a vSphere Standard Switch? (Choose two.)
Options
- ACentralized management
- BVirtual machines per host
- CComplex installation procedure
- DScalability
How the community answered
(19 responses)- A74% (14)
- B16% (3)
- C11% (2)
Explanation
Exam Questions, Study Guides, Practice Tests. Lead the way to help you pass any IT Certification exams, 100% Pass Guaranteed or Full Refund. Especially Cisco, Microsoft, CompTIA, Citrix, EMC, HP, Oracle, VMware, Juniper, Check Point, LPI, Nortel, EXIN and so on. Our Slogan: First Test, First Pass. Help you to pass any IT Certification exams at the first try. You can reach us at any of the email addresses listed below. Any problems about IT certification or our products, you could rely upon us, we will give you satisfactory answers in 24 hours.
Topics
Community Discussion
6The correct answers are A and D. A vSphere Standard Switch is configured per host, which means every change you make on one host has to be manually repeated on every other host in your environment. That is the centralized management problem: there is no single control plane, so as your host count grows, keeping switch configurations consistent becomes an operational burden that scales badly. Scalability (D) follows from the same root cause, because a flat per-host model was never designed for large distributed environments where you need policy consistency across dozens or hundreds of hosts. The vSphere Distributed Switch was introduced specifically to solve both of these gaps by lifting configuration to the vCenter level and giving you a unified logical switch across the cluster.
The per-host config burden is the real pain point, though I'd separate A and D a bit more cleanly since centralized management is specifically what vDS fixes by design, while scalability is really just the downstream consequence you hit when you don't have it.
The "centralized management" wording trips people up because it sounds like a feature you'd want, not a limitation, but that is exactly the point: a Standard Switch has no centralized management, so you are stuck configuring each host individually, which is the same root problem as the scalability answer D. B is a red herring because VM density per host is a hardware and licensing concern, not a switch type concern. A and D are your picks.
The "scalability" choice feels a little vague since VSS actually does scale to 4096 ports, but the real issue is that its config is siloed to a single host with no way to manage it across your whole cluster from one place, so A and D are the right picks. B is just a spec limit that VDS shares too, and C is nonsense since VSS is literally the simpler one to set up.
Got A and D, no centralized management and poor scalability. Saw this exact wording on mine last Thursday and almost picked B until I remembered vSS is configured host by host, so you just lose control fast once you scale up.
The answers are A and D, and it makes sense once you think about how vSS is scoped strictly to a single host, which means every configuration change has to be repeated per host with no shared state across the cluster. My question for the group is, when you were studying the comparison between vSS and vDS, did you find that the scalability limitation was more about the per-host config drift problem, or did you interpret it as a hard cap on the number of ports and uplinks the standard switch supports?