Operators want Distributed Firewall policy to stay with a permitting VM when it vMotions to another prepared host. Which NSX Data Center benefit matches that use case?
Select an answer to reveal the explanation.
Short Explanation
The badge should travel with the clerk, not stay taped to the old desk. NSX groups and DFW follow the VM across prepared hosts. That policy mobility is the benefit, not rewriting rules after every vMotion.
Full Explanation
Distributed Firewall policy that stays with a permitting VM across vMotion is the policy-mobility benefit: groups and rules follow the workload across prepared hosts because enforcement is tied to VM identity and vNIC context, not to a fixed host ACL. Operators should not rewrite every DFW rule by hand after each vMotion. Pinning the VM to one host so security never has to move sacrifices mobility for a false sense of simplicity. Storing firewall policy only on the physical top-of-rack switch cannot follow the VM when it leaves that rack. Exam caveat: policy mobility assumes the destination host is an NSX transport node in the appropriate zones; unprepared hosts break the model. Operational check: vMotion a tagged permitting VM between prepared hosts, confirm the same DFW rules still hit in logs or Traceflow without rule edits, and reject any runbook step that says to re-apply a ToR ACL after the move; add a pre-migration checklist for transport-node readiness. In municipal operations, record the chosen control and the rejected distractors in the change ticket so future on-call staff understand which failure modes would affect city services. Re-validate after the next maintenance window that the same design still holds for the current NSX build and the agency workloads that depend on it.