NSE4 Security Profiles Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Set DNS server to FortiGate's IP

  Why it's wrong here

  While reconfiguring clients to use the FortiGate as their DNS server is a necessary prerequisite for DNS filtering, it does not by itself cause any filtering to occur. The FortiGate will simply receive and forward the DNS queries unless a firewall policy explicitly applies a DNS filter profile to that traffic. This is a network-level configuration, not the profile configuration step the administrator must perform.

• ✓

  Apply the DNS filter profile to a firewall policy that matches DNS traffic

  Why this is correct

  To enforce DNS filtering, the administrator must create a firewall policy that matches outbound DNS traffic (typically UDP/TCP port 53 from internal clients) and attach the DNS filter profile to that policy. Only when the profile is referenced by a policy does the FortiGate's DNS proxy engine evaluate each query against the FortiGuard category database. Without this policy binding, the profile remains an unused configuration object and all DNS traffic passes unfiltered.

• ✓

  Create a DNS filter profile and set action for malicious domains to 'block'

  Why this is correct

  Creating a DNS filter profile and configuring the action for malicious domains to 'block' is the essential definition of how the FortiGate should treat queries to dangerous sites. This profile will later be assigned to a firewall policy; its action parameter tells the DNS proxy whether to allow, block, or monitor the request. However, the profile itself is only a template—it must be combined with a policy to affect traffic, which is why applying it to a matching policy is the definitive enforcement step.

• ✗

  Enable sinkhole on the DNS filter profile

  Why it's wrong here

  Enabling sinkhole on a DNS filter profile is an optional enhancement that redirects DNS answers for blocked domains to a predefined 'sinkhole' IP address, rather than just dropping the query. This is valuable for identifying infected hosts in the logs, but blocking the malicious domain is already sufficient to prevent the client from resolving it. The administrator's goal of filtering all DNS traffic does not require sinkhole, so enabling it is not a necessary action.

• ✗

  Configure SSL deep inspection for DNS over HTTPS

  Why it's wrong here

  Enabling SSL deep inspection is only relevant when clients send DNS over HTTPS (DoH), because the DNS queries are encrypted inside the TLS session and a regular DNS filter policy cannot read them. Unless the administrative goal specifically covers DoH traffic, which the question does not indicate, deep inspection is unnecessary. Moreover, even with deep inspection, the DNS filter profile must still be applied to the decrypted traffic to enforce policies, so deep inspection alone would not ensure filtering.

Go deeper

Related to this question