A county architect lists vSphere, vSAN, and NSX-T Data Center as the VMware software-defined data center stack. How do those products map to the SDDC pillars?
Select an answer to reveal the explanation.
Short Explanation
Remember the three civic utilities: vSphere for compute, vSAN for storage, NSX-T for the network. Mix those labels and the county stack briefing falls apart.
Full Explanation
In the VMware SDDC stack, vSphere virtualizes compute, vSAN virtualizes storage, and NSX-T Data Center virtualizes networking. That mapping is how a county architect should brief the three pillars: hosts and VMs under vSphere/vCenter, software-defined storage under vSAN, and overlay networking plus distributed security under NSX-T. Swapping those labels breaks procurement and operations conversations across municipal IT. Calling vSphere storage, vSAN networking, and NSX-T endpoint antivirus inverts the products. Mapping vSphere to Horizon VDI, vSAN to Workspace ONE, and NSX-T to Carbon Black confuses EUC and security siblings with the SDDC pillars. Treating vSphere as underlay switch OS, vSAN as BGP, and NSX-T as SaaS email is unrelated product fiction. Exam caveat: cities may use external storage or partial NSX adoption during transition, but the exam association for the named stack remains compute/storage/network as above. Operational check: in a design review, point to which product owns VM inventory, which owns datastore policy, and which owns segments and distributed firewall—those three answers should be vSphere, vSAN, and NSX-T respectively. Document the finding in the municipal change record so auditors can see the software-defined control was verified on civic workloads.