County fails over permitting VMs to a disaster-recovery NSX-T fabric. Recovered VMs match no security groups and hit default-deny. What should have been replicated to the DR site?
Select an answer to reveal the explanation.
Short Explanation
Recovered permitting VMs are strangers in a new courthouse unless their name tags come with them. Copy the tag taxonomy, groups, and Distributed Firewall policy to DR or default-deny will black-hole them.
Full Explanation
When county fails over permitting VMs to a disaster-recovery NSX-T fabric and recovered VMs match no security groups and hit default-deny, the DR site should have received the same tag taxonomy, security groups, and Distributed Firewall policy. Treat tags and groups as the permitting-office badges that must exist at the warm site or every recovered desk hits the locked default door. Replicating only vSphere HA restart priority with no security groups or tags fails by concept because HA restart order does not create NSX membership or DFW allows. A standing Application any-any allow at DR as the recovery design fails because permanent any-any abandons micro-segmentation instead of restoring intended policy. Alternate-processing-site language in a GRC plan without NSX-T groups fails because GRC wording does not populate security groups or realize DFW on the DR fabric. Exam caveat: DFW membership is driven by tags and groups—replicate taxonomy and policy to DR or recovered VMs miss allows. Operational check: compare production and DR tag taxonomies and security groups before failover tests, recover a permitting VM, confirm group membership and DFW hits, and document NSX policy replication in the county DR runbook.