Parks clones a production DFW policy onto the disaster-recovery cluster but keeps the same production group names, and the cloned rules still match production members. What should the administrator change?
Select an answer to reveal the explanation.
Short Explanation
Copying the recipe is fine. Serving it on the same platter as production is not. Rename and re-scope the DR groups so the clone only tastes DR VMs.
Full Explanation
When parks clones production Distributed Firewall policy onto the disaster-recovery cluster but keeps the same production group names, the cloned rules can still match production members. Give the DR copies environment-specific group names and membership so the cloned policy targets only DR VMs and cannot accidentally hit production.
Disabling Identity Firewall at DR so cloned policies cannot fire does not fix shared group identity and may drop needed IDFW. Replacing NSX groups with Carbon Black sensor groups that ignore environment abandons NSX membership design. Collapsing prod and DR into one shared group so clone scope cannot drift guarantees cross-environment hits—the opposite of isolation.
Exam caveat: cloned policy without renamed/re-scoped groups is a classic DR foot-gun.
Operational check: rename and re-member DR groups, verify membership shows only DR VMs, publish the cloned policy, test that production is untouched, and document DR group naming in the parks recovery standard.
DR group renaming is parks’ clone hygiene. After rename/re-scope, run a membership diff against production, attempt a rule that would have hit prod names, confirm zero prod matches, and store the naming convention in the DR NSX runbook.