Court case-management VMs are tagged, and the administrator wants an exported Distributed Firewall allow list from observed east-west flows among those VMs. Which workflow is correct?
Select an answer to reveal the explanation.
Short Explanation
Intelligence watched who talked to whom and can hand over a first-draft allow list. Review that draft in NSX policy. A Carbon Black process tree is not a DFW export.
Full Explanation
Court case-management VMs that are tagged and need an exported Distributed Firewall allow list from observed east-west flows should follow the NSX Intelligence recommendations workflow, then review the suggested policy before publishing. Intelligence turns observed conversations among tagged case-management workloads into a first-draft allow list that court security can peer-review against least privilege before it becomes production DFW. That review-then-publish discipline protects civic justice workloads from blind auto-publish. Exporting a Carbon Black Cloud process tree and pasting it into a DFW rule fails by concept because process trees describe host execution, not NSX overlay flow membership suitable as a DFW export. Using Workspace ONE UEM compliance as the DFW source fails by concept because UEM compliance is device posture for management, not NSX Distributed Firewall policy generation from east-west flows. Disabling the Distributed Firewall and relying on a T0 default route fails by concept because default routing restores connectivity without micro-segmentation and abandons the court's east-west control requirement. Exam caveat: Intelligence recommendations are a draft—always review before publish; CBC, UEM, and T0 defaults are not DFW allow-list exports. Operational check: run Intelligence recommendations for the tagged case-management group, export and peer-review the allow list, publish to a pilot, confirm hit counts, and file the approved policy with the court security architecture for municipal records protection.