City EHR VMs recover with Site Recovery Manager. The draft runbook says power on the VMs first and apply NSX-T security policy later. What should the administrator change?
Select an answer to reveal the explanation.
Short Explanation
Turning the clinic lights on before the locks exist is not a recovery plan. Put NSX-T policy export/import or stretched policy in the SRM runbook so EHR VMs are not wide open at boot.
Full Explanation
When city EHR VMs recover with Site Recovery Manager and the draft runbook says power on the VMs first and apply NSX-T security policy later, the administrator must include NSX-T security policy export/import or stretched policy in the recovery plan so firewall state exists when VMs start. Treat EHR recovery as reopening clinic wards only after the hallway locks are already installed—not powering systems into an unprotected window. Recovering the VMs first and leaving Distributed Firewall off until the next change window fails by concept because that unprotected window is exactly the risk the security recovery plan must eliminate. Relying on Tier-0 BGP reconvergence as the only security step fails because BGP reconvergence restores routing, not Distributed Firewall groups and rules. Skipping NSX-T policy because Carbon Black Cloud will microsegment east-west after boot fails because CBC is endpoint prevention, not a substitute for NSX-T Distributed Firewall policy at recovery time. Exam caveat: SRM recovery plans for secured workloads must include NSX policy readiness before or with VM power-on. Operational check: add NSX policy import or stretch steps to the EHR recovery plan, test failover with DFW groups populated at power-on, confirm no unprotected interval, and document policy-before-or-with-boot in the city BC/DR runbook.