Utility-billing operators want “who can talk to whom” policies to travel with workloads when VMs move between racks. Which SDDC trait should they identify?
Select an answer to reveal the explanation.
Short Explanation
When a billing VM moves racks, the rule should ride along like a badge on the worker, not stay glued to the old cubicle wall. SDDC policy lives on virtual constructs and workloads, not only on a physical port.
Full Explanation
Utility-billing operators want "who can talk to whom" policies to travel with workloads when VMs move between racks. That SDDC trait is security and network policy defined on virtual constructs and workloads rather than only on a physical port. Groups, tags, and distributed firewall rules bind to the VM identity so vMotion or host maintenance does not orphan the control on the old switchport. Policy bound only to a physical switch port or VLAN ID fails when the VM leaves that port. A Horizon instant-clone pool does not replace NSX grouping for server workload communication policy. Recabling the top-of-rack whenever a VM is vMotioned is the anti-pattern virtual networking removes. Exam caveat: policy still depends on correct tagging, group membership, and transport-node preparation at the destination; mobility of policy assumes the destination is part of the same prepared fabric. Operational check: vMotion a billing test VM between racks and verify the same distributed firewall rule set still enforces before and after the move without editing a physical ACL. Document the finding in the municipal change record so auditors can see the software-defined control was verified on civic workloads.