The city runs a three-node NSX Manager cluster. One node is down for maintenance. How do the Manager nodes interact so operators can still use the UI and API?
Select an answer to reveal the explanation.
Short Explanation
Three Managers are like three clerks who share the same counter. If one is out, the others still take requests. Clustering is how UI and API stay up, not vCenter or Edge taking over Manager.
Full Explanation
NSX Manager cluster nodes share management and central control so remaining members can continue UI and API service when one appliance is down for maintenance. Three Managers behave like three clerks sharing the same civic counter—if one is out, the others still take requests for segments, groups, and policy changes. That cluster interaction is how operators keep using the UI and API during a single-node outage without declaring a total management blackout. It is incorrect that all UI and API access stop until every Manager node returns. Transport nodes do not elect a new vCenter to replace NSX Manager, and vCenter clustering is not a substitute management plane for NSX objects. Edge nodes run centralized data-plane services such as NAT or VPN; they do not host the Manager UI while a Manager node is down. Exam caveat: supported cluster sizing and majority still matter for health, but the exam point is continued management availability from remaining Manager nodes—not Edge or vCenter substitution. Operational check: in a lab three-node Manager cluster, place one node in maintenance, confirm UI and API remain reachable through the surviving VIP or nodes, and verify operators did not point browsers at Edges as a Manager replacement.