An elections warm-site uses different vCenter tags than production. Recovered results VMs sit in empty security groups. What should the administrator document before the next failover test?
Select an answer to reveal the explanation.
Short Explanation
Groups fill from tags like precincts fill from voter rolls. If the warm-site uses different tag names, document the map so the groups actually get members.
Full Explanation
When an elections warm-site uses different vCenter tags than production and recovered results VMs sit in empty security groups, the administrator should document a production-to-warm-site tag map so NSX-T security groups populate and policy applies after recovery. Treat the tag map as the bilingual dictionary between production badge names and warm-site badge names so results desks land in the right groups. A Carbon Black Cloud sensor-group rename so tags are unused at the warm-site fails by concept because renaming CBC groups does not populate NSX security groups from mismatched vCenter tags. A Distributed Firewall exclusion for every recovered VM so empty groups do not matter fails because mass exclusion abandons DFW instead of fixing membership. A T0/T1 redesign so tag-based groups are unnecessary after failover fails because redesigning routing to avoid tags is not the DR membership fix and drops the intended group model. Exam caveat: document and apply a production-to-warm-site tag map so security groups populate after recovery. Operational check: maintain the tag map in the elections DR package, apply mapped tags on recovery, confirm security-group membership and DFW hits on results VMs, and retest after any warm-site tag taxonomy change.