NSX must see city clusters and VMs so operators can attach segments and build groups. Which SDN building block is registered as that inventory source?
Select an answer to reveal the explanation.
Short Explanation
NSX does not guess which VMs exist—it asks the compute manager, and in a vSphere civic DC that manager is vCenter. Horizon, Carbon Black, and a file share are not that inventory feed.
Full Explanation
NSX must see city clusters, hosts, and virtual machines so operators can prepare transport nodes, attach segments, and build inventory-based groups. The SDN building block registered as that inventory source is a compute manager—typically vCenter Server registered with NSX Manager in this exam-era civic design. Without that feed, the fabric cannot reliably discover where catalog or permit workloads live. A Horizon Connection Server inventories desktop pools and user sessions; it does not supply ESXi clusters as NSX transport-node inventory. A Carbon Black Cloud org key inventories endpoints for security operations, not hypervisor hosts as fabric objects. A vSAN file service share publishes file data and cannot act as the NSX compute-manager building block that lists VMs and clusters. Exam caveat: a degraded compute-manager connection breaks preparation visibility and security grouping even when NSX Manager itself remains reachable. Associate depth is identifying vCenter as the compute manager, not tuning every inventory sync interval. Operational check: in NSX Manager, verify the compute manager shows Connected, browse discovered clusters and VMs, create a test VM in vCenter, and confirm it appears for segment attachment and grouping; ensure Horizon, Carbon Black, and vSAN file shares are not configured as the compute manager.