Fortinet Enterprise Firewall 7.6 FCSS_EFW_AD-7.6 BGP Route Maps Communities Filtering Practice Test

 

This practice test focuses on bgp route maps communities filtering and resilience through original applied scenarios aligned to the final published Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator 7.6 blueprint. It is intended for study and does not reproduce live exam content. For broader exam preparation, review the Fortinet FCSS_EFW_AD-7.6 Exam Dumps page.

Question 1

The security team at Woodgrove Bank wants to accept only approved prefixes from an external BGP peer. Which configuration or operational action most directly satisfies that goal? Assume the platform versions are compatible with the feature. Only one site is affected; peer sites are healthy.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use BGP aggregation and outbound filtering according to the design

Correct answer: D

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
2. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
4. Inbound policy limits which peer routes enter the local BGP table. This directly addresses the stated requirement.
5. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, apply an inbound prefix list or route map that permits the approved prefixes and denies the rest. Inbound policy limits which peer routes enter the local BGP table.

Question 2

An incident at Alpine Ski House requires the NOC engineer to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes. What should be done first? No unrelated control should be weakened. The change must be validated on a pilot device before broader rollout.

• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Use BGP aggregation and outbound filtering according to the design
• Enable compatible graceful-restart behavior only where both sides and the design support it

Correct answer: D

Explanation

1. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
2. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
3. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
4. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This directly addresses the stated requirement.
5. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use BGP aggregation and outbound filtering according to the design. Aggregation plus filtering reduces route exposure while retaining the intended reachability.

Question 3

For a FortiGate/FortiManager/FortiAnalyzer 7.6 deployment at Datum Corporation, which option correctly addresses the need to mark selected routes so downstream policy can treat them consistently? The team will validate the result immediately after the change. Existing production IP addressing must remain unchanged.

• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use BGP aggregation and outbound filtering according to the design

Correct answer: C

Explanation

1. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
2. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This directly addresses the stated requirement.
4. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
5. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, set a BGP community with a route map and match that community where policy needs it. Communities provide policy metadata that can be propagated and matched by BGP policy.

Question 4

Contoso Finance has verified basic IP reachability. The remaining requirement is to change route attributes only for one class of prefixes. Which action should the team take? The change is taking place in a controlled maintenance window. The resulting configuration must remain centrally auditable.

• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Use BGP aggregation and outbound filtering according to the design
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Set a BGP community with a route map and match that community where policy needs it

Correct answer: A

Explanation

1. Route maps provide conditional BGP policy rather than changing attributes globally. This directly addresses the stated requirement.
2. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
3. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
4. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
5. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use a route map that matches the intended prefixes or communities and sets only the required BGP attributes. Route maps provide conditional BGP policy rather than changing attributes globally.

Question 5

At Litware Logistics, the Fortinet administrator must reduce disruption when the BGP control plane restarts on a peer that supports graceful restart. Which action best addresses the requirement? Choose the smallest targeted change. A known-good rollback point is available before the change.

• Set a BGP community with a route map and match that community where policy needs it
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use BGP aggregation and outbound filtering according to the design
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes

Correct answer: B

Explanation

1. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
2. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This directly addresses the stated requirement.
3. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
4. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
5. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, enable compatible graceful-restart behavior only where both sides and the design support it. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers.

Question 6

During an enterprise firewall change at Wide World Importers, the team needs to accept only approved prefixes from an external BGP peer. What should it do? The answer must address the stated cause rather than a different feature. The design must preserve the current segmentation boundaries.

• Use BGP aggregation and outbound filtering according to the design
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Set a BGP community with a route map and match that community where policy needs it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Enable compatible graceful-restart behavior only where both sides and the design support it

Correct answer: B

Explanation

1. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
2. Inbound policy limits which peer routes enter the local BGP table. This directly addresses the stated requirement.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
4. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
5. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, apply an inbound prefix list or route map that permits the approved prefixes and denies the rest. Inbound policy limits which peer routes enter the local BGP table.

Question 7

A production review at Relecloud identifies this requirement: advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes. Which Fortinet action is most appropriate? Preserve the existing design unless the requirement says otherwise. The team is not allowed to disable the security feature globally.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use BGP aggregation and outbound filtering according to the design
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Set a BGP community with a route map and match that community where policy needs it

Correct answer: C

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
2. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
3. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This directly addresses the stated requirement.
4. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
5. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use BGP aggregation and outbound filtering according to the design. Aggregation plus filtering reduces route exposure while retaining the intended reachability.

Question 8

While troubleshooting at Adventure Works, the NOC engineer needs to mark selected routes so downstream policy can treat them consistently. What is the best next step? Prefer a change that is reversible and easy to verify. The symptom appeared immediately after a planned configuration change.

• Use BGP aggregation and outbound filtering according to the design
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes

Correct answer: B

Explanation

1. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
2. Communities provide policy metadata that can be propagated and matched by BGP policy. This directly addresses the stated requirement.
3. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
4. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
5. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, set a BGP community with a route map and match that community where policy needs it. Communities provide policy metadata that can be propagated and matched by BGP policy.

Question 9

Fourth Coffee is standardizing a FortiOS 7.6 enterprise deployment. Which approach should it use to change route attributes only for one class of prefixes? The team needs an auditable result. Logs from the affected traffic are available for verification.

• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Set a BGP community with a route map and match that community where policy needs it
• Use BGP aggregation and outbound filtering according to the design
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Enable compatible graceful-restart behavior only where both sides and the design support it

Correct answer: D

Explanation

1. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
2. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
3. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
4. Route maps provide conditional BGP policy rather than changing attributes globally. This directly addresses the stated requirement.
5. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use a route map that matches the intended prefixes or communities and sets only the required BGP attributes. Route maps provide conditional BGP policy rather than changing attributes globally.

Question 10

A change ticket for Coho Winery states that administrators must reduce disruption when the BGP control plane restarts on a peer that supports graceful restart. Which choice is correct? Use normal enterprise Fortinet administration practice. The equivalent configuration works correctly at a separate site.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use BGP aggregation and outbound filtering according to the design
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Set a BGP community with a route map and match that community where policy needs it

Correct answer: A

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This directly addresses the stated requirement.
2. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
3. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
4. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
5. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, enable compatible graceful-restart behavior only where both sides and the design support it. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers.

Question 11

The security team at Fabrikam Manufacturing wants to accept only approved prefixes from an external BGP peer. Which configuration or operational action most directly satisfies that goal? Assume the platform versions are compatible with the feature. The change must be reversible within the same maintenance window.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Use BGP aggregation and outbound filtering according to the design
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Set a BGP community with a route map and match that community where policy needs it

Correct answer: D

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
2. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
3. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
4. Inbound policy limits which peer routes enter the local BGP table. This directly addresses the stated requirement.
5. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, apply an inbound prefix list or route map that permits the approved prefixes and denies the rest. Inbound policy limits which peer routes enter the local BGP table.

Question 12

An incident at Wingtip Energy requires the network operations engineer to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes. What should be done first? No unrelated control should be weakened. The device is already synchronized with its central-management database.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use BGP aggregation and outbound filtering according to the design
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes

Correct answer: B

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
2. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This directly addresses the stated requirement.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
4. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
5. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use BGP aggregation and outbound filtering according to the design. Aggregation plus filtering reduces route exposure while retaining the intended reachability.

Question 13

For a FortiGate/FortiManager/FortiAnalyzer 7.6 deployment at Lucerne Publishing, which option correctly addresses the need to mark selected routes so downstream policy can treat them consistently? The team will validate the result immediately after the change. The current routing table contains the expected connected networks.

• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Set a BGP community with a route map and match that community where policy needs it
• Use BGP aggregation and outbound filtering according to the design
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes

Correct answer: C

Explanation

1. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
2. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This directly addresses the stated requirement.
4. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
5. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, set a BGP community with a route map and match that community where policy needs it. Communities provide policy metadata that can be propagated and matched by BGP policy.

Question 14

Bellows College has verified basic IP reachability. The remaining requirement is to change route attributes only for one class of prefixes. Which action should the team take? The change is taking place in a controlled maintenance window. Basic IP reachability to the remote endpoint has already been verified.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use BGP aggregation and outbound filtering according to the design

Correct answer: B

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
2. Route maps provide conditional BGP policy rather than changing attributes globally. This directly addresses the stated requirement.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
4. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
5. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use a route map that matches the intended prefixes or communities and sets only the required BGP attributes. Route maps provide conditional BGP policy rather than changing attributes globally.

Question 15

At Tailspin Toys, the enterprise firewall engineer must reduce disruption when the BGP control plane restarts on a peer that supports graceful restart. Which action best addresses the requirement? Choose the smallest targeted change. Hardware replacement is outside the approved change scope.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Use BGP aggregation and outbound filtering according to the design
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest

Correct answer: A

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This directly addresses the stated requirement.
2. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
3. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
4. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
5. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, enable compatible graceful-restart behavior only where both sides and the design support it. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers.

Question 16

During an enterprise firewall change at Humongous Insurance, the team needs to accept only approved prefixes from an external BGP peer. What should it do? The answer must address the stated cause rather than a different feature. The requirement applies only to one policy, peer, or managed device group.

• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Set a BGP community with a route map and match that community where policy needs it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use BGP aggregation and outbound filtering according to the design

Correct answer: A

Explanation

1. Inbound policy limits which peer routes enter the local BGP table. This directly addresses the stated requirement.
2. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
3. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
4. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
5. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, apply an inbound prefix list or route map that permits the approved prefixes and denies the rest. Inbound policy limits which peer routes enter the local BGP table.

Question 17

A production review at Margie Travel identifies this requirement: advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes. Which Fortinet action is most appropriate? Preserve the existing design unless the requirement says otherwise. The team must avoid broadening administrative trust or permissions.

• Use BGP aggregation and outbound filtering according to the design
• Set a BGP community with a route map and match that community where policy needs it
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes

Correct answer: A

Explanation

1. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This directly addresses the stated requirement.
2. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
3. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
4. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
5. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use BGP aggregation and outbound filtering according to the design. Aggregation plus filtering reduces route exposure while retaining the intended reachability.

Question 18

While troubleshooting at Northwind Health, the network operations engineer needs to mark selected routes so downstream policy can treat them consistently. What is the best next step? Prefer a change that is reversible and easy to verify. The design must preserve existing centralized logging and telemetry.

• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use BGP aggregation and outbound filtering according to the design
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Set a BGP community with a route map and match that community where policy needs it
• Enable compatible graceful-restart behavior only where both sides and the design support it

Correct answer: D

Explanation

1. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
2. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
3. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
4. Communities provide policy metadata that can be propagated and matched by BGP policy. This directly addresses the stated requirement.
5. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, set a BGP community with a route map and match that community where policy needs it. Communities provide policy metadata that can be propagated and matched by BGP policy.

Question 19

Blue Yonder Airlines is standardizing a FortiOS 7.6 enterprise deployment. Which approach should it use to change route attributes only for one class of prefixes? The team needs an auditable result. Production subnets cannot be renumbered as part of this change.

• Use BGP aggregation and outbound filtering according to the design
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes

Correct answer: E

Explanation

1. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
2. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
4. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
5. Route maps provide conditional BGP policy rather than changing attributes globally. This directly addresses the stated requirement.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use a route map that matches the intended prefixes or communities and sets only the required BGP attributes. Route maps provide conditional BGP policy rather than changing attributes globally.

Question 20

A change ticket for Trey Research states that administrators must reduce disruption when the BGP control plane restarts on a peer that supports graceful restart. Which choice is correct? Use normal enterprise Fortinet administration practice. A maintenance window is open, but service interruption must be minimized.

• Use BGP aggregation and outbound filtering according to the design
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Set a BGP community with a route map and match that community where policy needs it

Correct answer: C

Explanation

1. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
2. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
3. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This directly addresses the stated requirement.
4. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
5. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, enable compatible graceful-restart behavior only where both sides and the design support it. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers.

Question 21

The security team at Apex Retail wants to accept only approved prefixes from an external BGP peer. Which configuration or operational action most directly satisfies that goal? Assume the platform versions are compatible with the feature. The team must preserve existing certificate-trust relationships unless the requirement explicitly changes them.

• Use BGP aggregation and outbound filtering according to the design
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Set a BGP community with a route map and match that community where policy needs it
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest

Correct answer: E

Explanation

1. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
2. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
4. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to accept only approved prefixes from an external BGP peer.
5. Inbound policy limits which peer routes enter the local BGP table. This directly addresses the stated requirement.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, apply an inbound prefix list or route map that permits the approved prefixes and denies the rest. Inbound policy limits which peer routes enter the local BGP table.

Question 22

An incident at Proseware Media requires the network security architect to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes. What should be done first? No unrelated control should be weakened. The change will be reviewed later using the configuration and event audit trail.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use BGP aggregation and outbound filtering according to the design
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest

Correct answer: B

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
2. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This directly addresses the stated requirement.
3. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
4. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.
5. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to advertise only an approved aggregate to a peer while suppressing more-specific internal prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use BGP aggregation and outbound filtering according to the design. Aggregation plus filtering reduces route exposure while retaining the intended reachability.

Question 23

For a FortiGate/FortiManager/FortiAnalyzer 7.6 deployment at City Power & Light, which option correctly addresses the need to mark selected routes so downstream policy can treat them consistently? The team will validate the result immediately after the change. The chosen approach must continue to work as additional branch sites are added.

• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Enable compatible graceful-restart behavior only where both sides and the design support it
• Set a BGP community with a route map and match that community where policy needs it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Use BGP aggregation and outbound filtering according to the design

Correct answer: C

Explanation

1. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
2. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
3. Communities provide policy metadata that can be propagated and matched by BGP policy. This directly addresses the stated requirement.
4. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.
5. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to mark selected routes so downstream policy can treat them consistently.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, set a BGP community with a route map and match that community where policy needs it. Communities provide policy metadata that can be propagated and matched by BGP policy.

Question 24

VanArsdel has verified basic IP reachability. The remaining requirement is to change route attributes only for one class of prefixes. Which action should the team take? The change is taking place in a controlled maintenance window. A second engineer will verify the result using independent operational evidence.

• Enable compatible graceful-restart behavior only where both sides and the design support it
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Use BGP aggregation and outbound filtering according to the design
• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest

Correct answer: B

Explanation

1. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
2. Route maps provide conditional BGP policy rather than changing attributes globally. This directly addresses the stated requirement.
3. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
4. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.
5. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to change route attributes only for one class of prefixes.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use a route map that matches the intended prefixes or communities and sets only the required BGP attributes. Route maps provide conditional BGP policy rather than changing attributes globally.

Question 25

At Woodgrove Bank, the security infrastructure engineer must reduce disruption when the BGP control plane restarts on a peer that supports graceful restart. Which action best addresses the requirement? Choose the smallest targeted change. The team requires a deterministic rollback path if validation fails.

• Set a BGP community with a route map and match that community where policy needs it
• Apply an inbound prefix list or route map that permits the approved prefixes and denies the rest
• Use a route map that matches the intended prefixes or communities and sets only the required BGP attributes
• Use BGP aggregation and outbound filtering according to the design
• Enable compatible graceful-restart behavior only where both sides and the design support it

Correct answer: E

Explanation

1. Communities provide policy metadata that can be propagated and matched by BGP policy. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
2. Inbound policy limits which peer routes enter the local BGP table. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
3. Route maps provide conditional BGP policy rather than changing attributes globally. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
4. Aggregation plus filtering reduces route exposure while retaining the intended reachability. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to reduce disruption when the BGP control plane restarts on a peer that supports graceful restart.
5. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers. This directly addresses the stated requirement.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, enable compatible graceful-restart behavior only where both sides and the design support it. Graceful restart can preserve forwarding state temporarily while BGP control-plane adjacency recovers.