NSE7_SSE_AR-26 Fortinet NSE 7 - FortiSASE 26 Architect Questions and Answers

The hub must send additional paths to spokes (set additional-path send). The hub must treat each spoke as a route-reflector client so spoke routes are reflected to other spokes. The hub must specify how many additional paths to advertise (set adv-additional-path < n > ). An operational review should distinguish the rule that matches the traffic from the interface that is ultimately selected. Valid forwarding also depends on destination route eligibility, current member state and the applicable SLA or quality-selection algorithm. A diagnostic showing configured members alone is not conclusive evidence that all those members will carry a particular flow. When troubleshooting, correlate the configured SD-WAN service with diagnose sys sdwan service4, the live session entry and the routing table. An application signature, an IP route and a health-check result describe different decision stages; treating them as interchangeable can produce incorrect conclusions about the egress interface. In the relevant Fortinet FortiOS documentation, the applicable feature should be verified against the deployed software version, the selected configuration mode and the live operational state before the answer is treated as a definitive implementation requirement.

FortiSASE Branch On-ramp extends cloud-delivered security services to users located behind branch routers or firewalls through IPsec tunnel connectivity.

Option A is correct because FortiSASE supports deployment of multiple branch on-ramp locations. A branch device can establish connections to multiple provisioned on-ramp locations, subject to the supported device type, licensing, and tunnel configuration. This facilitates geographic resilience and alternative connectivity paths.

Option D is correct because Branch On-ramp and Secure Private Access share important Border Gateway Protocol (BGP) configuration settings. These include FortiSASE autonomous system information and BGP router ID subnet allocation.

Fortinet specifies that the SPA network configuration must be established before deploying branch on-ramp locations, although individual SPA service connections can be configured afterward.

Option B is incorrect because SSL deep inspection requires endpoints to trust the certificate authority used by FortiSASE to inspect and re-sign intercepted TLS connections. Without the appropriate trusted CA certificate, users can experience certificate validation errors.

Option C is incorrect because Branch On-ramp supports IPsec-capable branch devices, including supported FortiGate and third-party devices. FortiAP and FortiExtender are associated primarily with thin-edge deployments.

FortiGate SD-WAN zones are logical containers that group interfaces for traffic steering, route selection, and security-policy enforcement. The exhibit distinguishes zones from their underlying SD-WAN members through a hierarchical display.

Option C is correct. WAN1 is an empty, user-created zone and can be deleted because it has no SD-WAN member associations. The other zones must be evaluated according to their membership and whether they are system-defined.

WAN2 has an expansion indicator, showing that the zone contains member entries even though those entries are currently collapsed. Consequently, option A is incorrect: the absence of visible subordinate interfaces does not prove that a zone has no members.

HUB1 also has an expansion indicator. Its members are hidden by the collapsed view, so option D is incorrect.

The red icon is not a universal deletion indicator. In particular, the built-in virtual-wan-link zone must not be treated as an ordinary removable custom zone. An administrator must distinguish interface or zone operational status from configuration eligibility for deletion.

Before removing a custom zone, its members and any references in firewall policies or SD-WAN rules must be examined.

The FortiManager installation error is associated with the gateway value produced by metadata substitution, not with a general failure of FortiManager-to-FortiGate connectivity. A template uses a variable such as ' $(sdwan_port1_gw) ' to provide the interface gateway at installation time. If the current device has no valid value in its per-device metadata mapping, the generated FortiOS configuration contains an invalid IPv4 gateway and the copy or validation operation fails. Therefore the remediation is to inspect the variable definition and its per-device mapping, which is option C in the normalized question. The administrator can verify the mapping for the affected FortiGate, supply a valid address, regenerate the installation preview and reinstall. It is unnecessary to remove all template installation targets: FortiManager supports them alongside metadata variables. Nor must the members of a zone all use identical gateway configuration methods. This conclusion is specifically tied to the error shown in the original exhibit. The uploaded FortiSASE guides describe centralized management generally, but detailed per-device template substitution belongs to the FortiManager 7.6 Administration Guide.

FortiManager supports advance model-device creation and per-device metadata variable mappings for large-scale onboarding. Model devices can be assigned configuration templates and policy packages before physical installation. When DHCP-based discovery is selected, DHCP options can also be prepared to direct new FortiGates toward FortiManager. Custom metadata values provide branch-specific addresses, site identifiers and gateway settings. The terms “ZTP template” and “policy blueprint” do not accurately identify the documented FortiManager objects in the candidate answers: device blueprints and policy packages are distinct components. Consequently, options A, B and D are valid under a DHCP-based ZTP design. This choice is dependent on the selected bootstrap method. Reference: FortiManager 7.6 — Model Devices, Metadata Variables, Zero-Touch Provisioning and Device Blueprints. FortiManager templates reduce repetitive work but must resolve to valid, device-specific configurations at installation time. Device assignments, metadata mappings, ADOM scope, policy-package interfaces and provisioning order should be inspected together rather than troubleshooting any one object in isolation.

Verification qualification: The DHCP-server step depends on the zero-touch-provisioning method; it is not universally mandatory.

The screenshot omits the application-destination selector because the corresponding FortiOS GUI feature has not been enabled. Option D is correct: open System > Feature Visibility and enable Application Detection Based SD-WAN. Fortinet documents the equivalent CLI setting as ' config system global ' followed by ' set gui-app-detection-sdwan enable ' . Once visible, individual applications, groups and categories can be selected in SD-WAN rules. This is supported for direct internet access and for standalone FortiGate appliances, so options A and B are wrong. Option C is also wrong because using the CLI is an alternative, not a required prerequisite when the GUI setting is available. Application-aware traffic steering additionally requires an application-control profile on an applicable firewall policy so traffic can be classified. Administrators should distinguish this application-signature selector from the Internet Service Database destination field: ISDB objects are another supported way to define destinations, but ISDB matching is not synonymous with application- control signature recognition. Review the GUI feature flag, firewall policy inspection profile and the matched service rule before evaluating the resulting forwarding member. This behavior is documented specifically in FortiOS 7.6 Application Steering Using SD-WAN Rules.

FortiGate SD-WAN traffic steering depends on both service-rule matching and routing-table reachability. A matching SD-WAN rule identifies eligible interfaces, but the selected member must also have a usable route toward the destination.

Option A is correct because service rule 3 matches the specified source and destination address ranges, and the routing table identifies HUB1-VPN3 as the route toward the corporate server subnet.

The source address 10.0.1.0/24 falls within the source range 10.0.0.0/8 , while destination 10.2.5.254 also falls within the configured destination range.

The exhibit identifies service rule 3 as an SLA-based service with multiple available overlay members. However, the route to 10.2.5.0/24 identifies HUB1-VPN3 as the reachable next-hop interface.

Although HUB1-VPN2 appears in the service ' s eligible member list, it does not provide the matching destination route shown in the routing table. Therefore, option B is incorrect.

Options C and D reference service rule 4 and physical WAN interfaces. They do not represent the selected corporate overlay path for the stated source and destination.

This demonstrates a fundamental SD-WAN behavior: matching a service rule does not eliminate the requirement for valid route resolution through its forwarding member.

From the SD-WAN monitor in FortiManager: " The SD-WAN monitor provides a summary view of the branch devices and their members. In the scenario shown, it is clear that branch2_fgt is missing SLA configuration for one member, as evidenced by the lack of performance metrics. The monitor also shows only two branches in the current topology, allowing quick assessment of branch health and configuration completeness. " This kind of visibility is vital for proactive monitoring and rapid troubleshooting in SD-WAN environments.References: FortiManager templates reduce repetitive work but must resolve to valid, device-specific configurations at installation time. Device assignments, metadata mappings, ADOM scope, policy-package interfaces and provisioning order should be inspected together rather than troubleshooting any one object in isolation. A successful management connection does not guarantee a successful configuration installation. Review the installation preview and task log, then validate the resulting device configuration and operational diagnostics. This separates a deployment-time validation failure from a live tunnel, routing or SLA fault.

FortiSASE Branch On-ramp provides a cloud-integrated connectivity method for branch networks that require centralized security enforcement without building a traditional enterprise WAN infrastructure at every location.

Option B is correct because Branch On-ramp enables supported branch routers and FortiGate devices to establish secure IPsec tunnels to FortiSASE security points of presence.

After establishing the connection, branch traffic can be inspected using cloud-delivered firewall and security services. The architecture reduces the need to deploy and maintain a complete set of security inspection capabilities at each remote site.

Branch endpoints generally forward traffic through their local IPsec device, which serves as the default gateway. FortiClient installation is not required solely for branch on-ramp connectivity.

Option A is incorrect because the primary architecture forwards selected branch traffic toward FortiSASE rather than limiting connectivity to direct local internet breakout.

Option C is incorrect because Branch On-ramp does not universally replace endpoint protection software. Endpoint security remains an independent requirement.

Option D is incorrect because application performance optimization is associated primarily with SD-WAN path selection and digital experience monitoring rather than the principal Branch On-ramp function.

The architectural objective is to simplify branch deployment while maintaining consistent security inspection and access policies across geographically distributed sites.

After using the SD-WAN overlay template, two mandatory post-run tasks remain: " First, administrators must create and assign policy packages to branch devices, as security and access policies are not included in overlay templates. Second, SD-WAN rules must be configured so that traffic can be matched and steered appropriately through the established overlays. Neglecting either task results in ungoverned traffic or inefficient routing, undermining the benefits of SD-WAN. " Templates automate topology, but policy and rule definition are critical for operational effectiveness.References: FortiManager templates reduce repetitive work but must resolve to valid, device-specific configurations at installation time. Device assignments, metadata mappings, ADOM scope, policy-package interfaces and provisioning order should be inspected together rather than troubleshooting any one object in isolation. A successful management connection does not guarantee a successful configuration installation. Review the installation preview and task log, then validate the resulting device configuration and operational diagnostics. This separates a deployment-time validation failure from a live tunnel, routing or SLA fault.

FortiSASE Secure Private Access (SPA) integrates with FortiGate SD-WAN hubs through IPsec overlays and Border Gateway Protocol routing. This enables FortiSASE security points of presence to advertise endpoint networks and learn routes to corporate applications.

Option A is correct because FortiSASE supports two principal BGP routing designs: BGP per overlay and BGP on loopback. Both designs support appropriate iBGP and eBGP peering arrangements.

With BGP per overlay, routing adjacencies use addresses associated with individual IPsec tunnel interfaces. This approach establishes BGP sessions over each configured overlay.

With BGP on loopback, routing adjacencies terminate on logical loopback interfaces rather than individual tunnel interfaces. This separates BGP session establishment from the underlying IPsec transport and provides improved routing stability when overlay paths change.

iBGP is used when FortiSASE and the connected FortiGate hub belong to the same autonomous system. eBGP enables interconnection when different autonomous systems are involved.

Option B incorrectly excludes BGP on loopback. Option C incorrectly excludes eBGP.

Option D incorrectly presents Dynamic BGP as an independently selectable FortiSASE SPA routing design. Although Dynamic BGP is supported in FortiOS SD-WAN architectures, the FortiSASE SPA configuration identifies BGP per overlay and BGP on loopback as its two routing-design choices.

The matching router policy uses set action deny, which is not equivalent to a firewall security-policy deny. Within config router policy, the deny action stops policy-route processing and returns the packet to normal forwarding-information-base route evaluation. Both source 10.0.1.130 and destination 128.66.0.125 match the configured policy-route ranges. FortiGate therefore uses the FIB to select forwarding, subject to a valid route and an accepting firewall policy. The candidate answer key incorrectly claims SD-WAN load balancing, and its explanation incorrectly claims the traffic is dropped. Both contradict FortiOS policy-route semantics. Reference: FortiOS 7.6 CLI Reference — config router policy, action deny; Fortinet Technical Tip — Stop Policy Route. An operational review should distinguish the rule that matches the traffic from the interface that is ultimately selected. Valid forwarding also depends on destination route eligibility, current member state and the applicable SLA or quality-selection algorithm. A diagnostic showing configured members alone is not conclusive evidence that all those members will carry a particular flow.

Policy 3 points traffic To = HUB1-VPN1, which is an SD-WAN member interface. In SD-WAN you must reference the SD-WAN zone (the logical interface) in policies, not its member tunnels. Change the policy’s To interface to the zone HUB1, and the install will succeed. FortiManager templates reduce repetitive work but must resolve to valid, device-specific configurations at installation time. Device assignments, metadata mappings, ADOM scope, policy-package interfaces and provisioning order should be inspected together rather than troubleshooting any one object in isolation. A successful management connection does not guarantee a successful configuration installation. Review the installation preview and task log, then validate the resulting device configuration and operational diagnostics. This separates a deployment-time validation failure from a live tunnel, routing or SLA fault. In the relevant Fortinet FortiManager documentation, the applicable feature should be verified against the deployed software version, the selected configuration mode and the live operational state before the answer is treated as a definitive implementation requirement.

The application-aware SD-WAN rule can initially route a connection through the implicit SD-WAN rule if its three-tuple (destination IP, port, protocol) has not yet been learned in the application cache. Once the application-control engine identifies GoToMeeting as a Collaboration application, session reevaluation can allow matching of the intended application rule. Depending on state, NAT and route changes, an existing session might not migrate successfully. This mechanism is not universally dependent on deep SSL inspection, and the configured Collaboration category is a legitimate match for GoToMeeting. The first cause is established; the second is a plausible interpretation not proven by the visible log alone. Reference: FortiOS 7.6 — Application Detection Steering; Fortinet Technical Tip — Application Learning Phases. An operational review should distinguish the rule that matches the traffic from the interface that is ultimately selected. Valid forwarding also depends on destination route eligibility, current member state and the applicable SLA or quality-selection algorithm. A diagnostic showing configured members alone is not conclusive evidence that all those members will carry a particular flow.

Verification qualification: The exhibit establishes initial application classification behavior, but not that session route refresh definitely failed.

The question asks what must be done first before two existing physical interfaces can be moved into an SD-WAN zone. The exhibit shows firewall policies referencing port1 directly, and FortiOS does not permit firewall policies to continue referring to interfaces after those interfaces become SD-WAN members. Option D is therefore a reasonable practical first action: remove or modify the direct-interface firewall-policy references. However, the screenshot also shows static routes referencing the same interface. Those route references can likewise require adjustment. FortiOS does not establish a universal ordering that says firewall policies must always be modified before static routes; both changes may be required to complete the migration. Thus the single-answer design is ambiguous even though D is the preferred remediation in the previous review. The administrator should perform an interface-reference audit, move firewall policies to the intended SD-WAN zone, recreate appropriate zone-based static routes, and then configure the SD-WAN members. The default virtual-wan-link zone and other user-defined zones need not be deleted merely because an interface changes membership. The FortiOS 7.6 Members and Zones documentation establishes the relevant referencing restriction.

Verification qualification: Both firewall policy references and static-route dependencies may need changes; the mandated first action is ambiguous.

According to the Fortinet SD-WAN 7.6 Core Administrator Study Guide, Routing and Sessions, page 193, FortiOS supports static routes referencing SD-WAN zones and individual member interfaces. However, duplicate destination routes cannot simultaneously reference a zone and one of its individual member interfaces.

Option A is correct: FortiOS requires the two static routes to have different destination prefixes. When a static route references an SD-WAN zone, FortiGate creates forwarding entries for the members belonging to that zone. Configuring an additional route with the identical destination prefix through an individual member creates a conflicting route definition.

Overlapping destination networks are permitted when their prefixes differ. For example, a zone-based route could reference 10.0.0.0/8, while a member-specific route references 10.2.0.0/16.

Option B is incorrect: Equal administrative distance does not resolve the duplicate-route restriction. ECMP is not a substitute for valid route configuration.

Option C is incorrect: FortiOS supports default static routes (0.0.0.0/0) referencing SD-WAN zones.

Option D is incorrect: SD-WAN members can include physical interfaces, VLAN interfaces, IPsec tunnels, and other supported interface types.

Therefore, the two static routes must have different destination prefixes, although overlapping networks are allowed.

Exact Source References:

Fortinet SD-WAN 7.6 Core Administrator Study Guide, pages 192–193 — Routing and Sessions.

FortiOS 7.6 Administration Guide — Adding a Static Route and SD-WAN Members and Zones.

FortiGate SD-WAN can distribute traffic over multiple WAN links while applying performance-based eligibility checks. These checks measure network conditions such as latency, jitter, and packet loss against defined service-level agreement thresholds.

Option A is correct because FortiGate can load balance sessions across available SD-WAN members that satisfy the configured SLA target. An interface that fails the required performance criteria is excluded from the eligible load-balancing set under normal SLA-compliant operation.

Option B is correct because current FortiOS versions support load balancing within the Lowest Cost (SLA) strategy. The configuration uses set mode sla together with set load-balance enable under the relevant SD-WAN service rule. Importantly, the load-balancing algorithm does not use interface cost to select individual links once SLA-based load balancing is enabled.

Option C is incorrect because Best Quality is a separate strategy that selects preferred members based on measured link-quality metrics. It is not the supported SLA-based multi-link load-balancing configuration described in the question.

Option D is incorrect because the legacy session, spillover, and volume terminology does not describe supported Best Quality load-balancing algorithms in this context.

FortiOS 7.4.1 and later integrated the former Maximize Bandwidth strategy into the current load-balancing configuration model.

Fortinet ' s unified SASE architecture supports multiple methods of securing private application access, including identity-based Zero Trust Network Access and connectivity through Secure SD-WAN.

Option B is correct because ZTNA provides an application-centric alternative to traditional remote-access VPN architectures. Instead of providing broad network connectivity, ZTNA authenticates users, evaluates device security posture, and grants access only to explicitly authorized applications.

Fortinet ZTNA integrates identity verification, endpoint posture assessment, and application-specific security policies to reduce implicit trust.

Option C is correct because Secure SD-WAN enables encrypted and centrally managed connectivity between enterprise locations, cloud environments, and private resources. When integrated with FortiSASE, existing SD-WAN hubs can provide secure private application access through cloud security points of presence.

Option A is incorrect in this scenario because SD-WAN Branch On-ramp is primarily an ingress method for connecting branch networks to FortiSASE. Although it can participate in a broader private-access architecture, it is not the general VPN-replacement technology being tested.

Option D is incorrect because SWG and CASB primarily address internet and SaaS application security rather than providing the private network connectivity and application-specific access control required here.

ZTNA delivers granular access enforcement, while Secure SD-WAN supplies resilient and secure enterprise connectivity.

The IKE debug shows processing notify type SHORTCUT_QUERY, recv shortcut-query and forward shortcut-query. These commands identify a hub receiving ADVPN shortcut discovery signaling from a spoke and forwarding it toward another spoke. A spoke that merely receives a shortcut query would not be characterized by the explicit forwarding record in the same manner. The output does not establish a two-region topology or a completed direct shortcut. The candidate key identifying a spoke contradicts the forwarded-shortcut-query diagnostic evidence. Reference: FortiOS 7.6 — ADVPN Shortcut Establishment and IKE Debugging. FortiManager templates reduce repetitive work but must resolve to valid, device-specific configurations at installation time. Device assignments, metadata mappings, ADOM scope, policy-package interfaces and provisioning order should be inspected together rather than troubleshooting any one object in isolation. A successful management connection does not guarantee a successful configuration installation. Review the installation preview and task log, then validate the resulting device configuration and operational diagnostics. This separates a deployment-time validation failure from a live tunnel, routing or SLA fault.

The SD-WAN monitor’s table view in FortiManager provides a donut visualization plus a detailed table that shows each SD-WAN member’s status and SLA pass/miss, giving the per-member health view you’re after. FortiManager templates reduce repetitive work but must resolve to valid, device-specific configurations at installation time. Device assignments, metadata mappings, ADOM scope, policy-package interfaces and provisioning order should be inspected together rather than troubleshooting any one object in isolation. A successful management connection does not guarantee a successful configuration installation. Review the installation preview and task log, then validate the resulting device configuration and operational diagnostics. This separates a deployment-time validation failure from a live tunnel, routing or SLA fault. In the relevant Fortinet FortiManager documentation, the applicable feature should be verified against the deployed software version, the selected configuration mode and the live operational state before the answer is treated as a definitive implementation requirement. The status of individual overlay interfaces can be inspected separately.

FortiManager SD-WAN Monitor Template View uses per-branch health indicators and hover details. Orange icons indicate partial degradation or an SLA failure on at least one monitored interface. The branch1 tooltip specifically identifies HUB2-VPN1, HUB2-VPN2 and HUB2-VPN3 as problematic. The map is consistent with other overlays toward the alternate hub, supporting the six-overlay/three-down interpretation, although the full six-interface list is not directly visible in the hover box. Branch3’s exact configured tunnel count cannot be inferred from an orange indicator alone. This is why A and D are stronger than claims about hub counts or branch3’s exact overlay count. Reference: FortiManager 7.6 — SD-WAN Monitor Template View. FortiManager templates reduce repetitive work but must resolve to valid, device-specific configurations at installation time. Device assignments, metadata mappings, ADOM scope, policy-package interfaces and provisioning order should be inspected together rather than troubleshooting any one object in isolation. A successful management connection does not guarantee a successful configuration installation. Review the installation preview and task log, then validate the resulting device configuration and operational diagnostics. This separates a deployment-time validation failure from a live tunnel, routing or SLA fault.

Verification qualification: The tooltip alone does not explicitly confirm the inferred total tunnel count.

Comprehensive and Detailed Explanation From Fortinet SD-WAN 7.6 Architect / Course Guide:

FortiManager SD-WAN provisioning templates allow administrators to define installation targets for individual SD-WAN members. This enables a common template to accommodate branch devices with different WAN interfaces or overlay tunnel configurations.

Option B is correct because the diagnostic output corresponds to branch1_fgt, based on the configured installation targets and the absence of SD-WAN member ID 6.

The HUB1 zone configuration shows:

HUB1-VPN1 (ID 4): No installation target restriction; deployed to all assigned devices.

HUB1-VPN2 (ID 5): Assigned to branch1_fgt, branch2_fgt, and branch3_fgt.

HUB1-VPN3 (ID 6): Assigned only to branch2_fgt and branch3_fgt.

The diagnostic output lists members 4, 5, 7, 8, and 9, but member 6 is absent.

This matches branch1_fgt because HUB1-VPN3 is not included in that device ' s installation targets.

Option A is incorrect because branch2_fgt should have member 6 installed.

Option C is incorrect because the absence of a member from the diagnostic output does not establish that it is dead; it may not be configured on that device.

Option D is incorrect because the output is consistent with the template ' s device-specific configuration.

The determining principle is that FortiManager installs SD-WAN members according to their installation targets, and an empty installation target applies the member to all devices assigned to the template.

The IKE debug shows a receiving SHORTCUT_QUERY event and NAT hole punching, without an explicit forward shortcut-query record. This is consistent with a spoke receiving the shortcut-discovery query relayed by its hub over the existing spoke-to-hub tunnel. A hub-forwarder log would ordinarily include forwarding messages; the exhibit does not prove that a final spoke-to-spoke shortcut is already established. NAT hole punching is part of preparing connectivity when at least one endpoint is behind address translation, not proof that two established peers have completed negotiation. Therefore, the supported role is the destination spoke receiving a query via its hub. Reference: FortiOS 7.6 — ADVPN Shortcut Discovery and NAT Traversal. An operational review should distinguish the rule that matches the traffic from the interface that is ultimately selected. Valid forwarding also depends on destination route eligibility, current member state and the applicable SLA or quality-selection algorithm. A diagnostic showing configured members alone is not conclusive evidence that all those members will carry a particular flow.

FortiGate evaluates SD-WAN traffic using service-rule matching, member route eligibility, and the routing table. An SD-WAN rule cannot ordinarily select a member that lacks a valid route to the destination.

Option D is correct because the ICMP packet does not have an eligible forwarding path through the matching SD-WAN service rule. Consequently, FortiGate falls back to routing according to its forwarding information base (FIB).

The diagnostic output identifies two SD-WAN services:

Service 1 uses priority-based selection across port2 and port1, but its application-control criteria specify Salesforce, Microsoft Portal, and Microsoft Outlook. The ICMP packet does not match those applications.

Service 2 matches source 10.0.1.0/24 and destination 128.66.0.0/16. Although this rule selects port7 and port8 for SLA-based load balancing, the routing table provides no valid route to the destination through either member. Both interfaces have directly connected routes to 10.0.1.0/24 only.

The routing table instead contains equal-cost default routes through port1 and port2. Therefore, conventional FIB forwarding determines the outgoing interface.

Option A is incorrect because valid default routes exist. Option B ignores member route eligibility. Option C incorrectly assumes port2 is exclusively selected.

An SD-WAN member may be removed using the FortiGate GUI once its configuration dependencies are cleared. Option A is the intended answer: FortiOS updates the member configuration and its associated forwarding entries as needed. Removal does not require the CLI, does not enforce a minimum of two members per user-defined zone, and does not automatically move the interface into the default virtual-wan-link zone. Those facts eliminate B, C and D. A working deployment can lose connectivity after this change if other services depended on routes through the deleted member; therefore an administrator should check static routing and member reachability, not simply the SD-WAN Rules or Performance SLAs tabs. FortiOS describes an SD-WAN member as a reference to an underlying physical or logical interface. Deleting the SD-WAN membership does not necessarily delete that underlying interface or its addressing. Before removing it, examine SD-WAN member references, health checks, firewall policies, SD-WAN zones and configured static routes. After the change, compare the active routing table and the available SD-WAN forwarding members. The answer assumes no outstanding dependency blocks the delete operation.

The CSV import process for FortiManager model devices requires the fields ' Serial Number ' , ' Device Blueprint ' , and ' Name ' . These are the mandatory identifiers used to create model devices and apply the appropriate initial provisioning configuration. In the exhibit, the missing device-blueprint field and an empty name for one device prevent a complete import. Options A and B are therefore the required corrections. Metadata values for addresses or user-defined variables may be included as additional columns, but they are not universally mandatory to import a model device. Consequently, options C and D impose requirements that depend on a subsequent provisioning template, not the CSV import itself. The selected blueprint must also be compatible with the target hardware platform. When deploying large numbers of devices, administrators should ensure serial numbers are unique, device names are valid and blueprint assignments resolve to templates and packages within the correct ADOM. The definitive FortiManager 7.6 import specification lists precisely those three required CSV columns; it does not impose a blanket requirement for every metadata variable to contain a value at import time.

FortiSASE geofencing provides geographical access control by permitting or denying connections to FortiSASE security points of presence (POPs) according to the originating country or region of the connecting user or edge device.

Option D is correct because FortiSASE identifies the source country using the connection ' s public IP address and evaluates it against configured regional access restrictions.

Administrators configure this functionality under Network > Geofencing > Regional access to FortiSASE.

FortiSASE supports three geographical access modes:

Allow all: Permits connections from all countries and regions. This is the default configuration.

Allow specified: Permits connections only from explicitly authorized countries or regions.

Deny specified: Blocks connections originating from selected countries or regions while permitting other locations.

Option A is incorrect because geofencing does not primarily enforce time-based application access restrictions.

Option B is incorrect because content inspection and web filtering are separate security functions.

Option C is incorrect because endpoint data encryption is unrelated to geographical connection restrictions.

Additionally, FortiSASE supports regional compliance rules that prioritize permitted POPs or on-premises gateways for users originating from specified regions. These routing preferences are distinct from geofencing ' s connection admission controls.

FortiGate supports Active, Passive, and Prefer Passive performance SLA monitoring modes. Passive monitoring measures actual network traffic rather than generating synthetic probes.

Option B is correct in the conventional preferred-link scenario because passive measurement depends on traffic traversing an SD-WAN member. When traffic is forwarded exclusively through the preferred link, FortiGate cannot measure the performance of unused alternative links. This is a limitation of passive monitoring.

Option D is correct because FortiGate uses TCP session information to measure latency, jitter, and packet loss. Latency measurements are derived from TCP connection behavior, while packet loss and jitter are determined using TCP header information.

Option A is incorrect because passive measurement relies on TCP session characteristics rather than ICMP traffic.

Option C is incorrect because enabling passive WAN health measurement disables automatic ASIC offloading on the affected firewall policies, allowing FortiGate to inspect the required TCP session information.

Option E is incorrect because the three-minute fallback to active probing belongs to Prefer Passive, not Passive mode. In Prefer Passive mode, FortiGate activates probes after three minutes without qualifying TCP traffic.

FortiManager SD-WAN Overlay Orchestration produces the core provisioning artifacts IPsec tunnel templates, BGP templates and CLI templates. IPsec tunnels implement the WAN overlays, BGP exchanges route prefixes and the CLI portion provides other device configuration needed by the topology. The candidate key includes a generic Rules template, but the standard generated template list does not identify such an object. SD-WAN rules are configured using the appropriate SD-WAN provisioning template or follow-up policy tasks, and they are not the same as the three generated template types. Static routing templates are not universally generated as core overlays. Reference: FortiManager 7.6 — Objects and Templates Created by SD-WAN Overlay Orchestrator. FortiManager templates reduce repetitive work but must resolve to valid, device-specific configurations at installation time. Device assignments, metadata mappings, ADOM scope, policy-package interfaces and provisioning order should be inspected together rather than troubleshooting any one object in isolation. A successful management connection does not guarantee a successful configuration installation. Review the installation preview and task log, then validate the resulting device configuration and operational diagnostics. This separates a deployment-time validation failure from a live tunnel, routing or SLA fault.

For SD-WAN deployments that span multiple regions—where most traffic is intra-region and there is no requirement for inter-region ADVPN—the best practice is to use IBGP with BGP on loopback interfaces for routing within each region and EBGP between the regions. This approach ensures robust and scalable routing, isolates regional routing domains, and enables policy control at region boundaries. BGP on loopback is preferred for its reliability and flexibility, as it enables peering that is not tied to specific physical interfaces. EBGP between regions allows each region to maintain independent routing policies and summarization, optimizing performance and manageability. By separating IBGP (intra-region) and EBGP (inter-region), you create a modular architecture that scales easily and simplifies fault isolation and troubleshooting.References: A deployment should preserve the distinction between the physical or logical WAN underlay, the IPsec overlay and the SD-WAN zone that groups forwarding members. These layers can have different routing and security-policy requirements. The configured architecture must also allow the required traffic paths and failover behavior rather than assuming every available interface is interchangeable.