Fortinet NSE7 Specialty Modules (SD-WAN and Enterprise Firewall tracks) (FORTINET-NSE7-SPECIALTY) FORTINET-NSE7-SPECIALTY Questions 1–75 | Page 1/3

MCQmedium

An enterprise network uses ADVPN 2.0 with BGP running over IPsec tunnels. A spoke needs to initiate a shortcut tunnel to another spoke. Which FortiOS CLI command is used on the hub to verify the active shortcut tunnels and view the shortcut state information?

A.execute router clear bgp all

B.get system sdwan neighbor

C.diagnose vpn tunnel list

D.diagnose netlink interface list

AnswerC

On the hub, diagnose vpn tunnel list enumerates IPsec tunnels including ADVPN shortcut sessions, showing their names, selectors and state. This confirms which spoke-to-spoke shortcuts are currently established and active without inspecting individual security associations.

Why this answer

On FortiOS, 'diagnose vpn tunnel list' displays all active IPsec tunnels including ADVPN shortcut tunnels, showing their names, source/destination, and state. This is the standard command to confirm that a shortcut has been negotiated between spokes and to inspect its current status.

Exam trap

The trap is selecting commands that sound network-diagnostic (like netlink interface list or sdwan neighbor) when the question specifically asks about IPsec/ADVPN shortcut tunnel state, which only 'diagnose vpn tunnel list' surfaces.

How to eliminate wrong answers

Option A is wrong because 'execute router clear bgp all' clears BGP sessions — it is a disruptive reset command, not a verification command, and does not show tunnel state. Option B is wrong because 'get system sdwan neighbor' displays SD-WAN neighbor/health-check information, not IPsec tunnel or ADVPN shortcut state. Option D is wrong because 'diagnose netlink interface list' shows kernel-level interface information and does not enumerate IPsec tunnels or their shortcut status.

Full explanation →

Multi-Selecthard

When configuring an IPsec tunnel using IKEv2, which THREE parameters are commonly negotiated during Phase 1?

Select 3 answers

A.Encryption algorithm (e.g., AES-256)

B.Authentication method (e.g., PSK or RSA)

C.TCP port selection

D.Firewall policy ID

E.Diffie-Hellman group

AnswersA, B, E

IKEv2 Phase 1 negotiates the encryption algorithm, such as AES-256, to protect the IKE SA itself. This is one of the three commonly negotiated Phase 1 parameters, alongside integrity and Diffie-Hellman group, satisfying the stem's requirement.

Why this answer

During IKEv2 Phase 1 (IKE_SA_INIT and IKE_AUTH), the peers negotiate the encryption algorithm such as AES-256 (option A), which protects the IKE SA itself, making it a core Phase 1 parameter. The authentication method, such as PSK or RSA signatures (option B), is also negotiated and validated in Phase 1 to authenticate the peers and establish trust. The Diffie-Hellman group (option E) is likewise negotiated in Phase 1 to perform the key exchange and derive shared secret keys for the IKE SA.

TCP port selection (option C) is not negotiated in Phase 1 because IKE uses UDP ports 500 and 4500, not TCP. Firewall policy ID (option D) is a local configuration construct and is not an IKEv2 Phase 1 negotiation parameter.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates can separate Phase 1 (IKE SA) parameters from Phase 2 (IPsec SA) parameters and from local-only configuration — options like 'TCP port' and 'firewall policy ID' are distractors that don't belong to either negotiation.

Full explanation →

MCQhard

You are managing FortiGates across multiple ADOMs. How can you share common firewall objects (e.g., mail servers, common IP ranges) across these ADOMs?

A.Create objects in the Global Database

B.Manually copy objects to each ADOM

C.Use the API to script the creation in every ADOM

D.Enable 'Object Sharing' in system settings

AnswerA

Objects created in the Global Database are inherited by every ADOM, so common firewall addresses and services are defined once and referenced everywhere. This satisfies the cross-ADOM sharing requirement without duplicating objects in each ADOM, though per-ADOM objects cannot be shared upward.

Why this answer

In FortiManager, the Global Database (Global ADOM) is the designated object space for creating firewall objects that must be shared across multiple ADOMs. Objects defined there can be referenced by policies in any ADOM, providing a single source of truth for common items like mail servers and IP ranges.

Exam trap

The trap is assuming there is a per-ADOM sharing setting or that scripting is the intended solution; Fortinet exams test knowledge of the Global Database as the native cross-ADOM object mechanism.

How to eliminate wrong answers

Option B is wrong because manually copying objects into each ADOM creates duplication and drift, defeating the purpose of centralized management. Option C is wrong because scripting object creation via the API in every ADOM still results in duplicated objects and does not provide native cross-ADOM sharing. Option D is wrong because there is no 'Object Sharing' toggle in system settings that enables cross-ADOM object reuse; the correct mechanism is the Global Database.

Full explanation →

MCQmedium

Which command allows you to view the current routing table for a specific VDOM?

A.get router info routing-table all

B.get system routing

C.diag ip route

D.show router table

AnswerA

The command get router info routing-table all displays the complete routing table, and within a specific VDOM context it shows only that VDOM's routes. This satisfies the requirement to view the current routing table for a chosen VDOM.

Why this answer

On FortiGate, the routing table for a specific VDOM is inspected with 'get router info routing-table all' executed inside that VDOM context. This command dumps all routes (connected, static, and dynamic) in the RIB for the active VDOM, which is essential when troubleshooting inter-VDOM or per-VDOM routing issues.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates know the exact FortiOS command tree — 'get router info routing-table' versus plausible-sounding but non-existent commands like 'show router table' or 'diag ip route'.

How to eliminate wrong answers

Option B is wrong because 'get system routing' is not a valid FortiOS command — routing information is exposed through the 'get router info' command tree, not 'get system'. Option C is wrong because 'diag ip route' is not a FortiOS syntax; diagnostic IP commands exist but not in this form for viewing the routing table. Option D is wrong because 'show router table' is not a FortiOS command — 'show' is used for configuration objects, not runtime routing tables.

Full explanation →

Multi-Selectmedium

Which TWO options are available when configuring an SD-WAN rule in FortiManager?

Select 2 answers

A.Interface physical speed

B.Source/Destination criteria

C.Traffic steering strategy

D.MAC address spoofing

E.Hardware acceleration toggle

AnswersB, C

Source and destination criteria are configurable match conditions within an SD-WAN rule, letting administrators scope traffic by subnet, address object or geography before applying the rule. This satisfies the stem's requirement for available SD-WAN rule options in FortiManager, alongside other match fields such as application, service and DSCP.

Why this answer

In FortiManager, an SD-WAN rule (the equivalent of a policy route within the SD-WAN zone) is defined primarily by matching traffic through source/destination criteria, so option B is correct: you specify source addresses, destination addresses, users, services, and applications to identify which traffic the rule applies to. Option C is also correct because every SD-WAN rule must select a traffic steering strategy — such as best quality, lowest cost, maximize bandwidth (SLA), or manual — which determines how the rule chooses among the SD-WAN members. Option A is not a configurable match or action in an SD-WAN rule; interface speed is a link attribute used by some steering strategies but is not itself a rule setting.

Option D is incorrect because MAC address spoofing is not a FortiManager SD-WAN rule parameter. Option E is incorrect because hardware acceleration is a per-firewall-policy/interface setting, not an SD-WAN rule configuration option.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the distinction between SD-WAN rule components and unrelated interface or security settings, so candidates may mistakenly select options like interface speed or hardware acceleration, which are not part of the rule configuration.

Full explanation →

MCQeasy

A network administrator is configuring SSL inspection for a group of users. Which certificate must be installed on the client endpoints to prevent browser certificate warnings?

A.The FortiGate CA certificate used for SSL inspection

B.The FortiGate's local device certificate

C.The Fortinet_Factory CA certificate

D.A third-party public CA certificate

AnswerA

SSL deep inspection makes the FortiGate re-sign each session with its own CA certificate. Installing that CA certificate in the endpoints' trust stores lets browsers validate the re-signed chain, eliminating warnings. Without it, clients see an untrusted issuer for every inspected site.

Why this answer

When a FortiGate performs SSL deep inspection, it acts as a man-in-the-middle: it intercepts the client's TLS connection, presents its own certificate to the client, and establishes a separate TLS session to the real server. For the client browser to trust this substituted certificate without warnings, the FortiGate's CA certificate (the one used for SSL inspection, typically Fortinet_CA_SSL or a custom CA) must be installed in the client's trusted root store. This allows the browser to validate the certificate chain back to a trusted CA.

Exam trap

The trap here is confusing the FortiGate's local device certificate (used for its own services) with the SSL inspection CA certificate (used to sign intercepted site certificates); only the latter needs to be installed on clients.

How to eliminate wrong answers

Option B is wrong because the FortiGate's local device certificate is used for administrative GUI/SSL VPN access, not for signing dynamically generated inspection certificates; installing it would not establish trust for inspected sites. Option C is wrong because the Fortinet_Factory CA certificate is a built-in factory default used for the FortiGate's own default certificates (e.g., for HTTPS admin access) and is not the CA that signs the per-site certificates generated during SSL inspection. Option D is wrong because a third-party public CA certificate cannot be used to sign the on-the-fly certificates for arbitrary domains; only the FortiGate's inspection CA (which the FortiGate controls) can sign those certificates, and installing a public CA cert would not match the issuer of the presented certificate.

Full explanation →

MCQhard

What is the purpose of the 'Gateway' override in an SD-WAN member configuration?

A.To force the use of a secondary ISP.

B.To specify a manual gateway for the SD-WAN member.

C.To bypass the firewall policy.

D.To enable load balancing.

AnswerB

The Gateway override replaces the SD-WAN member's automatically detected next-hop with an administrator-specified manual gateway address. This is required when the member's traffic must egress through a particular router or next-hop that FortiGate cannot infer from the interface configuration.

Why this answer

The 'Gateway' override in an SD-WAN member configuration lets you manually specify the next-hop gateway IP address for that member interface. This is needed when the interface is on a subnet where the default gateway cannot be auto-detected, or when you want to force traffic through a specific next-hop (for example, a secondary router). It overrides the automatically learned gateway for that SD-WAN member.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the purpose of the gateway override, and candidates confuse it with ISP selection or load balancing, which are handled by SD-WAN rules, not the member gateway field.

How to eliminate wrong answers

Option A is wrong because forcing a secondary ISP is achieved through SD-WAN rules and priority/SLA settings, not the gateway override field. Option C is wrong because bypassing a firewall policy is not a function of SD-WAN member configuration; policy is enforced separately. Option D is wrong because load balancing is handled by SD-WAN rules and algorithm selection, not by specifying a manual gateway.

Full explanation →

Multi-Selectmedium

Which TWO methods can be used to update SD-WAN policies across all managed devices in FortiManager?

Select 2 answers

A.Using a CLI script to push updates

B.Modifying the SD-WAN template and installing the changes

C.Editing the individual FortiGate policy

D.Creating a new ADOM

E.Rebooting the FortiManager

AnswersA, B

A CLI script pushed through FortiManager runs the same configuration commands on every targeted managed device, updating SD-WAN policy entries in bulk. This satisfies the requirement to propagate changes across all devices without touching each firewall individually.

Why this answer

Option A is correct because FortiManager supports running CLI scripts (via Device Manager > Scripts) against managed FortiGates, allowing SD-WAN policy commands to be pushed to all devices in a single script execution. Option B is correct because SD-WAN policies are provisioned through SD-WAN templates in FortiManager, and modifying the template followed by an Install Wizard operation propagates the updated policy to all devices bound to that template. Option C is not the intended method since editing an individual FortiGate policy only affects that single device and does not centrally update policies across all managed devices.

Option D is incorrect because creating a new ADOM merely establishes a separate administrative domain and does not push any SD-WAN policy changes. Option E is incorrect because rebooting FortiManager does not modify or distribute SD-WAN policies to managed devices.

Exam trap

FORTINET-NSE7-SPECIALTY often tests centralized vs. per-device management — candidates pick 'editing the individual FortiGate policy' because it's the most direct-sounding action, missing that FortiManager's value is fleet-wide template/script pushes.

Full explanation →

MCQeasy

You are deploying a new SD-WAN interface. What is the mandatory step before you can add an interface to an SD-WAN zone?

A.Configure a performance SLA for that specific interface.

B.Remove all firewall policy, static route, and DHCP references from the interface.

C.Assign a VLAN ID to the interface.

D.Enable SD-WAN on the global system settings.

AnswerB

An interface carrying firewall policy, static route or DHCP references cannot be added to an SD-WAN zone; FortiGate rejects the operation. Removing those references first is mandatory, since SD-WAN zones require interfaces free of such conflicting configuration.

Why this answer

Before an interface can be added to an SD-WAN zone, FortiOS requires that the interface have no existing references — specifically, it must not be referenced by firewall policies, static routes, or DHCP server configurations. This is because SD-WAN zones take over the interface's role in routing and policy, and leftover references cause conflicts or install failures. Removing those references is the mandatory prerequisite.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the prerequisite order — candidates assume a performance SLA or VLAN is required first, but the real gate is removing existing policy/route/DHCP references from the interface.

How to eliminate wrong answers

Option A is wrong because a performance SLA is configured on the SD-WAN members/zone after the interface is added, not as a prerequisite to adding it — you can add an interface to a zone before defining SLAs. Option C is wrong because a VLAN ID is only relevant if the interface is a VLAN subinterface; physical WAN interfaces added to SD-WAN zones don't require a VLAN ID. Option D is wrong because SD-WAN is enabled per-interface/zone, not via a global system setting — there is no 'enable SD-WAN globally' toggle that gates zone membership.

Full explanation →

MCQhard

An administrator is migrating a standalone FortiGate into an existing FortiManager. What happens to the existing firewall policies on the FortiGate during the import process?

A.They are moved to a 'Disabled' state

B.They are deleted to ensure a clean slate

C.They are merged into the Global Policy

D.They are imported and converted into a Policy Package

AnswerD

During import, FortiManager reads the standalone FortiGate's configuration and converts its firewall policies into a managed Policy Package. This satisfies the migration requirement, since the existing policies are preserved as a package rather than discarded or left unmanaged.

Why this answer

When importing a standalone FortiGate into FortiManager, the existing firewall policies are imported and converted into a Policy Package within the ADOM. FortiManager creates a policy package named after the device (or a chosen name) containing the imported policies, objects, and interfaces, so the device can then be managed centrally. The policies are not deleted or disabled; they become the managed baseline.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that importing a device deletes or disables its policies; in reality, they are imported and converted into a managed policy package.

How to eliminate wrong answers

Option A is wrong because policies are not moved to a Disabled state during import; they remain active and are represented in the policy package. Option B is wrong because import does not delete policies — deletion would break the device's security posture and is not part of the import workflow. Option C is wrong because Global Policy is a separate ADOM-level feature for shared policies across multiple devices; import does not merge device policies into Global Policy automatically.

Full explanation →

Multi-Selectmedium

Which TWO methods are used to achieve traffic separation in a multi-VDOM environment?

Select 2 answers

A.Using VLAN sub-interfaces

B.Enabling SSL inspection globally

C.Assigning physical ports to VDOMs

D.Using different HA clusters

E.Using different firmware versions

AnswersA, C

VLAN sub-interfaces let a single physical port carry multiple tagged VLANs, each mapped to a different VDOM, so traffic is logically separated at layer 2 while sharing the same hardware interface. This satisfies multi-VDOM traffic separation without dedicating physical ports.

Why this answer

In a multi-VDOM FortiGate environment, traffic separation is achieved by assigning physical ports to VDOMs (option C), which places each interface in its own virtual domain so that traffic entering one VDOM cannot reach another VDOM unless an inter-VDOM link is explicitly configured. VLAN sub-interfaces (option A) also achieve traffic separation because each VLAN tag creates a distinct logical interface that can be bound to a specific VDOM, keeping tagged traffic isolated per VDOM. Options B, D, and E do not provide traffic separation: SSL inspection is a security inspection feature, different HA clusters relate to device redundancy rather than VDOM traffic isolation, and different firmware versions are irrelevant to VDOM traffic separation.

Exam trap

The trap is selecting security or redundancy features (SSL inspection, HA clusters) as traffic separation methods — candidates confuse 'isolation' with 'inspection' or 'redundancy,' but only interface/port assignment and VLAN sub-interfaces actually partition traffic.

Full explanation →

MCQhard

When configuring an SD-WAN rule for a specific application, how does the FortiGate identify the traffic?

A.By analyzing the packet payload size.

B.By looking at the source MAC address.

C.By using the Application Control database.

D.By forcing traffic through a specific VLAN.

AnswerC

Application Control signatures inspect payload and protocol behaviour, so the FortiGate matches traffic by application identity rather than port or IP. This satisfies the stem's requirement to identify a specific application within an SD-WAN rule, since the Application Control database supplies the signatures SD-WAN references when steering that application's sessions.

Why this answer

FortiGate SD-WAN rules match traffic to applications using the Application Control signature database, which identifies applications by inspecting packet contents (DPI) rather than by static IP/port. When you select an 'Application' or 'Application Category' in an SD-WAN rule, the FortiGate leverages the same IPS/App-Ctrl engine signatures to classify the flow. This allows dynamic identification of SaaS and cloud apps whose IPs and ports change frequently.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that SD-WAN application rules match on IP/port or payload size, when in fact they depend on the Application Control signature database and DPI.

How to eliminate wrong answers

Option A is wrong because packet payload size alone cannot reliably identify an application — many apps share similar payload sizes and encryption hides content size patterns. Option B is wrong because source MAC addresses are only relevant within the local Layer 2 segment and are rewritten at each hop, so they cannot identify applications across a routed SD-WAN topology. Option D is wrong because forcing traffic through a VLAN is a segmentation action, not an identification mechanism — VLANs do not classify application traffic.

Full explanation →

MCQeasy

An administrator configures an SD-WAN rule with a 'Lowest Cost (SLA)' strategy. What determines the metric used by FortiOS to select the best interface when multiple links meet the SLA criteria?

A.The round-robin algorithm applied sequentially across all active links

B.The lowest physical port number on the FortiGate hardware

C.The lowest packet loss, jitter, or latency value measured by the health check among the qualifying links

D.The highest interface bandwidth capacity defined in the static route table

AnswerC

With Lowest Cost (SLA), FortiOS first filters members that satisfy the SLA targets, then ranks the survivors by their measured health-check metrics. Among qualifying links it picks the one reporting the lowest packet loss, jitter, or latency, so the metric is the live probe measurement rather than a static cost value.

Why this answer

With the 'Lowest Cost (SLA)' strategy, FortiOS first filters SD-WAN members to those currently meeting their SLA targets (latency, jitter, packet loss thresholds defined in the health check). Among the qualifying members, it selects the one with the lowest measured cost metric — typically the lowest latency, jitter, or packet loss value reported by the health check probes. This makes the selection dynamic and performance-driven rather than static.

Exam trap

The trap is assuming 'Lowest Cost' refers to monetary or bandwidth cost, when in FortiOS it refers to the lowest measured SLA metric (latency/jitter/loss) among links that already meet the SLA thresholds.

How to eliminate wrong answers

Option A is wrong because round-robin is a separate SD-WAN strategy (or a load-balancing method) that cycles through links without regard to SLA performance, not the 'Lowest Cost (SLA)' behavior. Option B is wrong because physical port numbering has no bearing on SD-WAN member selection — FortiOS does not use port order as a cost metric. Option D is wrong because interface bandwidth from the static route table is not the metric used by the SLA-based strategy; the health-check measurements (latency/jitter/loss) drive the decision.

Full explanation →

MCQmedium

When configuring SD-WAN in FortiManager, why would you use 'Shared Objects'?

A.To increase the number of VDOMs supported

B.To allow FortiGates to share logs

C.To enable reuse of configuration elements across different templates

D.To create a site-to-site VPN

AnswerC

Shared Objects let one definition, such as an SD-WAN health check or SLA target, be referenced by many templates rather than duplicated. This satisfies the requirement to reuse configuration elements consistently across templates, so a single edit propagates everywhere.

Why this answer

Shared Objects in FortiManager are global or ADOM-level configuration objects (addresses, services, VIPs, security profiles, SD-WAN templates) that can be referenced by multiple policy packages, provisioning templates, and SD-WAN templates. This eliminates duplication and ensures consistency when the same object (e.g., an SD-WAN member interface or SLA target) must appear across many FortiGates or VDOMs. Because SD-WAN deployments typically span dozens of branches with identical object definitions, Shared Objects is the mechanism that makes template reuse practical.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates confuse FortiManager's configuration-reuse constructs (Shared Objects, templates, policy packages) with operational features like logging (FortiAnalyzer) or VPN creation, so the trap is picking a plausible-sounding but functionally unrelated answer.

How to eliminate wrong answers

Option A is wrong because the number of VDOMs supported is a platform/licensing limit on the FortiGate itself, not something FortiManager Shared Objects can increase. Option B is wrong because log sharing between FortiGates is handled by FortiAnalyzer (or syslog/FAZ forwarding), not by FortiManager Shared Objects, which are configuration constructs. Option D is wrong because site-to-site VPNs are built with IPsec phase1/phase2 objects and VPN Manager or templates — Shared Objects merely store reusable definitions and do not create tunnels by themselves.

Full explanation →

MCQmedium

A network administrator needs to provision a new SD-WAN zone across 50 managed FortiGates using FortiManager. The administrator wants to minimize manual configuration and ensure that the SD-WAN settings remain consistent. Which FortiManager feature should be used to achieve this?

A.Configure SD-WAN directly on each FortiGate via CLI and then import the configuration into FortiManager.

B.Create a new policy package and manually add SD-WAN members to each FortiGate.

C.Use the SD-WAN Template feature in FortiManager to define a template and assign it to the managed FortiGates.

D.Utilize FortiManager's script feature to push SD-WAN configuration to all FortiGates.

AnswerC

SD-WAN Templates in FortiManager allow you to define SD-WAN settings once and apply them to multiple FortiGates, ensuring consistency and reducing manual effort. The template supports dynamic mapping of interfaces, zones, and health checks, and can be assigned to device groups or individual devices. This is the recommended method for scalable SD-WAN provisioning across many FortiGates.

Why this answer

SD-WAN Templates in FortiManager provide a centralized, reusable method to define SD-WAN settings and apply them to multiple FortiGates. They support dynamic mapping of interfaces and zones, ensuring consistency and reducing manual configuration. This approach is ideal for provisioning SD-WAN across many devices, as it simplifies management and enforces standardization.

Exam trap

The trap here is assuming that CLI scripts or manual configuration can achieve the same consistency and scalability as SD-WAN templates.

Full explanation →

MCQhard

What happens if you modify an SD-WAN template that is already applied to a FortiGate?

A.The changes take effect immediately without a push

B.The configuration status shows 'Modified' and requires an installation task

C.The FortiGate automatically pulls the new config

D.The FortiGate configuration is reverted

AnswerB

Editing an applied SD-WAN template marks the FortiGate's configuration status as 'Modified', because the device's running configuration no longer matches the last installed template revision. An explicit installation task must then push the updated template, satisfying the stem's requirement that changes are staged rather than applied automatically.

Why this answer

When you modify an SD-WAN template that is already applied to a FortiGate, FortiManager marks the device's configuration status as 'Modified' because the running configuration on the FortiGate no longer matches the template. The change is not pushed automatically; an administrator must run an installation task (or 'Install Wizard') to push the updated template to the FortiGate. This is consistent with FortiManager's staged change model.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the push-vs-pull misconception — candidates assume FortiGate pulls config like a DHCP client, but FortiManager is a push model requiring an explicit install task.

How to eliminate wrong answers

Option A is wrong because FortiManager never pushes configuration changes to managed devices without an explicit installation task — changes are staged in the manager's database first. Option C is wrong because FortiGate does not pull configuration from FortiManager; FortiManager pushes configuration to FortiGate, and only when an install task is initiated. Option D is wrong because modifying a template does not revert the FortiGate's configuration — the device keeps running its current config until a new one is installed, and the 'Modified' status simply flags the drift.

Full explanation →

MCQhard

What is the effect of changing the IPS 'buffer' size on a FortiGate device?

A.It disables the hardware acceleration engine

B.It changes the signature timeout

C.It increases the number of concurrent IPS connections

D.It determines the maximum size of data packets to hold for inspection

AnswerD

The IPS buffer size sets how much packet data is held in memory for inspection before a verdict is reached. Increasing it lets the engine inspect larger payloads, satisfying the requirement to define the maximum data size retained for analysis, at the cost of memory.

Why this answer

The IPS buffer size on a FortiGate determines the maximum amount of data that the IPS engine will hold in memory for inspection before making a decision. A larger buffer allows the engine to reassemble and inspect larger payloads, which can improve detection of attacks that span multiple packets, but it also consumes more memory. The buffer size does not disable hardware acceleration, change signature timeouts, or increase concurrent connections.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the specific effect of the IPS buffer size, and candidates may confuse it with other IPS parameters like signature timeout or connection limits — the key is to remember it controls the amount of data held for inspection.

How to eliminate wrong answers

Option A is wrong because changing the IPS buffer size does not disable the hardware acceleration engine (NPU offload); hardware acceleration is controlled by separate settings and is not affected by buffer size. Option B is wrong because the signature timeout is a separate parameter that controls how long the IPS engine waits for a signature match, not the buffer size. Option C is wrong because the number of concurrent IPS connections is determined by system resources and session limits, not by the buffer size; the buffer size affects per-session inspection depth, not the total number of sessions.

Full explanation →

MCQhard

An administrator notices that logs are not appearing in FortiManager for a specific FortiGate. What is the first thing to check to ensure log forwarding is active?

A.The FortiManager license

B.The device's physical connection

C.Log forwarding configuration on the FortiGate

D.The firmware version of the FortiGate

AnswerC

Log forwarding must be configured on the FortiGate itself, specifying FortiManager as the remote log server, before any logs can reach it. Checking this setting first confirms whether the source device is actually sending logs.

Why this answer

When logs are missing in FortiManager for a specific FortiGate, the first thing to verify is the log forwarding configuration on the FortiGate itself. FortiManager receives logs only if the FortiGate is configured to send them — either via 'config log fortianalyzer setting' (if FortiManager hosts FortiAnalyzer features) or through the Fabric/central management settings. If log forwarding is disabled or misconfigured (wrong FortiManager IP, disabled logging), no logs will appear regardless of other factors.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the troubleshooting sequence — the trap is jumping to licensing or firmware (complex causes) instead of first verifying the basic log forwarding configuration on the source device, which is the most common and easily overlooked cause.

How to eliminate wrong answers

Option A is wrong because a FortiManager license issue would typically affect all managed devices or specific features, not just one FortiGate's logs — and licensing is not the first troubleshooting step when a single device's logs are missing. Option B is wrong because a physical connection issue would prevent FortiManager from managing the device at all (no policy pushes, no status), not just log forwarding; also, management connectivity is usually verified before log troubleshooting. Option D is wrong because firmware version mismatches may cause compatibility issues but would not selectively stop log forwarding for one device if the device is otherwise managed; firmware is checked after basic configuration.

Full explanation →

MCQmedium

When using SD-WAN, how does the 'member' configuration interact with physical interfaces?

A.Members replace the IP configuration

B.Members require a separate VDOM

C.Members are logical groups of interfaces

D.Members must have DHCP enabled

AnswerC

SD-WAN members are logical groupings that reference underlying physical interfaces, rather than being physical interfaces themselves. This abstraction lets multiple links be bundled into one SD-WAN zone, so traffic steering and health checks apply to the logical member while the physical interface carries the traffic.

Why this answer

In FortiGate SD-WAN, a 'member' is a logical construct that binds a physical (or VLAN) interface into the SD-WAN virtual interface (virtual-wan-link). The member does not replace the interface's IP configuration — it references the underlying interface, which retains its own IP, gateway, and DHCP settings. Members are essentially logical groupings that let the SD-WAN engine treat multiple WAN links as a single logical egress.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates understand that SD-WAN members are logical references to existing interfaces, not replacements — the misconception that members reconfigure or replace interface IP settings leads to wrong answers.

How to eliminate wrong answers

Option A is wrong because SD-WAN members reference existing interfaces and do not replace or override their IP configuration; the physical interface keeps its addressing. Option B is wrong because SD-WAN members do not require a separate VDOM — they operate within the same VDOM as the SD-WAN interface. Option D is wrong because DHCP is not a requirement for SD-WAN membership; members can use static IPs, PPPoE, or DHCP depending on the WAN link type.

Full explanation →

MCQhard

You need to inspect traffic between two VDOMs. Which mechanism is required?

A.Policy-based routing

B.Physical loopback cable

C.Inter-VDOM Link

D.Static NAT

AnswerC

An inter-VDOM link creates a dedicated virtual connection between two VDOMs, allowing traffic to traverse and be inspected by firewall policies. Without it, VDOMs remain isolated, so this mechanism satisfies the requirement to inspect inter-VDOM traffic.

Why this answer

An Inter-VDOM Link is the virtual interface pair that connects two VDOMs on the same FortiGate, allowing traffic to pass between them. Each VDOM gets one end of the link, and firewall policies on both VDOMs control what traffic is permitted. Without an Inter-VDOM Link, VDOMs are fully isolated and cannot exchange traffic.

Policy-based routing, physical loopback cables, and static NAT do not provide inter-VDOM connectivity.

Exam trap

The trap is choosing a physical workaround (loopback cable) or a routing feature (PBR) instead of the purpose-built virtual interface — candidates overlook that FortiGate provides Inter-VDOM Links specifically for this requirement.

How to eliminate wrong answers

Option A is wrong because policy-based routing (PBR) influences path selection based on policy, but it does not create a connection between VDOMs — there must already be an interface path. Option B is wrong because a physical loopback cable would require two physical ports (one in each VDOM) cabled together, which is inefficient and not the intended mechanism; the Inter-VDOM Link is the virtual equivalent. Option D is wrong because static NAT translates addresses but does not bridge two isolated VDOMs — NAT requires an existing routed path.

Full explanation →

MCQmedium

What is the benefit of using 'CLI Templates' in FortiManager?

A.They replace the GUI completely

B.They convert the policy to a CLI script

C.They allow applying configuration commands to multiple devices

D.They improve the FortiGate hardware performance

AnswerC

CLI Templates in FortiManager store reusable command snippets that can be assigned to multiple managed devices, pushing identical configuration without manual repetition. This satisfies the stem's requirement by enabling consistent, bulk command deployment across device groups.

Why this answer

CLI Templates in FortiManager are reusable sets of CLI commands that can be assigned to device groups or individual devices, enabling consistent configuration across many FortiGates at once. They are a provisioning and standardization tool, not a GUI replacement or performance enhancer. This makes bulk changes efficient and reduces human error.

Exam trap

The trap is assuming CLI Templates are about converting policies or boosting performance, when they are actually a bulk configuration-deployment mechanism for multiple devices.

How to eliminate wrong answers

Option A is wrong because CLI Templates complement the GUI; they do not replace it, and FortiManager still uses the GUI for most management tasks. Option B is wrong because converting a policy to a CLI script is a different feature (policy package installation or script export), not the purpose of CLI Templates. Option D is wrong because CLI Templates affect configuration, not hardware performance — no software template can improve FortiGate CPU or throughput.

Full explanation →

MCQhard

A FortiGate is performing OSPF routing. You want to redistribute connected routes into OSPF, but only for a specific subnet. How can this be achieved?

A.Configure a distribute-list in the OSPF process

B.Use an IP prefix list under the OSPF area command

C.Use a route map in the OSPF redistribute configuration

D.Use an access list under the interface configuration

AnswerC

A route map applied to the OSPF redistribute connected statement filters which connected prefixes enter OSPF, matching only the specified subnet via an access list or prefix list. This satisfies the stem's constraint of advertising a single subnet rather than every connected route, which plain redistribution would leak.

Why this answer

On FortiGate, redistribution into OSPF is controlled with a route map applied under 'config router ospf' > 'config redistribute connected'. The route map can match a specific prefix (via an IP prefix list or access list) and permit only that subnet, so only the desired connected route is redistributed.

Exam trap

The trap is confusing route filtering tools: distribute-lists filter OSPF-learned routes, while route maps are required to filter what gets redistributed into OSPF.

How to eliminate wrong answers

Option A is wrong because a distribute-list filters routes being received or advertised within OSPF, not the redistribution of connected routes into OSPF. Option B is wrong because IP prefix lists are not applied under the OSPF area command for this purpose; area commands control area parameters, not redistribution filtering. Option D is wrong because an access list under an interface does not govern OSPF redistribution; interface-level ACLs filter traffic, not routing advertisements.

Full explanation →

MCQmedium

In SD-WAN central management, what is the 'SD-WAN Zone' used for?

A.To define the physical port speed

B.To limit bandwidth for specific users

C.To group multiple SD-WAN members for logical policy routing

D.To isolate the SD-WAN traffic from the WAN

AnswerC

An SD-WAN zone groups multiple SD-WAN members so that policies and rules can reference the zone rather than individual interfaces. This satisfies the stem by enabling logical policy routing across members, simplifying configuration when links change.

Why this answer

The SD-WAN Zone is used to group multiple SD-WAN members (interfaces) into a logical entity for policy routing. This allows administrators to apply consistent routing policies and SLA profiles across all members in the zone, simplifying configuration and management.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the confusion between SD-WAN zones and other zoning concepts, leading candidates to select options about bandwidth limiting or isolation.

How to eliminate wrong answers

Option A is wrong because physical port speed is configured on the interface itself, not via the SD-WAN zone. Option B is wrong because bandwidth limiting for users is handled through traffic shaping or QoS policies, not the SD-WAN zone. Option D is wrong because isolating SD-WAN traffic from the WAN is not the purpose; the zone is about logical grouping for routing.

Full explanation →

MCQeasy

Which component of FortiManager allows for the centralized management of firmware across multiple devices?

A.Policy Database

B.Device Templates

C.Log View

D.Firmware Management

AnswerD

Firmware Management centralises firmware deployment across managed devices, letting administrators stage images and push upgrades to device groups from one console. This directly satisfies the stem's requirement for centralised firmware control across multiple FortiGate units, rather than configuring each appliance individually.

Why this answer

Firmware Management is the FortiManager component that provides centralized firmware upgrade and downgrade capabilities across multiple FortiGate devices. It allows administrators to import firmware images, schedule upgrades, and monitor the firmware status of all managed devices from a single console.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the specific FortiManager module names, expecting candidates to distinguish Firmware Management from Policy Database, Device Templates, and Log View, which serve different purposes.

How to eliminate wrong answers

Option A is wrong because the Policy Database stores firewall policies and objects, not firmware images or upgrade tasks. Option B is wrong because Device Templates are used to provision configuration settings like interfaces and routing, not to manage firmware versions. Option C is wrong because Log View displays logs and events, not firmware management functions.

Full explanation →

MCQmedium

When viewing the SD-WAN Monitor in FortiManager, what information is provided for the 'Health Check' status?

A.The firmware version of the device

B.The number of active users

C.Latency, jitter, and packet loss metrics

D.The current IP address of the interface

AnswerC

The SD-WAN Monitor's Health Check view reports the live SLA measurements gathered by the health check probes: latency, jitter and packet loss per member, letting administrators confirm whether each link currently meets its configured SLA thresholds.

Why this answer

The SD-WAN Monitor in FortiManager displays Health Check status, which is derived from the SD-WAN health-check probes configured on the FortiGate. These probes measure latency, jitter, and packet loss for each member link, and FortiManager surfaces those metrics so administrators can see link quality centrally. This is the core purpose of the health-check status view.

Exam trap

FORTINET-NSE7-SPECIALTY often tests what SD-WAN health checks actually measure, and candidates confuse inventory data (firmware, IP) with the dynamic SLA metrics (latency, jitter, loss).

How to eliminate wrong answers

Option A is wrong because firmware version is device inventory information, not a health-check metric, and is shown elsewhere (Device Manager). Option B is wrong because active user counts are session/authentication data, not SD-WAN health-check output. Option D is wrong because the interface IP address is configuration/inventory data, not a dynamic health-check measurement.

Full explanation →

Multi-Selectmedium

Which THREE of the following protocols can be used for Performance SLA probes?

Select 3 answers

A.FTP

B.ICMP

C.TCP Echo

D.HTTP

E.DHCP

AnswersB, C, D

ICMP is one of the probe protocols available for Performance SLA health checks, sending echo requests to measure latency, jitter and packet loss. This satisfies the stem's requirement by confirming ICMP as a valid probe type alongside the other supported protocols.

Why this answer

Performance SLA probes in FortiGate SD-WAN support several probe protocols, and ICMP (option B) is correct because it sends echo requests to measure latency, jitter, and packet loss to a target. TCP Echo (option C) is correct because it uses TCP port 7 echo to verify reachability and measure round-trip performance. HTTP (option D) is correct because FortiGate can issue HTTP GET requests to a monitored web server and evaluate response time and availability.

FTP (option A) is not a supported Performance SLA probe type, and DHCP (option E) is a network configuration protocol, not a probe mechanism for SLA monitoring.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates confuse general network protocols (FTP, DHCP) with the specific probe types supported for SD-WAN Performance SLAs, so the trap is selecting FTP or DHCP as valid probe protocols.

Full explanation →

MCQhard

Which parameter, when modified in a policy, causes a session flush for all active connections hitting that policy?

A.Schedule

B.Action (Accept to Deny)

C.Comments field

D.Policy Name

AnswerB

Changing a policy's action from Accept to Deny alters the policy's identity, so FortiGate tears down every session matching it, forcing re-evaluation against the new action. Other edits, such as logging or comments, leave established sessions intact.

Why this answer

Changing the Action of a policy from Accept to Deny alters the fundamental handling of traffic that matches the policy. FortiOS must immediately tear down existing sessions that were permitted under the previous Accept action, because they are no longer authorized. This forces all active connections hitting that policy to be flushed and re-evaluated against the new Deny action.

Exam trap

The trap here is assuming that any policy modification causes a session flush, but only changes that affect traffic handling (like Action) do so; cosmetic changes like Comments or Name do not.

How to eliminate wrong answers

Option A is wrong because modifying the Schedule only affects when the policy is active; existing sessions are not flushed immediately, and the change takes effect based on time constraints. Option C is wrong because the Comments field is purely informational metadata and has no impact on session handling or policy enforcement. Option D is wrong because renaming a policy does not change its matching criteria or action, so active sessions remain unaffected and continue without a flush.

Full explanation →

MCQeasy

When using SD-WAN zones, what is the primary benefit of grouping multiple physical interfaces into a single zone?

A.It increases the throughput of individual physical links.

B.It prevents the need for performance SLAs.

C.It automatically enables load balancing between interfaces.

D.It allows you to apply a single firewall policy to the entire group.

AnswerD

A zone groups several physical links so policy is written once against the logical zone rather than per member interface. Traffic is then load-balanced and failed over across members, satisfying the requirement to manage many links as one policy target.

Why this answer

Grouping multiple physical interfaces into a single SD-WAN zone allows you to apply a single firewall policy to the entire group, simplifying management and ensuring consistent security policies across all member interfaces. This is the primary benefit because it reduces administrative overhead and ensures that policies are uniformly enforced. While SD-WAN zones can also facilitate load balancing and failover, those are features of the SD-WAN rules applied to the zone, not the primary purpose of grouping interfaces.

Exam trap

The trap here is confusing the primary benefit of zones with the capabilities of SD-WAN rules; candidates might select load balancing as the primary benefit, but the question asks for the benefit of grouping interfaces into a zone, which is policy simplification.

How to eliminate wrong answers

Option A is wrong because grouping interfaces into a zone does not increase the throughput of individual physical links; throughput is determined by the link capacity and aggregation methods, not by zone membership. Option B is wrong because performance SLAs are still required and are configured within SD-WAN rules; zones do not eliminate the need for SLAs. Option C is wrong because while SD-WAN zones enable load balancing when used with SD-WAN rules, the automatic load balancing is not the primary benefit; the primary benefit is simplified policy application.

Full explanation →

MCQmedium

How can you verify that an SD-WAN configuration change was successfully applied to a FortiGate via FortiManager?

A.By checking the FortiAnalyzer logs

B.By restarting the FortiGate

C.By checking the Device Manager installation status

D.By viewing the system dashboard of the FortiGate locally

AnswerC

Checking Device Manager installation status confirms whether FortiManager successfully pushed the configuration to the managed FortiGate. After installing policy changes, the installation status column reports success or failure per device, satisfying the stem's requirement to verify the change was applied. This reflects the actual push result, not merely a saved revision.

Why this answer

FortiManager's Device Manager displays the installation status of configuration changes pushed to managed FortiGates. After installing a policy package or SD-WAN configuration, the installation status column shows whether the change succeeded, failed, or is pending, along with any error details. This is the authoritative verification method.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the role separation between FortiManager (configuration management and install status) and FortiAnalyzer (logging/reporting), causing candidates to pick FortiAnalyzer logs when verifying configuration installation.

How to eliminate wrong answers

Option A is wrong because FortiAnalyzer is a logging and reporting platform — it does not track FortiManager installation status of configuration changes. Option B is wrong because restarting the FortiGate does not verify configuration installation and is disruptive; it also does not confirm the change was applied. Option D is wrong because the FortiGate's local system dashboard shows runtime status, not whether FortiManager successfully installed a specific configuration revision.

Full explanation →

MCQmedium

Which SD-WAN rule strategy should you choose if you want to distribute traffic across multiple interfaces based on their bandwidth weights?

A.Manual

B.Maximize Bandwidth (SLA)

C.Lowest Cost (SLA)

D.SLA Target

AnswerB

Maximize Bandwidth (SLA) distributes sessions across members proportionally to their configured bandwidth weights, provided each member passes its SLA targets. This satisfies the stem's requirement to spread traffic by bandwidth weight, unlike Best Quality or Lowest Cost, which pick a single member rather than load-sharing.

Why this answer

The 'Maximize Bandwidth (SLA)' strategy selects SD-WAN members that meet the SLA and then distributes traffic across them proportionally to their configured bandwidth weights. This is the strategy designed to aggregate and load-balance traffic based on link capacity, making it the correct choice when you want weighted distribution by bandwidth.

Exam trap

The trap is that candidates confuse 'Maximize Bandwidth (SLA)' with 'Lowest Cost (SLA)' or invent 'SLA Target' as a strategy, not realizing that bandwidth-weighted distribution is specifically the Maximize Bandwidth (SLA) behavior.

How to eliminate wrong answers

Option A is wrong because 'Manual' strategy requires an administrator to explicitly define the order or selection of members; it does not automatically distribute traffic by bandwidth weights. Option C is wrong because 'Lowest Cost (SLA)' selects the single lowest-cost member that meets the SLA, not a weighted distribution across multiple members. Option D is wrong because 'SLA Target' is not a valid FortiGate SD-WAN strategy name — the actual strategies include Manual, Best Quality, Lowest Cost (SLA), Maximize Bandwidth (SLA), and Load Balance, so 'SLA Target' is a distractor.

Full explanation →

Multi-Selecthard

Which THREE pieces of information are displayed in the SD-WAN Monitor in FortiManager?

Select 3 answers

A.Status of SD-WAN members

B.Latency, jitter, and packet loss

C.Interface bandwidth usage

D.System temperature of the FortiGate

E.The current username of the logged-in admin

AnswersA, B, C

The SD-WAN Monitor in FortiManager polls managed FortiGate devices and displays the live operational state of each SD-WAN member interface, satisfying the stem's requirement for member status. This includes per-link health, SLA probe results and up/down state, which administrators need to verify that WAN links are passing traffic as intended.

Why this answer

Option A is correct because the SD-WAN Monitor in FortiManager displays the operational status of each SD-WAN member (up/down/standby), which is essential for verifying link health. Option B is correct because the monitor shows the performance SLA metrics per member — latency, jitter, and packet loss — that FortiGate uses to steer traffic and trigger failover. Option C is correct because interface bandwidth usage (throughput in/out) per SD-WAN member is presented, allowing admins to see load and utilization across links.

Option D is not part of the SD-WAN Monitor; FortiGate system temperature is a hardware sensor value shown in device dashboards or SNMP monitoring, not SD-WAN monitoring. Option E is also unrelated, as the logged-in administrator's username is an administrative session detail, not SD-WAN telemetry.

Exam trap

The trap here is confusing SD-WAN performance monitoring with general device health monitoring; candidates may select system temperature or admin username because they appear in other FortiManager dashboards.

Full explanation →

MCQhard

You are configuring an IPsec VPN tunnel between two FortiGates. Phase 1 comes up successfully, but Phase 2 fails. You have verified that the pre-shared keys match and the proposals are identical. What is the most likely cause?

A.The Phase 1 proposal includes a DH group that is not supported by the remote peer.

B.The Phase 2 selectors (quick mode selectors) do not match on both peers.

C.The pre-shared key is incorrect on one peer.

D.The Phase 2 proposal includes an encryption algorithm that is not supported by the remote peer.

AnswerB

Phase 2 selectors define the traffic that is encrypted and must match on both peers. If they do not match, Phase 2 negotiation fails. Common issues include mismatched subnet or wildcard masks. Since Phase 1 is up, the problem is likely in Phase 2 parameters, making this the most probable cause.

Why this answer

Phase 2 negotiation requires that the quick mode selectors (the traffic selectors) match on both peers. If they differ, the tunnel will not establish even though Phase 1 is up. Verifying that the local and remote subnets and masks are mirror images is essential.

Common mistakes include asymmetric selectors or using different address objects.

Exam trap

The trap here is focusing on Phase 2 proposal parameters while overlooking that the traffic selectors must also match exactly.

Full explanation →

Multi-Selectmedium

Which TWO of the following are benefits of using SD-WAN templates in FortiManager?

Select 2 answers

A.Consistent SD-WAN policy application across devices

B.Automatic firmware upgrades

C.Automated log analysis

D.Direct access to the FortiGate CLI

E.Simplified configuration deployment for large branch deployments

AnswersA, E

Templates push one central SD-WAN definition to every assigned device, so rules, members and health checks stay identical. This removes per-device drift and satisfies the benefit of consistent SD-WAN policy application across devices, rather than relying on manually repeated CLI configuration on each FortiGate.

Why this answer

Option A is correct because SD-WAN templates in FortiManager let you define SD-WAN settings and policies once and apply them consistently across many managed FortiGates, ensuring uniform rules and reducing per-device drift. Option E is correct because these templates enable simplified, scalable configuration deployment for large branch environments by provisioning SD-WAN interfaces, members, and rules centrally instead of manually configuring each device. Option B is incorrect because firmware upgrades are handled by FortiManager's firmware management features, not SD-WAN templates.

Option C is incorrect because log analysis is provided by FortiAnalyzer, not by SD-WAN templates in FortiManager. Option D is incorrect because direct FortiGate CLI access is a separate administrative capability and is not a benefit of SD-WAN templates.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the confusion between FortiManager's SD-WAN templates and other management features like firmware upgrades or log analysis, causing candidates to select unrelated benefits.

Full explanation →

MCQmedium

An administrator wants to use FortiManager to push a configuration change to 50 FortiGates simultaneously. Which method minimizes downtime and ensures consistency?

A.Create 50 separate ADOMs

B.Assign devices to a Device Group and push a common Policy Package

C.Connect to each FortiGate via SSH and run scripts

D.Enable 'Auto-Push' for every change

AnswerB

A Device Group with a shared Policy Package installs one consistent configuration across all 50 FortiGates in a single push, avoiding per-device drift and sequential edits. This satisfies the simultaneous, consistency-critical requirement while minimising downtime through centralised, atomic deployment.

Why this answer

Assigning the 50 FortiGates to a Device Group and pushing a common Policy Package lets FortiManager install the same consistent configuration to all devices in one operation. This minimizes downtime because the install is orchestrated centrally with a single revision, and it guarantees consistency since every device receives identical policy objects. It also avoids the human error inherent in per-device changes.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the difference between centralized policy push (Device Group + Policy Package) and per-device scripting, so candidates who value 'automation via SSH' over FortiManager's native orchestration pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because creating 50 separate ADOMs fragments management, multiplies administrative overhead, and prevents a single consistent policy push — it is the opposite of consistency. Option C is wrong because connecting to each FortiGate via SSH and running scripts is manual, error-prone, and does not guarantee identical results across devices; it also risks downtime from typos or partial execution. Option D is wrong because enabling 'Auto-Push' for every change pushes each individual change immediately, which can cause inconsistent intermediate states and unexpected downtime rather than a controlled, atomic rollout.

Full explanation →

MCQhard

An administrator needs to perform a firmware upgrade on 100 FortiGates. Which feature in FortiManager allows this to be done securely with a rollback option?

A.Automated patch management

B.Manual script pushing

C.Firmware Management in Device Manager

D.Global Policy upgrade task

AnswerC

Firmware Management in Device Manager lets the administrator stage images and push upgrades to all 100 FortiGates in one coordinated task, satisfying the bulk-upgrade constraint. It retains the previous firmware per device, enabling rollback if an upgrade fails, which the scenario explicitly requires.

Why this answer

FortiManager's Firmware Management feature (found under Device Manager) allows administrators to upload firmware images, schedule upgrades, and perform bulk upgrades across multiple FortiGates. It includes a rollback option that can revert devices to a previous firmware version if the upgrade fails or causes issues. This is the secure, centralized method for upgrading many devices.

Exam trap

The trap is selecting generic-sounding options like 'Automated patch management' or 'Manual script pushing' — candidates must know the exact FortiManager feature name 'Firmware Management' and that it includes rollback, which scripts do not.

How to eliminate wrong answers

Option A is wrong because 'Automated patch management' is not a specific FortiManager feature name — while FortiManager can automate some tasks, the firmware upgrade feature is called Firmware Management. Option B is wrong because manually pushing scripts is not secure or efficient for 100 devices and does not provide a built-in rollback option. Option D is wrong because 'Global Policy upgrade task' is not a firmware upgrade feature — Global Policy is for managing policies across multiple ADOMs, not for firmware upgrades.

Full explanation →

Multi-Selectmedium

Which TWO components are synchronized between HA members?

Select 2 answers

A.Administrator credentials

B.Active session table

C.Local log files

D.Firmware image

E.Configuration database

AnswersB, E

Synchronising the active session table lets the standby FortiGate inherit established flows, so traffic already in progress continues without renegotiation or re-authentication when failover occurs. This satisfies the HA requirement for seamless session continuity, since the primary unit continuously replicates its session entries to the subordinate member.

Why this answer

In an HA (High Availability) cluster, the two members synchronize the active session table (option B) so that if a failover occurs, existing sessions can continue without being dropped, since session state is replicated to the standby unit. They also synchronize the configuration database (option E), ensuring both members share identical policy, object, and system settings so the standby can take over seamlessly. Administrator credentials are part of the configuration and are not synchronized as a separate component, local log files (option C) are not synchronized between HA peers, and firmware images (option D) are not synchronized as part of HA operation—each unit must be updated independently to matching versions.

Exam trap

Candidates might think that administrator credentials are synchronized separately, but they are part of the configuration database; the trap is selecting them as a separate component.

Full explanation →

MCQmedium

What is the impact of checking the 'Interface Preference' box in an SD-WAN rule?

A.It overrides the SLA strategy selection.

B.It enables failover to the default gateway.

C.It enables load balancing across interfaces.

D.It increases the probe frequency.

AnswerA

Ticking Interface Preference forces the rule to use the specified outgoing interface rather than letting the SLA strategy pick the best member. It therefore overrides SLA-based selection, satisfying the stem's question about the checkbox's impact on SD-WAN rule behaviour.

Why this answer

Checking 'Interface Preference' in an SD-WAN rule forces the rule to use the explicitly selected interface(s) rather than letting the SLA strategy dynamically pick the best-performing member. This effectively overrides the SLA-based path selection for that rule, so traffic egresses the preferred interface even if another member has better SLA metrics. It is used when a specific link must be used for policy, compliance, or cost reasons.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that Interface Preference enables failover or load balancing, when it actually pins traffic to a chosen member and overrides SLA-driven selection.

How to eliminate wrong answers

Option B is wrong because failover to the default gateway is governed by routing and SD-WAN member configuration, not by the Interface Preference checkbox. Option C is wrong because load balancing across interfaces is achieved through SD-WAN rule strategies and multiple members, not by enabling Interface Preference. Option D is wrong because probe frequency is configured under the performance SLA health-check settings, not by the Interface Preference option.

Full explanation →

MCQmedium

What is the purpose of the 'Inbound' interface setting in an SD-WAN rule?

A.To restrict the rule to traffic originating from a specific interface.

B.To enable reverse path forwarding checks.

C.To define the WAN gateway.

D.To specify the egress interface.

AnswerA

The Inbound interface setting constrains rule matching to sessions whose ingress interface equals the specified one. Traffic arriving on any other interface bypasses the rule, so it scopes the SD-WAN rule to flows originating from that particular interface.

Why this answer

The 'Inbound' interface setting in an SD-WAN rule specifies the incoming interface for traffic that the rule should match. It restricts the rule to traffic originating from a specific interface, allowing granular control over which traffic is subject to the SD-WAN rule. This is useful when you want to apply different SD-WAN strategies based on the source of the traffic, such as traffic from the LAN versus traffic from a VPN tunnel.

Exam trap

Candidates often confuse the inbound interface setting with the outbound interface selection, leading them to choose 'egress interface' as the answer.

How to eliminate wrong answers

Option B is wrong because reverse path forwarding (RPF) checks are a security feature configured separately, not through the 'Inbound' interface setting in an SD-WAN rule. Option C is wrong because the WAN gateway is defined in the interface configuration or static routes, not in the SD-WAN rule's inbound setting. Option D is wrong because the egress interface is determined by the SD-WAN rule's outbound interface selection, not by the inbound setting.

Full explanation →

MCQmedium

An administrator implements BGP over SD-WAN tunnels to a cloud provider. The cloud provider requires BGP MD5 authentication on all peering sessions. Where is BGP MD5 authentication configured on the FortiGate?

A.Within the firewall policy authentication settings

B.Under the IPsec phase 1 interface advanced settings

C.Inside the SD-WAN health check probe configuration

D.Under the router bgp neighbor configuration block in the CLI

AnswerD

BGP MD5 authentication is set with the password parameter inside the neighbor block under config router bgp, applying to that specific peering session. This satisfies the cloud provider's requirement that every SD-WAN peering session authenticate.

Why this answer

BGP MD5 authentication is configured on the FortiGate under the BGP neighbor configuration in the CLI, using the command 'set password' within the 'config router bgp' and 'config neighbor' blocks. This sets the TCP MD5 signature option for the BGP session, which must match on both peers. It is not configured in firewall policies, IPsec Phase 1 settings, or SD-WAN health checks.

Exam trap

FORTINET-NSE7-SPECIALTY often tests where BGP authentication is configured, and candidates may incorrectly assume it is part of IPsec or firewall settings rather than a BGP neighbor parameter, leading them to choose the wrong option.

How to eliminate wrong answers

Option A is wrong because firewall policy authentication settings control user authentication for traffic passing through the firewall, not BGP session authentication. Option B is wrong because IPsec Phase 1 advanced settings deal with IKE authentication and encryption parameters, not BGP MD5. Option C is wrong because SD-WAN health check probes are used to monitor link quality and do not carry BGP authentication settings.

Full explanation →

MCQeasy

Which interface can be used as an SD-WAN member in an SD-WAN template?

A.Physical ports, VLANs, and VPN tunnels

B.Only WAN physical ports

C.Only VLANs

D.Only loopback interfaces

AnswerA

Physical ports, VLANs and IPsec VPN tunnels all qualify as SD-WAN members within a FortiGate SD-WAN template, since membership requires only a routable interface with a gateway. This satisfies the stem's constraint by covering every supported member type, whereas omitting VLANs or tunnels would exclude valid overlay and segmented-link designs.

Why this answer

In Fortinet SD-WAN, an SD-WAN member interface can be any logical or physical interface that carries traffic and supports the necessary health-check and performance SLA monitoring. This includes physical ports (e.g., wan1, wan2), VLAN sub-interfaces (e.g., vlan10 on a physical port), and VPN tunnels (e.g., IPsec tunnels, ADVPN shortcuts). The SD-WAN template in FortiManager abstracts these members into a single virtual interface, allowing dynamic path selection based on link quality.

Therefore, option A correctly identifies the full set of supported interface types.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that SD-WAN members are restricted to physical WAN interfaces, but the exam expects you to know that VLANs and VPN tunnels are equally valid, as they are all routable and monitorable interfaces.

How to eliminate wrong answers

Option B is wrong because SD-WAN members are not limited to WAN physical ports; VLANs and VPN tunnels are equally valid and commonly used, especially in multi-VDOM or overlay designs. Option C is wrong because VLANs are only a subset; physical ports and VPN tunnels are also supported. Option D is wrong because loopback interfaces are not supported as SD-WAN members—they lack the ability to carry forwarded traffic and are typically used for management or BGP router-ID purposes, not for performance-based path selection.

Full explanation →

MCQeasy

What is the default behavior of a FortiGate firewall policy when no explicit policy matches the traffic?

A.Send to local DNS

B.Implicit Deny

C.Route to DMZ

D.Allow

AnswerB

FortiGate applies an implicit deny at the end of policy processing, silently dropping traffic that matches no explicit policy. This default-deny posture satisfies the stem's scenario by ensuring unmatched traffic is blocked rather than permitted.

Why this answer

FortiGate firewalls, like most stateful firewalls, follow a default-deny security posture. When a packet does not match any explicit firewall policy, it is dropped by the implicit deny rule. This implicit deny is not visible in the policy list but is always present at the bottom, ensuring that only traffic explicitly permitted by a policy is allowed.

This behavior aligns with the principle of least privilege and is a fundamental security best practice.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that FortiGate allows traffic by default or that there is an implicit allow rule, when in fact the default is implicit deny.

How to eliminate wrong answers

Option A is wrong because FortiGate does not automatically send unmatched traffic to a local DNS server; DNS resolution is handled separately and only if a policy allows DNS traffic. Option C is wrong because there is no default routing to a DMZ; routing decisions are based on the routing table, and security policies must explicitly permit traffic to any zone, including DMZ. Option D is wrong because allowing all unmatched traffic would be a severe security risk and contradicts FortiGate's default-deny design.

Full explanation →

MCQmedium

Which FortiGate feature should be enabled to prevent internal users from accessing malicious websites based on real-time threat intelligence?

A.Antivirus profile

B.Web Filter

C.Application Control

D.DNS Filter

AnswerB

Web Filter enforces URL and category-based policies using FortiGuard real-time threat intelligence, blocking malicious sites before internal users connect. It satisfies the stem's requirement for live intelligence-driven prevention, unlike static lists or DNS-only filtering. Enabling it on the relevant firewall policy applies the block inline to outbound user traffic.

Why this answer

Web Filter is the FortiGate feature that inspects and controls HTTP/HTTPS traffic to block access to malicious or categorized websites using real-time threat intelligence feeds (FortiGuard). It evaluates URLs against FortiGuard's web filter database and can enforce policies based on categories, reputation, and threat scores. Antivirus, Application Control, and DNS Filter do not provide the same URL-based, real-time web categorization and blocking capability.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the distinction between Web Filter and DNS Filter, as both can block malicious sites; candidates must recognize that Web Filter provides URL-based real-time categorization while DNS Filter only blocks domain resolution.

How to eliminate wrong answers

Option A is wrong because Antivirus profiles scan files for malware signatures but do not block website access based on URL categorization or real-time web threat intelligence. Option C is wrong because Application Control identifies and controls applications (e.g., Facebook, BitTorrent) rather than blocking malicious websites by URL reputation. Option D is wrong because DNS Filter blocks malicious domains at the DNS resolution layer, but it does not provide full URL-based web filtering or real-time web category intelligence for HTTP/HTTPS traffic.

Full explanation →

Multi-Selecthard

An enterprise deploys ADVPN 2.0 with BGP and security profiles applied to traffic traversing the VPN overlay. Which THREE statements are correct regarding how security profiles and ADVPN 2.0 interact in FortiOS? (Choose three)

Select 3 answers

A.SSL inspection (DPI) applied on spoke firewall policies inspects decrypted traffic traversing the ADVPN shortcut tunnel

B.Security profiles can be centrally managed and pushed to spokes using FortiManager security profile templates

C.Firewall policies enforcing security profiles (such as Antivirus and IPS) must be configured on the spoke units because shortcut traffic flows directly between spokes without passing through the hub

D.ADVPN 2.0 automatically disables all firewall inspection profiles on shortcut interfaces to maximize throughput

E.The hub FortiGate inspects all data packets exchanged between spokes even after a direct shortcut tunnel is established

AnswersA, B, C

SSL inspection on spoke policies decrypts and inspects traffic traversing ADVPN shortcut tunnels, because shortcut tunnels terminate at the spoke's IPsec interface where the firewall policy and its security profiles apply. This satisfies the stem's constraint that security profiles govern overlay traffic, including dynamically established shortcuts rather than only the initial hub-and-spoke path.

Why this answer

Option C is correct because in ADVPN 2.0, once a spoke-to-spoke shortcut tunnel is established, data traffic flows directly between the spokes and no longer traverses the hub, so the spoke FortiGates must have firewall policies with security profiles (Antivirus, IPS, etc.) applied to inspect that shortcut traffic. Option A is correct because SSL inspection (deep packet inspection) configured on those spoke policies will decrypt and inspect the TLS traffic traversing the ADVPN shortcut tunnel, since the spoke is the enforcement point for the shortcut. Option B is correct because FortiManager security profile templates allow centralized creation and push of security profiles (AV, IPS, web filter, etc.) to managed spoke FortiGates, which is a standard way to keep consistent UTM enforcement across an ADVPN deployment.

Option D is incorrect because ADVPN 2.0 does not automatically disable firewall inspection profiles on shortcut interfaces; inspection is governed by the firewall policies and profiles the administrator configures. Option E is incorrect because after a shortcut is established, inter-spoke data traffic bypasses the hub entirely, so the hub cannot inspect those packets.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that the hub continues to inspect all traffic even after shortcut tunnels are established, or that security profiles are automatically disabled on shortcuts.

Full explanation →

MCQeasy

What is the result of 'Pushing' a policy package from FortiManager to a FortiGate?

A.The FortiGate policy is sent to the FortiManager

B.The policy is saved in a draft state on the FortiGate

C.The FortiManager policy is appended to the existing FortiGate policy

D.The FortiGate policy configuration is overwritten with the FortiManager version

AnswerD

Pushing a policy package installs the FortiManager policy package onto the FortiGate, replacing the device's local policy configuration with the FortiManager version. This satisfies the scenario: the FortiGate's policy configuration is overwritten, not merged or merely backed up.

Why this answer

When you push a policy package from FortiManager to a managed FortiGate, FortiManager installs its policy package configuration onto the device, replacing the corresponding firewall policy configuration on the FortiGate with the FortiManager version. This is the standard 'install' operation in the FortiManager workflow, and it overwrites the device-level policy configuration rather than merging or appending it. The FortiGate becomes a reflection of the FortiManager policy package for the policy-related objects that are pushed.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the direction and effect of FortiManager operations, trapping candidates who confuse 'push/install' (FortiManager to FortiGate, overwriting device config) with 'import/retrieve' (FortiGate to FortiManager) or who assume policies are merged rather than replaced.

How to eliminate wrong answers

Option A is wrong because it describes the reverse direction — retrieving or importing configuration from the FortiGate into FortiManager, not pushing from FortiManager to the FortiGate. Option B is wrong because FortiManager does not push policies into a draft state on the FortiGate; draft or pending states exist within FortiManager's workflow (e.g., policy package status), not as a device-side draft of the pushed policy. Option C is wrong because FortiManager does not append its policy package to the existing FortiGate policy; installation replaces the relevant policy configuration rather than concatenating it, so any device-local policy changes not reflected in FortiManager can be lost.

Full explanation →

MCQhard

If an SD-WAN template contains a reference to an interface that does not exist on a target FortiGate, what occurs during the installation process?

A.The FortiGate automatically creates a dummy interface

B.The installation fails with a configuration error

C.The installation proceeds and ignores the missing interface

D.The FortiGate enters an 'Emergency' state

AnswerB

FortiManager validates template references against the target FortiGate's actual interface list before pushing configuration. A missing interface breaks that dependency check, so the install aborts with a configuration error rather than silently skipping or creating the object, satisfying the stem's scenario of a non-existent referenced interface.

Why this answer

If an SD-WAN template references an interface that does not exist on the target FortiGate, the installation fails with a configuration error. FortiManager validates the template against the device's actual interfaces during the install process; a missing interface cannot be resolved, so the push is aborted. The administrator must correct the template or the device's interface configuration.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the assumption that FortiManager will auto-create or ignore missing interfaces; in reality, installation fails, and candidates must know that template references must match existing device interfaces.

How to eliminate wrong answers

Option A is wrong because FortiGate does not automatically create dummy interfaces to satisfy template references; interfaces must exist or be created explicitly. Option C is wrong because the installation does not silently ignore missing interfaces — it fails to prevent an inconsistent config. Option D is wrong because the FortiGate does not enter an 'Emergency' state due to a template mismatch; it simply rejects the invalid config, and the install fails.

Full explanation →

Multi-Selecthard

Which THREE of the following are mandatory for a BGP neighbor adjacency to establish?

Select 3 answers

A.Identical prefix lists

B.Correct autonomous system numbers

C.Reachability to the neighbor IP

D.Identical router IDs

E.Matching BGP version

AnswersB, C, E

The peers must know their AS relationship.

Why this answer

Option B is correct because BGP peers must have compatible AS numbers: an eBGP session requires the neighbor's configured remote-as to match the AS actually present in the OPEN message, and an iBGP session requires both routers to be in the same AS, otherwise the OPEN is rejected. Option C is correct because the routers must have IP reachability to each other's neighbor addresses (typically via a route in the IGP or a directly connected link) so the TCP three-way handshake on port 179 can complete before any BGP session can form. Option E is correct because the BGP version negotiated in the OPEN message must match; both peers must support a common version (normally BGP-4), and a version mismatch causes the session to fail.

Option A is not required because prefix lists are policy tools applied to filter advertised or received routes after the session is up, and they have no role in forming the adjacency. Option D is not required because router IDs only need to be unique within each AS and are used for tie-breaking and loop detection; they do not have to be identical between peers for the session to establish.

Exam trap

The trap is that candidates assume router IDs must match (they must be unique, not identical) or that prefix lists are needed for adjacency, when in fact they only affect route exchange after the session is up.

Full explanation →

MCQmedium

You need to inspect traffic between two internal VLANs. How do you ensure this traffic is processed by the FortiGate?

A.Configure firewall policies between the VLAN interfaces

B.Enable hardware switching

C.Set the firewall mode to Transparent

D.Enable inter-VLAN routing on the switches only

AnswerA

Inter-VLAN traffic arriving on one VLAN interface and leaving another is only inspected when a firewall policy references both interfaces as source and destination. Without such a policy the FortiGate discards the packets, so configuring policies between the VLAN interfaces ensures processing occurs.

Why this answer

For a FortiGate to inspect traffic between two internal VLANs, it must be the Layer 3 gateway for those VLANs and have firewall policies that permit and inspect traffic between the VLAN interfaces. Simply creating the VLAN interfaces is not enough — without policies, the implicit deny drops the traffic, and without the FortiGate as gateway, traffic never reaches it.

Exam trap

The trap is thinking that creating VLAN interfaces alone enables inspection, when the exam is testing that firewall policies (and FortiGate as gateway) are required to route and inspect inter-VLAN traffic.

How to eliminate wrong answers

Option B is wrong because hardware switching (or hardware acceleration) is a performance feature, not a routing/inspection enabler; it does not cause traffic to be inspected. Option C is wrong because Transparent mode is used when the FortiGate sits inline without being a gateway, but the scenario implies inter-VLAN routing where the FortiGate should be the gateway — and transparent mode has its own limitations for inter-VLAN inspection. Option D is wrong because enabling inter-VLAN routing only on the switches bypasses the FortiGate entirely, so no inspection occurs.

Full explanation →

MCQmedium

You are configuring an IPS policy to protect a web server. You notice that traffic is being dropped due to a false positive. Which action is the most efficient way to resolve this while maintaining security?

A.Change the IPS mode from blocking to monitoring

B.Disable the entire IPS sensor profile

C.Create an IPS sensor override for the specific signature ID

D.Increase the IPS packet buffer size

AnswerC

An IPS sensor override targets the exact signature ID generating the false positive, disabling or tuning only that signature while every other IPS signature remains active. This preserves protection for the web server and avoids weakening the whole sensor or policy, satisfying the requirement to resolve the drop efficiently.

Why this answer

Creating an IPS sensor override for the specific signature ID allows you to selectively disable or modify the action of only the offending signature, eliminating the false positive while keeping all other IPS protections active. This is the most surgical and efficient approach because it preserves the security posture of the entire sensor profile. FortiGate IPS sensors support per-signature overrides (set status disable, set action pass, or set log-packet enable) without affecting unrelated signatures.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that changing the IPS mode to monitor or disabling the sensor is an acceptable fix for false positives, when the exam expects the most granular, security-preserving action.

How to eliminate wrong answers

Option A is wrong because switching the IPS mode from blocking to monitoring globally disables enforcement for all signatures, converting the sensor into a detection-only tool and leaving the web server exposed to every other threat the IPS was designed to block. Option B is wrong because disabling the entire IPS sensor profile removes all intrusion prevention, which is a drastic overreaction to a single false positive and eliminates defense-in-depth. Option D is wrong because IPS packet buffer size relates to how much data is buffered for inspection and has no bearing on false-positive signature matches; increasing it does not stop the signature from firing.

Full explanation →

Multi-Selectmedium

Which TWO methods can be used to authenticate a FortiGate when it registers to a FortiManager?

Select 2 answers

A.External RADIUS server

B.SNMP community string

C.Password/Pre-shared Key

D.Serial Number registration

E.IP-based automatic discovery

AnswersC, D

Password or pre-shared key authentication satisfies the registration constraint by having the FortiGate present a shared secret that FortiManager validates before accepting the device. This credential is configured on both sides during initial setup, so no certificate infrastructure or external identity provider is required for the FortiGate to register.

Why this answer

Option C (Password/Pre-shared Key) is correct because when a FortiGate is added to FortiManager using the 'Add Device' wizard, the administrator can specify a pre-shared key (PSK) that the FortiGate must present during the FGFM (FortiGate-FortiManager) registration handshake to authenticate itself. Option D (Serial Number registration) is correct because FortiManager can also authenticate a registering FortiGate by matching its serial number against a pre-authorized device entry, allowing the device to be recognized and added without a PSK. Options A, B, and E are not valid FortiGate-to-FortiManager authentication methods: RADIUS is used for administrative or user authentication, not device registration; SNMP community strings are for monitoring, not registration; and IP-based automatic discovery merely identifies candidate devices on the network but does not authenticate them for FortiManager registration.

Exam trap

The trap is picking IP-based discovery as an authentication method — discovery and authentication are separate steps, and candidates conflate the two because discovery is the first thing they see in the FortiManager workflow.

Full explanation →

MCQeasy

What is the default behavior for 'override' in FortiGate HA?

A.Depends on the model

B.Enabled

C.Always enabled

D.Disabled

AnswerD

FortiGate HA leaves override disabled by default, so a rebooted unit does not automatically reclaim the primary role. The cluster keeps its current primary unless override is enabled on the higher-priority member, avoiding unnecessary failovers.

Why this answer

In FortiGate HA, the 'override' setting is disabled by default. When disabled, the primary unit is selected based on the highest priority value, but if a higher-priority unit joins later it will not automatically preempt the current primary. Enabling override allows a unit with a higher priority to take over the primary role when it comes online.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that override is enabled by default or that it is required for HA to function, when in fact it is disabled by default and only controls preemption behavior.

How to eliminate wrong answers

Option A is wrong because the default value of override is consistent across FortiGate models and is not model-dependent. Option B is wrong because override is not enabled by default; it must be explicitly configured. Option C is wrong because override is never 'always enabled' — it is a configurable toggle that defaults to disabled.

Full explanation →

MCQhard

You are configuring BGP and need to advertise a summary route to your ISP. How do you ensure only the summary route is advertised?

A.Use a distribute-list

B.Set the weight to 0

C.Use an aggregate-address with summary-only

D.Configure a route map with a prefix list

AnswerC

The summary-only keyword suppresses the more-specific component routes from being advertised, leaving only the aggregate prefix in BGP updates. Without it, both the aggregate and its contributing routes propagate, so this satisfies the requirement to advertise solely the summary to the ISP.

Why this answer

The 'aggregate-address' command with the 'summary-only' keyword in BGP creates a summary route and suppresses the advertisement of more specific component routes to BGP peers. This ensures that only the summary route is advertised, which reduces the size of the BGP table on the ISP's routers and provides a clean, aggregated announcement. Without 'summary-only', both the summary and the more specific routes would be advertised.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the difference between filtering routes (distribute-list, route map) and aggregating routes (aggregate-address) — candidates may choose a filtering method when the question asks for a summary route advertisement.

How to eliminate wrong answers

Option A is wrong because a distribute-list filters routes based on an access list but does not create a summary route; it can suppress specific routes but does not generate the aggregate, so it does not meet the requirement of advertising a summary route. Option B is wrong because setting the weight to 0 has no effect on route advertisement — weight is a local attribute for outbound path selection and does not control which routes are advertised to peers. Option D is wrong because a route map with a prefix list can filter or modify routes but does not automatically create a summary route; it would require manual configuration of the summary and suppression, which is more complex and not the standard method.

Full explanation →

Multi-Selectmedium

Which THREE of the following are parameters that can be monitored in a Performance SLA?

Select 3 answers

A.Packet Loss

B.CPU load

C.Jitter

D.Disk usage

E.Latency

AnswersA, C, E

Packet loss is a measurable Performance SLA metric, tracked as a percentage of dropped traffic across the monitored link or member. This satisfies the stem's constraint by being one of the three valid parameters FortiGate SD-WAN health checks evaluate.

Why this answer

In a Performance SLA (as used by SD-WAN/performance-monitoring features such as Fortinet's SD-WAN performance SLAs), the monitored parameters are network-quality metrics measured by probes: Packet Loss (A) is correct because the SLA tracks the percentage of probe packets that never arrive at the remote target, Jitter (C) is correct because it measures the variation in delay between consecutive probe packets, and Latency (E) is correct because it measures the round-trip or one-way delay of the probes. These three metrics are exactly the ones used to decide whether a link meets the SLA and to trigger failover or rule changes. CPU load (B) and Disk usage (D) are host/resource utilization statistics reported by system sensors or SNMP, not link-quality parameters evaluated by a Performance SLA, so they do not belong.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the confusion between network-quality SLA metrics (latency, jitter, loss) and system resource metrics (CPU, memory, disk) that are unrelated to SLA health.

Full explanation →

MCQmedium

What is the effect of changing the 'Hold-down' timer in a Performance SLA?

A.It changes the frequency of the probes.

B.It sets the maximum number of failed probes allowed.

C.It prevents route flapping by delaying the transition back to an 'up' state.

D.It determines the timeout duration for a single probe.

AnswerC

Hold-down specifies how long a member must remain healthy before the SLA transitions it back to up. Extending it prevents rapid up/down oscillation, so flapping members do not repeatedly trigger route changes and traffic re-steering.

Why this answer

The Hold-down timer in a Performance SLA specifies how long the SLA remains in a down state before it is allowed to transition back to up, even after probes succeed again. This delay prevents rapid flapping between up and down states when link quality is marginal, stabilizing SD-WAN rule decisions. It is a hysteresis mechanism, not a probe frequency or failure threshold.

Exam trap

FORTINET-NSE7-SPECIALTY often tests confusion between probe interval, failure threshold, timeout, and hold-down, so candidates must map each timer to its exact function.

How to eliminate wrong answers

Option A is wrong because probe frequency is controlled by the probe interval setting, not the hold-down timer. Option B is wrong because the maximum number of failed probes is governed by the failure threshold or retry count, not hold-down. Option D is wrong because the timeout duration for a single probe is a separate probe timeout parameter, not the hold-down timer.

Full explanation →

MCQeasy

What is the impact of changing the 'set vdom-mode' from 'no-vdom' to 'multi-vdom'?

A.Automatic disablement of HA

B.Loss of all firewall policies

C.No impact, immediate change

D.System reboot required

AnswerD

Switching from no-vdom to multi-vdom restructures the entire configuration hierarchy, so the FortiGate must reboot to reinitialise interfaces and routing tables under the new mode. This satisfies the stem's constraint that the change cannot apply at runtime.

Why this answer

Changing 'set vdom-mode' from 'no-vdom' to 'multi-vdom' requires a reboot because the FortiGate must reinitialize its configuration database and process architecture to support multiple virtual domains. VDOM mode is a global system setting that affects how interfaces, policies, routing tables, and admin domains are partitioned, so the change cannot be applied live. After the reboot, the default 'root' VDOM is created and the previous global configuration is migrated into it.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates assume VDOM mode changes are hot-applied like most FortiGate settings — the trap is forgetting that this specific global setting mandates a reboot.

How to eliminate wrong answers

Option A is wrong because HA is not automatically disabled by enabling multi-vdom; HA can operate in either mode, though VDOM partitioning interacts with HA configuration and must be planned. Option B is wrong because existing firewall policies are not lost — they are migrated into the root VDOM during the mode change. Option C is wrong because the change is not immediate; the CLI explicitly warns that a reboot is required and prompts for confirmation.

Full explanation →

MCQmedium

When using SD-WAN templates, how are SD-WAN rules ordered?

A.Top to bottom

B.Based on the creation date

C.By the interface speed

D.Randomly

AnswerA

SD-WAN rules in FortiManager templates are evaluated sequentially from the first entry downwards, so the topmost matching rule wins and later rules are skipped. This top-to-bottom precedence satisfies the stem's ordering constraint, letting administrators position specific traffic-steering rules above broader catch-all rules to control path selection deterministically.

Why this answer

SD-WAN rules in FortiManager (and on FortiGate) are evaluated top to bottom, and the first rule whose match criteria are satisfied is applied. Order therefore directly determines which path selection logic wins, making rule sequencing a critical design decision. This mirrors the behavior of firewall policies and other ordered rule sets.

Exam trap

The trap is assuming SD-WAN rules are ordered by some automatic criterion like speed or creation time, when the exam is testing that they are evaluated sequentially from top to bottom like firewall policies.

How to eliminate wrong answers

Option B is wrong because creation date is not used for ordering — rules can be reordered at any time regardless of when they were created. Option C is wrong because interface speed is a criterion a rule might match on, not the ordering mechanism. Option D is wrong because random ordering would make SD-WAN behavior non-deterministic and unmanageable, which is not how the system works.

Full explanation →

MCQmedium

Which object must be created before assigning a health check to an SD-WAN service rule in an SD-WAN template?

A.An SD-WAN Health Check

B.A routing protocol

C.A firewall address object

D.An SD-WAN Zone

AnswerA

An SD-WAN health check object must exist first, because the service rule references it by name to determine link quality and steer traffic. This satisfies the stem's prerequisite ordering before assignment within the SD-WAN template.

Why this answer

In Fortinet SD-WAN, a health check must be defined as an SD-WAN Health Check object before it can be referenced in an SD-WAN service rule. The service rule uses the health check to monitor the status of the specified SLA targets (e.g., latency, jitter, packet loss) and to determine which member links are eligible for traffic steering. Without a preconfigured health check, the service rule has no monitoring mechanism to evaluate link quality, so the assignment cannot be made.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the dependency order of SD-WAN configuration objects, and candidates may mistakenly believe that an SD-WAN zone or routing protocol is required before assigning a health check, when in fact the health check object itself must be created first.

How to eliminate wrong answers

Option B is wrong because a routing protocol (e.g., BGP, OSPF) is used for dynamic route exchange and is not a prerequisite for assigning a health check to an SD-WAN service rule; SD-WAN health checks operate independently of routing protocols. Option C is wrong because a firewall address object defines IP addresses or subnets for policy matching and has no role in SD-WAN health monitoring or service rule configuration. Option D is wrong because an SD-WAN zone is a logical grouping of interfaces that can be used in SD-WAN rules, but it is not required specifically for assigning a health check; the health check object itself must exist first.

Full explanation →

Multi-Selecthard

An enterprise network uses OSPF over SD-WAN IPsec tunnels. The administrator notices that OSPF adjacency is constantly dropping over a specific backup SD-WAN member link due to intermittent packet loss. Which THREE configuration adjustments can improve OSPF stability over unstable SD-WAN IPsec links? (Choose three)

Select 3 answers

A.Configure OSPF network type as point-to-point on the IPsec tunnel interfaces to eliminate unnecessary DR/BDR elections

B.Enable OSPF graceful restart or helper mode on the FortiGate routers

C.Set the OSPF router ID to 0.0.0.0 on all branch spokes

D.Increase the OSPF hello interval and dead interval on the affected IPsec tunnel interfaces to tolerate temporary packet loss

E.Disable OSPF hello packets entirely and rely on static default routes

AnswersA, B, D

Point-to-point network type removes DR/BDR election and waiting timers on the IPsec tunnel, so intermittent loss cannot trigger adjacency resets through election churn. This directly addresses the instability caused by the backup link's packet loss.

Why this answer

Option A is correct because configuring the OSPF network type as point-to-point on the IPsec tunnel interfaces removes the DR/BDR election process, which is unnecessary on a tunnel that connects only two routers and whose election churn can cause adjacency resets during packet loss. Option B is correct because enabling OSPF graceful restart (and helper mode on the neighbor) allows a restarting or flapping router to keep forwarding traffic and preserve adjacencies without tearing down and relearning routes, which directly improves stability over intermittent SD-WAN links. Option D is correct because increasing the hello and dead intervals makes OSPF more tolerant of temporary packet loss, since the dead interval is typically 4x the hello interval and a longer timer prevents the adjacency from being declared down during brief outages.

Option C is incorrect because a router ID of 0.0.0.0 is invalid for OSPF and would prevent the router from forming adjacencies or participating in the OSPF domain. Option E is incorrect because OSPF relies on hello packets to discover and maintain neighbors; disabling them would break adjacency formation and force reliance on static routes, which is not an OSPF stability adjustment.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates know that OSPF router ID 0.0.0.0 is invalid and that disabling hellos breaks OSPF — both are distractors that sound plausible but violate protocol fundamentals.

Full explanation →

MCQmedium

When creating an SD-WAN template, what must be defined before you can add an SD-WAN interface to the template?

A.Individual SD-WAN member interfaces

B.The SD-WAN health check probes

C.Global firewall policies

D.The virtual domain (VDOM) settings

AnswerA

An SD-WAN interface is a logical overlay aggregating physical links, so FortiManager cannot build it until the underlying member interfaces exist. Defining those individual SD-WAN member interfaces first gives the template the concrete members it references, satisfying the prerequisite before the SD-WAN interface can be added.

Why this answer

In FortiManager, an SD-WAN template requires the underlying SD-WAN member interfaces to be defined first, because the SD-WAN interface is a logical overlay that aggregates those physical or logical member links. Without member interfaces, there is nothing for the SD-WAN zone to bind to, so FortiManager will not allow you to add the SD-WAN interface to the template.

Exam trap

The trap is that candidates assume health checks or firewall policies are prerequisites, when in fact the SD-WAN interface is a logical construct that must reference concrete member interfaces before it can exist.

How to eliminate wrong answers

Option B is wrong because health check probes are configured as part of the SD-WAN configuration but are not a prerequisite for adding the SD-WAN interface itself — they are defined after or alongside the SD-WAN interface. Option C is wrong because global firewall policies are unrelated to the SD-WAN template creation sequence and are configured separately. Option D is wrong because VDOM settings are an administrative scoping construct, not a dependency for adding an SD-WAN interface to a template.

Full explanation →

MCQeasy

What is required before FortiManager can display SD-WAN monitoring data?

A.The FortiGate must have a cloud license

B.The FortiGate must be sending logs to FortiManager

C.The FortiGate must be running a specific firmware

D.The FortiGate must be in Transparent mode

AnswerB

FortiManager renders SD-WAN monitoring from the log messages FortiGates forward, not from live telemetry or API polling. Without those logs arriving, the SD-WAN dashboards and SLA widgets stay empty. Enabling log forwarding to FortiManager therefore satisfies the prerequisite the stem asks about.

Why this answer

FortiManager displays SD-WAN monitoring data by receiving logs from the FortiGate. The FortiGate must be configured to send logs to FortiManager, typically via the 'log fortianalyzer' or 'log fortimanager' settings. Without logs, FortiManager has no data to display for SD-WAN monitoring, such as performance SLAs, link status, and traffic statistics.

Exam trap

The trap is assuming that FortiManager automatically collects SD-WAN data without explicit log configuration; candidates might overlook the need for the FortiGate to send logs.

How to eliminate wrong answers

Option A is wrong because a cloud license is not required for SD-WAN monitoring; FortiManager can monitor on-premises FortiGates without cloud licenses. Option C is wrong because while a specific firmware version may be needed for certain features, the fundamental requirement is log sending, not just firmware. Option D is wrong because Transparent mode is unrelated to SD-WAN monitoring; FortiGates can be in NAT/route mode and still send logs.

Full explanation →

MCQmedium

When setting up a Performance SLA, what is the 'Participant' setting?

A.The monitoring interval.

B.The user group assigned to the probe.

C.The destination IP address.

D.The SD-WAN member that originates the probe.

AnswerD

The Participant identifies the specific SD-WAN member that generates and sends the probe traffic, anchoring the SLA measurement to a defined source. This determines which member's performance is evaluated against the SLA thresholds for latency, jitter and packet loss.

Why this answer

In a FortiGate Performance SLA, the 'Participant' setting specifies which SD-WAN member (interface) originates the health check probes. Each member that should be monitored must be added as a participant, and the SLA measures latency, jitter, and packet loss from that member to the configured server.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the distinction between the SLA 'server' (destination) and 'participant' (source member), causing candidates to confuse the two and select the destination IP as the Participant.

How to eliminate wrong answers

Option A is wrong because the monitoring interval is configured separately as 'interval' and 'timeout' within the SLA settings, not as the Participant. Option B is wrong because user groups are not assigned to Performance SLA probes — identity is not part of health check configuration. Option C is wrong because the destination IP address is configured as the 'server' in the SLA, not the Participant; the Participant is the source member.

Full explanation →

MCQhard

A FortiGate device is running ADVPN 2.0 with OSPF. A spoke experiences transient routing loops when a shortcut tunnel tears down due to inactivity timeout. Which configuration adjustment on the FortiGate hub and spokes prevents these temporary routing blackholes or loops during shortcut teardown?

A.Disable OSPF on the spoke units and rely entirely on static default routes

B.Adjust the administrative distance or use route redistribution filters with appropriate metrics so hub routes and shortcut routes do not conflict during teardown

C.Set the IPsec phase 1 lifetime to infinite to prevent shortcuts from timing out

D.Configure asymmetric routing bypass on all firewall policies

AnswerB

During shortcut teardown, the hub-advertised route and the withdrawn shortcut route can briefly coexist with equal preference, causing loops or blackholes. Raising administrative distance or applying redistribution filters with distinct metrics ensures the hub path is preferred deterministically until the shortcut is fully removed.

Why this answer

ADVPN 2.0 shortcut tunnels are dynamically created direct spoke-to-spoke IPsec tunnels, and when they tear down due to inactivity, the routing table must reconverge so traffic falls back to the hub. If OSPF metrics or administrative distances cause the hub-learned route and the shortcut route to conflict during teardown, transient loops or blackholes occur. Adjusting administrative distance or using redistribution filters with appropriate metrics ensures the hub route is preferred only when the shortcut is gone, preventing the race condition.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates understand that ADVPN shortcut teardown is a routing convergence problem, not a tunnel-lifetime problem — the trap is picking 'infinite phase 1 lifetime' or 'disable OSPF' instead of metric/administrative-distance tuning.

How to eliminate wrong answers

Option A is wrong because disabling OSPF on spokes and relying on static default routes eliminates dynamic routing entirely, which breaks ADVPN's ability to advertise shortcuts and defeats the purpose of the architecture. Option C is wrong because setting IPsec phase 1 lifetime to infinite does not prevent shortcut inactivity timeouts — those are controlled by separate idle-timeout and shortcut-related settings, and an infinite lifetime would create stale SAs rather than solve the routing race. Option D is wrong because asymmetric routing bypass is a firewall policy setting that allows return traffic on a different path; it does not address OSPF route convergence or the metric conflict during shortcut teardown.

Full explanation →

Multi-Selectmedium

Which TWO of the following are necessary to successfully deploy an SSL VPN in tunnel mode?

Select 2 answers

A.An IPSec phase 1 configuration

B.A BGP session with the client

C.A valid SSL certificate for the VPN portal

D.A firewall policy allowing the SSL VPN interface to the Internal zone

E.A dedicated hardware switch

AnswersC, D

Tunnel-mode SSL VPN presents a portal over HTTPS, so a valid SSL certificate matching the portal's hostname is required. Without it, browsers reject the connection, preventing the tunnel from being established as the scenario demands.

Why this answer

Option C is correct because tunnel-mode SSL VPN relies on TLS to establish the encrypted session, so the VPN portal must present a valid SSL certificate that clients can validate during the TLS handshake. Option D is correct because once the tunnel is established, traffic from the SSL VPN interface must be permitted by a firewall policy into the Internal zone; otherwise, authenticated users cannot reach internal resources. Option A is incorrect because IPSec phase 1 (IKE SA) applies to IPSec VPNs, not SSL/TLS-based VPNs.

Option B is incorrect because BGP is a dynamic routing protocol between routers and is not required for an SSL VPN client tunnel. Option E is incorrect because SSL VPN functionality is a software feature and does not require a dedicated hardware switch.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the misconception that SSL VPN tunnel mode requires IPsec Phase 1 settings, confusing it with IPsec dial-up VPNs that do use IKE Phase 1 and Phase 2.

Full explanation →

MCQmedium

A FortiGate is operating in transparent mode. What is the default behavior when the device receives a frame with an unknown MAC address?

A.Drop the packet

B.Flood to all ports

C.Forward to the management interface

D.Send an ICMP unreachable message

AnswerB

In transparent mode the FortiGate forwards frames by MAC address; an unknown destination MAC triggers flooding out all ports except the ingress, mirroring switch behaviour. This satisfies the stem's default-behaviour constraint for unrecognised MAC addresses.

Why this answer

In transparent mode, a FortiGate acts as a Layer 2 bridge and learns MAC addresses from incoming frames. When it receives a frame destined for a MAC address not present in its forwarding table (unknown unicast), the default behavior is to flood the frame out all ports in the same broadcast domain except the ingress port — standard Ethernet bridge behavior. This ensures the frame reaches its destination even before the MAC is learned.

Exam trap

The trap is assuming transparent mode behaves like a router (dropping or sending ICMP for unknown destinations) — candidates forget that transparent mode is fundamentally a Layer 2 bridge, so flooding is the correct default for unknown MACs.

How to eliminate wrong answers

Option A is wrong because dropping unknown unicast frames would break basic Layer 2 connectivity; bridges must flood unknown destinations to discover where hosts reside. Option C is wrong because forwarding to the management interface would be a security risk and is not how transparent-mode bridging works — the management interface is separate from the data plane. Option D is wrong because ICMP unreachable is a Layer 3 mechanism; transparent mode operates at Layer 2 and does not generate ICMP messages for unknown MAC addresses.

Full explanation →

MCQhard

If you modify a shared SD-WAN health check object that is referenced by ten different templates, what happens to the FortiGates?

A.All FortiGates using those templates will be affected after an install

B.The FortiGates will automatically revert to the old settings

C.The health check will be disabled on all devices

D.Only the templates are updated, not the FortiGates

AnswerA

Shared health check objects are referenced, not copied, by templates. Editing the object changes the definition held centrally, so every FortiGate bound to those ten templates receives the updated SLA parameters at the next policy install, altering member selection and failover behaviour network-wide.

Why this answer

In FortiManager, SD-WAN health check objects are shared objects that can be referenced by multiple templates. When you modify a shared object, the change is stored in the ADOM and must be installed to the managed FortiGates. After the install, all FortiGates using templates that reference that health check will receive the updated configuration.

Exam trap

The trap is assuming that modifying a shared object only affects the template definition and not the devices; in FortiManager, shared objects propagate to all devices that reference them after an install.

How to eliminate wrong answers

Option B is wrong because FortiGates do not automatically revert to old settings; they retain the last installed configuration until a new install pushes changes. Option C is wrong because modifying a health check does not disable it; it updates its parameters (e.g., interval, failtime) and the object remains active. Option D is wrong because templates are not the final target; the change must be installed to the FortiGates, and all devices referencing the object are affected.

Full explanation →

MCQmedium

What is the maximum number of members allowed in a single SD-WAN zone?

A.8

B.2

C.4

D.Depends on the model, but generally limited by system resources.

AnswerD

FortiGate does not publish a fixed member ceiling per SD-WAN zone; the practical limit depends on the appliance model's memory and CPU resources. Higher-capacity platforms support more members, so the answer reflects hardware capability rather than a universal numeric maximum.

Why this answer

The maximum number of members in a single SD-WAN zone is not a fixed hard-coded number; it depends on the FortiGate model and is ultimately bounded by available system resources such as memory and CPU. Fortinet does not publish a universal cap like 4 or 8, and different platforms support different scales. Therefore the correct answer is the model/resource-dependent option.

Exam trap

The trap is looking for a fixed numeric answer (4, 8, 2) when Fortinet deliberately leaves the SD-WAN member limit model-dependent — candidates who memorize a number instead of the principle get it wrong.

How to eliminate wrong answers

Option A is wrong because 8 is not a universal limit — some models support more, and it is not a documented fixed maximum. Option B is wrong because 2 is far too low; even entry-level FortiGates support more than two SD-WAN members. Option C is wrong because 4 is also an arbitrary number not tied to FortiOS documentation; the real constraint is platform capacity.

Full explanation →

MCQmedium

In an ADVPN 2.0 deployment, a hub unit uses BGP to advertise routes to spokes. When a spoke learns a prefix via BGP from the hub, what mechanism allows the spoke to automatically initiate an ADVPN shortcut tunnel directly to another spoke when traffic flows between them?

A.The FortiGate kernel detects traffic matching a dynamic BGP route over the IPsec interface and initiates an IKE shortcut negotiation with the target spoke

B.OSPF sends a special multicast hello packet across the hub to establish mesh point-to-point links

C.FortiManager pushes a dynamic static route to both spokes simultaneously

D.The Web Filtering profile intercepts the packet and redirects it via proxy to the destination spoke

AnswerA

The FortiGate kernel monitors traffic egressing the ADVPN IPsec interface and matching a BGP-learned route; this triggers an IKE negotiation directly with the destination spoke, establishing the shortcut. This satisfies the requirement for automatic, traffic-driven shortcut initiation without hub involvement in the data path.

Why this answer

In ADVPN 2.0, the spoke learns a BGP route to a remote spoke's subnet via the hub. When traffic matches that route and is sent over the IPsec interface to the hub, the FortiGate kernel detects it and triggers an IKE shortcut negotiation directly with the target spoke, establishing a direct tunnel. This is the core ADVPN shortcut mechanism.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the data-plane trigger for ADVPN shortcuts, tempting candidates with control-plane mechanisms like OSPF or FortiManager pushes that do not initiate shortcuts.

How to eliminate wrong answers

Option B is wrong because OSPF multicast hellos are not used to establish ADVPN shortcuts; ADVPN uses BGP and IKE. Option C is wrong because FortiManager does not push dynamic static routes to establish shortcuts; shortcut establishment is data-plane triggered. Option D is wrong because Web Filtering is a security profile, not a routing or tunnel establishment mechanism.

Full explanation →

MCQhard

During SD-WAN template deployment, what is the role of 'Dynamic Mapping'?

A.To map a single template object to different physical settings on different devices

B.To automate firmware updates

C.To monitor bandwidth usage

D.To dynamically change the SD-WAN rule based on time

E.To calculate the latency of paths

AnswerA

Dynamic Mapping lets one template object resolve to different physical interfaces or settings per device, so a single template fits heterogeneous hardware. This satisfies the stem's requirement to map one object across differing device configurations.

Why this answer

Dynamic Mapping in SD-WAN template deployment allows a single template object (like an interface or SD-WAN rule) to be mapped to different physical settings on different devices. This enables flexibility when deploying the same template to multiple FortiGates with varying interface names or configurations. It uses variables and metadata to adapt the template to each device's specifics.

Exam trap

The trap is confusing Dynamic Mapping with dynamic SD-WAN rules or performance monitoring; candidates might think it's about changing rules dynamically, but it's about mapping template objects to device-specific settings.

How to eliminate wrong answers

Option B is wrong because automating firmware updates is unrelated to Dynamic Mapping; that is handled by FortiManager's firmware management features. Option C is wrong because monitoring bandwidth usage is a function of SD-WAN monitoring, not mapping. Option D is wrong because dynamically changing SD-WAN rules based on time is handled by SD-WAN rules with schedules, not Dynamic Mapping.

Option E is wrong because calculating latency is part of SD-WAN performance SLAs, not mapping.

Full explanation →

Multi-Selectmedium

Which TWO administrative actions require a 'Workspace Mode' enabled in FortiManager?

Select 2 answers

A.Automatic log rotation

B.Creating new ADOMs

C.Forcing a reboot

D.Locking policies for editing

E.Reviewing changes before publishing

AnswersD, E

Workspace Mode creates a private editing workspace so an administrator can lock policies while modifying them, preventing concurrent edits by others. Locking policies for editing therefore requires Workspace Mode, satisfying the stem's condition for actions unavailable in normal workflow mode.

Why this answer

In FortiManager, Workspace Mode is the workflow that lets administrators lock objects (such as policies) for editing and then review pending changes before publishing them to managed devices, so options D and E are exactly the actions that require it. Locking policies for editing (D) is only meaningful inside Workspace Mode, because the lock prevents other admins from modifying the same policy while changes are staged. Reviewing changes before publishing (E) is the second half of that workflow, since FortiManager queues modifications in the workspace and requires an explicit review/publish step.

The other options do not depend on Workspace Mode: automatic log rotation (A) is a logging/disk-management setting, creating new ADOMs (B) is a system-level administrative task performed outside the workspace workflow, and forcing a reboot (C) is a device/system operation available regardless of workspace state.

Exam trap

The trap is assuming any administrative action requires Workspace Mode, when in fact only actions involving staged editing, locking, and review/publish workflows do.

Full explanation →

MCQmedium

When using SD-WAN templates, which option allows you to manage different ISPs on different branches within the same template?

A.Dynamic Mapping

B.Global Objects

C.Device Groups

D.SD-WAN Rules

AnswerA

Dynamic Mapping lets a single SD-WAN template assign interfaces per branch based on variables such as interface role or ISP, rather than fixed names. This satisfies the stem's constraint of managing different ISPs across branches within one template.

Why this answer

Dynamic Mapping in SD-WAN templates lets you bind template variables to per-device values, so the same template can reference different ISP interfaces (e.g., wan1 vs. wan2, or different ISP names) on different branches. When the template is installed, FortiManager resolves each variable against the device's metadata, producing branch-specific SD-WAN configurations from one template. This is the mechanism Fortinet designed specifically for multi-ISP, multi-branch template reuse.

Exam trap

FORTINET-NSE7-SPECIALTY often tests template-reuse mechanisms — candidates confuse Device Groups (organizational) or SD-WAN Rules (traffic steering) with Dynamic Mapping (per-device variable substitution), which is the only option that actually varies ISPs per branch within one template.

How to eliminate wrong answers

Option B is wrong because Global Objects are shared address/service objects (firewall addresses, VIPs, etc.) used across policies — they don't map template placeholders to per-device interface values. Option C is wrong because Device Groups are a FortiManager organizational construct for grouping managed devices for policy assignment; they don't resolve per-branch ISP differences inside a single SD-WAN template. Option D is wrong because SD-WAN Rules define traffic-steering logic (which traffic uses which member), not the mapping of template variables to per-device ISP interfaces.

Full explanation →

Multi-Selectmedium

Which TWO actions can be performed on a Revision History item in FortiManager?

Select 2 answers

A.Compare with current version

B.Restore to a previous state

C.Delete the entire ADOM

D.Export the revision to an external cloud

E.Modify the version permanently

AnswersA, B

Revision History entries can be compared against the current configuration, displaying a side-by-side or inline diff of changed objects. This satisfies the requirement to identify exactly what differs between a saved revision and the live FortiManager database before deciding whether to restore it.

Why this answer

In FortiManager, a Revision History item represents a saved configuration snapshot of an ADOM or policy package, and option A (Compare with current version) is correct because FortiManager provides a diff view that shows the differences between the selected revision and the current running configuration. Option B (Restore to a previous state) is also correct because you can revert the ADOM or policy package back to that saved revision, effectively rolling back configuration changes. Option C (Delete the entire ADOM) is wrong because deleting an ADOM is an ADOM-level administrative action, not an operation available on an individual revision history entry.

Option D (Export the revision to an external cloud) is wrong because FortiManager does not offer a cloud export function for revision items; revisions are stored locally in the FortiManager database. Option E (Modify the version permanently) is wrong because revisions are immutable snapshots — you cannot edit a saved revision in place, only compare, restore, or delete it.

Exam trap

Fortinet NSE7 exams often test whether candidates know the exact scope of Revision History actions — the trap is picking plausible-sounding but non-existent features like 'export to cloud' or 'modify version permanently,' when the only real actions are compare and restore.

Full explanation →

Multi-Selectmedium

An administrator applies security profiles (Antivirus, Web Filtering, and IPS) to traffic steered by an SD-WAN rule. Performance issues arise. Which TWO methods can the administrator use to optimize inspection performance without completely disabling security? (Choose two)

Select 2 answers

A.Switch the inspection mode from proxy-based to flow-based where supported, allowing hardware offloading (NP6/NP7) to accelerate packet processing

B.Set the IPsec Phase 1 encryption algorithm to DES to speed up decryptions

C.Configure security profile exemptions or antivirus inspection overrides for trusted internal subnets or latency-sensitive VoIP traffic

D.Disable all SSL inspection globally across the entire FortiGate device

E.Remove the SD-WAN virtual interface from all firewall zones

AnswersA, C

Flow-based inspection permits FortiOS to offload sessions to NP6/NP7 processors, whereas proxy-based mode forces traffic through the CPU. This satisfies the constraint of retaining Antivirus, Web Filtering and IPS while restoring throughput on SD-WAN-steered traffic.

Why this answer

Option A is correct because switching from proxy-based to flow-based inspection where the FortiGate model supports it allows traffic to be accelerated by network processors (NP6/NP7) via hardware offloading, which dramatically reduces CPU load and latency while still applying Antivirus, Web Filtering, and IPS security. Option C is correct because configuring security profile exemptions or antivirus inspection overrides for trusted internal subnets or latency-sensitive VoIP traffic lets the administrator bypass heavy inspection only for specific low-risk or delay-sensitive flows, preserving security for the rest of the traffic. Option B is wrong because DES is a weak, deprecated cipher that does not meaningfully improve IPsec performance and would degrade security rather than optimize inspection.

Option D is wrong because disabling SSL inspection globally removes a critical security control and does not address the SD-WAN inspection performance issue in a targeted way. Option E is wrong because removing the SD-WAN virtual interface from all firewall zones would break the SD-WAN routing and policy enforcement entirely, not optimize inspection.

Exam trap

FORTINET-NSE7-SPECIALTY often tests performance-vs-security tradeoffs — candidates pick 'disable SSL inspection' or 'disable profiles' as the fix, missing that flow-based offload and scoped exemptions preserve security while restoring performance.

Full explanation →

MCQeasy

Which configuration mode allows you to define a virtual MAC address for an HA cluster to prevent ARP cache issues on switches?

A.DHCP relay

B.Static ARP

C.Virtual MAC

D.Physical MAC

AnswerC

Virtual MAC mode assigns a cluster-wide MAC shared by both units, so connected switches never see a changed source MAC after failover and their ARP caches stay valid. This directly satisfies the stem's requirement to prevent ARP cache issues.

Why this answer

In a FortiGate HA cluster, configuring a virtual MAC address ensures that the cluster's interfaces present a consistent MAC address to the network, regardless of which unit is active. This prevents ARP cache issues on switches and routers, as they see the same MAC for the cluster IP even after a failover. The virtual MAC is defined under the HA configuration and is used by the primary unit to send gratuitous ARP updates.

Exam trap

The trap is confusing virtual MAC with static ARP or physical MAC; candidates might think static ARP solves HA ARP issues, but it's the virtual MAC that provides seamless failover.

How to eliminate wrong answers

Option A is wrong because DHCP relay is used to forward DHCP requests between subnets and has no role in HA MAC addressing. Option B is wrong because static ARP entries are manually configured on hosts or switches and do not provide a dynamic, cluster-wide virtual MAC for HA. Option D is wrong because using the physical MAC of the active unit would cause ARP caches to become stale upon failover, leading to connectivity issues.

Full explanation →

MCQeasy

When configuring an SD-WAN health check to monitor internet reachability using HTTP/HTTPS requests, which parameter defines the specific string the FortiGate expects to receive in the server response body to validate that the path is healthy?

A.probe-packet-size

B.sla-break-time

C.http-match

D.server-response-timeout

AnswerC

The http-match parameter specifies the literal string FortiGate searches for in the HTTP or HTTPS response body; the health check only marks the path alive when that string is present, satisfying the stem's requirement to validate reachability by matching expected response content.

Why this answer

The http-match parameter in an SD-WAN health check defines the exact string that the FortiGate searches for in the HTTP/HTTPS response body to confirm the probe succeeded. When the FortiGate sends an HTTP GET to the configured URL, it compares the returned payload against this string; a mismatch marks the SLA member as failed. This allows administrators to validate not just TCP reachability but actual application-layer health.

Exam trap

The trap here is confusing the response-content validator (http-match) with timing or sizing parameters (server-response-timeout, probe-packet-size) that also appear in the health-check CLI — candidates often pick the timeout parameter thinking it validates the response.

How to eliminate wrong answers

Option A is wrong because probe-packet-size controls the size of the ICMP/echo payload used in ping-based health checks, not the expected HTTP response content. Option B is wrong because sla-break-time is the number of consecutive failed probes (or time window) before the SLA is considered violated, not a response-matching string. Option D is wrong because server-response-timeout defines how long the FortiGate waits for a reply before declaring the probe failed, not what content it expects to see.

Full explanation →

Multi-Selectmedium

Which THREE of the following criteria are used for SD-WAN rule traffic matching?

Select 3 answers

A.Interface speed

B.Destination address

C.VLAN priority

D.Application/Service

E.Source address

AnswersB, D, E

Destination address is one of the SD-WAN rule matching criteria, letting you steer traffic toward specific remote subnets or hosts across member links. It satisfies the stem by matching on the packet's destination IP, evaluated alongside source address and application/service to select the outbound member.

Why this answer

In FortiGate SD-WAN rules, traffic matching is performed using criteria such as destination address (B), application/service (D), and source address (E), which are all standard SD-WAN rule match objects that identify which traffic should be steered. Destination address (B) and source address (E) match on IP prefixes or address objects, while application/service (D) matches on recognized applications or service definitions, allowing policy-based steering. Interface speed (A) is not a match criterion; it is a property of the member interface used for load-balancing decisions, not for classifying traffic.

VLAN priority (C) is also not an SD-WAN rule match criterion; VLAN/802.1p priority is handled through QoS and traffic shaping, not through SD-WAN rule matching.

Exam trap

FORTINET-NSE7-SPECIALTY often tests the distinction between SD-WAN rule match criteria (source, destination, application, service) and link/SLA attributes (interface speed, jitter, latency) that are used for member selection rather than matching.

Full explanation →

MCQhard

You are troubleshooting a policy installation failure where the FortiManager reports a 'Configuration conflict'. Which action should you perform to identify the root cause of the mismatch?

A.Force an 'Import Policy' operation

B.Reboot the FortiManager

C.Disable the policy package entirely

D.Use the 'Diff' feature in the Policy & Objects tab to compare the database and device config

AnswerD

The 'Diff' feature compares FortiManager's policy database against the managed device's running configuration, exposing exactly which objects or rules diverge. This directly satisfies the stem's need to identify the root cause of the 'Configuration conflict' mismatch before remediation, rather than guessing or reinstalling blindly.

Why this answer

When FortiManager reports a 'Configuration conflict' during policy installation, the root cause is usually a mismatch between the FortiManager policy package/database and the actual configuration on the FortiGate. The 'Diff' feature in the Policy & Objects tab compares the FortiManager database against the device configuration line-by-line, exposing exactly which objects, policies, or settings differ. This is the correct diagnostic step before deciding whether to import, overwrite, or reconcile.

Exam trap

FORTINET-NSE7-SPECIALTY often tests whether candidates jump to 'Import Policy' as a fix for conflicts — but Import overwrites FortiManager's intent, whereas Diff is the diagnostic tool that reveals the actual mismatch.

How to eliminate wrong answers

Option A is wrong because forcing an Import Policy would overwrite FortiManager's database with the device config, potentially destroying the intended policy design and masking the root cause rather than identifying it. Option B is wrong because rebooting FortiManager does not resolve configuration mismatches and may disrupt other managed devices. Option C is wrong because disabling the policy package removes it from installation scope entirely, which does not diagnose the conflict and leaves the device unmanaged.

Full explanation →

Fortinet NSE7 Specialty Modules (SD-WAN and Enterprise Firewall tracks) (FORTINET-NSE7-SPECIALTY) (FORTINET-NSE7-SPECIALTY) — Questions 1–75