A library needs one NSX group of Active Directory patrons for Identity Firewall and a separate group of catalog VMs for ordinary distributed firewall rules. How should the groups be defined?
Select an answer to reveal the explanation.
Short Explanation
The group recipe has to match the dish: user-based IDFW wants directory people, while VM DFW wants virtual machines or tags. Mixing the batter the same way for both jobs fails.
Full Explanation
A library needs one NSX group of Active Directory patrons for Identity Firewall and a separate group of catalog VMs for ordinary distributed firewall—match each group’s criteria to the firewall type: directory users for IDFW, and VM or tag membership for DFW. Criteria must fit the rule engine that will consume the group.
Using a single IP set for both patrons and VMs collapses identity and workload into one blunt object. Putting patron AD accounts into a Carbon Black policy group and reusing it for both rule types does not feed NSX IDFW/DFW correctly. Building both groups from Workspace ONE Access roles so NSX can ignore criteria types skips NSX grouping design entirely.
Exam caveat: IDFW groups are directory-based; workload DFW groups are VM/tag/segment-based—do not force one criteria type on both.
Operational check: create an AD-based IDFW group for patrons and a tag/VM group for catalog servers, publish matching rule types, and verify each group resolves in the intended policy.
Criteria matching firewall type keeps library IDFW and DFW groups honest. Peer-review new groups for criteria misuse, and reject designs that shove patrons and VMs into one IP set “for simplicity” during annual security architecture reviews.