A field crew's laptops need to reach the work-order dispatch server over three separate custom TCP services the application uses for data sync, file transfer, and status polling. The security engineer wants a single firewall policy line, and wants to add a fourth service later without touching the policy. What should the service field reference?
Select an answer to reveal the explanation.
Short Explanation
Just like address groups, a service group bundles individual services under one name, so you point the policy at the group once and manage the actual list of services inside the group from then on.
Full Explanation
FortiOS supports service group objects that bundle multiple service definitions, built-in or custom, under a single referenceable name, and a policy's service field accepts a service group exactly as it accepts an individual service. Pointing the policy at a service group means future changes, like adding a fourth custom service, happen entirely inside the group's membership and never touch the policy itself, which is the actual requirement here. Listing the three services directly in the policy's service field does produce correct matching today, but it fails the stated goal, because adding a fourth service later still means editing the policy to add another entry, the same maintenance coupling a group is meant to remove. Building one oversized custom service object spanning every port in use, plus a margin, is a poor substitute: it is harder to audit than three clearly named services, and the 'margin for future additions' language usually ends up permitting ports nothing legitimate ever uses. The built-in ALL service object matches every port and protocol; it is not more editable than any other object, and using it here would eliminate the port-level restriction entirely rather than just add convenience. Operationally, adding a service to the group and confirming policy hit counts increase for that service without a policy edit is a quick way to prove the grouping is working as intended.