A utility's firewall policy references a user group called 'NOC-Engineers' rather than listing each engineer's individual username. What operational advantage does referencing the group provide over listing individuals directly in the policy?
Select an answer to reveal the explanation.
Short Explanation
Naming a group in a policy instead of ten separate usernames means the policy itself almost never has to change. New engineer joins the team? Add them to the group. Someone leaves? Pull them out. The policy sits there untouched either way, which is exactly the kind of administration you want to minimize.
Full Explanation
Referencing a user group in a firewall policy decouples membership management from policy editing: onboarding a new engineer or offboarding a departing one only requires updating group membership, not touching the policy at all, which is a meaningful administrative advantage as team membership changes over time. There is no established performance difference in FortiOS between a policy matching a group versus individually listed users — the stated speed advantage is not how the matching engine works, and processing speed is not the design motivation for using groups. Group-based policies still require authentication; membership is precisely how the FortiGate determines that a user identified through some method (local, RADIUS, LDAP, or FSSO) is entitled to that policy's access — it does not remove the authentication requirement, it depends on it. A group reference also does not apply to every user regardless of membership; the mechanism relies on the FortiGate confirming actual membership before matching, exactly the situation where a user belongs to neither referenced group and matches nothing. The caveat is that this convenience only helps if membership is kept accurate and reviewed regularly, since a stale group is as much a liability as a stale individual entry. Confirm by adding a new engineer to the group and verifying they gain access without any policy change.