Nse7 SD Wan Central Management practice questions

fmg_event.log

Why it fails: This tracks general system events.

fmg_audit.log

Why it fails: fmg_audit.log records configuration changes and administrative actions, not template-push CLI execution, so it cannot identify the failing command. It is tempting because audit logs do track who changed what, making them the right choice when investigating unauthorised configuration edits or verifying change history on FortiManager.

fmg_system.log

Why it fails: The fmg_system.log records FortiManager daemon and system-level events, not the per-command CLI output generated when an SD-WAN template installs to a managed FortiGate. It is tempting because it does capture provisioning and system errors, and would be the right choice when diagnosing FortiManager service failures rather than template push command rejection.

System Settings > SD-WAN

Why it fails: System Settings manages FortiManager itself.

Policy & Objects > Firewall Policy

Why it fails: That is for standard firewall policies.

Log View > SD-WAN

Why it fails: Log View is for troubleshooting.

Loopback interfaces

Why it fails: SD-WAN members must be physical or VLAN interfaces carrying WAN traffic; loopback interfaces are logical, host-only interfaces with no link-layer connectivity, so they cannot participate. They are tempting because loopbacks provide stable router IDs and management reachability, which is their actual purpose.

Aggregate interfaces

Why it fails: Aggregate interfaces bundle multiple physical links into one logical interface; SD-WAN membership requires the underlying physical or VLAN interfaces, so an aggregate cannot serve as a member. Aggregates are tempting because they provide redundancy and increased bandwidth at layer 2, which is their genuine role.

The changes take effect immediately without a push

Why it fails: Modifying an applied SD-WAN template requires an explicit install to push changes; they do not take effect immediately. Immediate effect is tempting because some FortiManager objects propagate on save, but template changes need a policy package installation to reach the FortiGate.

The FortiGate automatically pulls the new config

Why it fails: FortiGates do not autonomously pull configuration; FortiManager pushes changes through an install operation. Automatic pull is tempting because FortiGate devices do poll FortiManager for updates, but SD-WAN template modifications still require the administrator to install the policy package.

The FortiGate configuration is reverted

Why it fails: Modifying a template does not revert the FortiGate configuration; the device retains its current settings until a new install occurs. Reversion is tempting because FortiManager can restore previous revisions, which is its purpose in rollback scenarios, but editing a template alone does not trigger that.

To define the physical port speed

Why it fails: An SD-WAN zone groups member interfaces so rules and health checks reference the zone rather than individual links; it does not set physical port speed, which is configured on the interface itself. It is tempting because zones do contain interfaces, but speed negotiation is an interface-level property, not a zone function.

To limit bandwidth for specific users

Why it fails: An SD-WAN zone groups member interfaces for rule and health-check referencing; bandwidth limiting is enforced by traffic shaping policies or shapers, not by zone membership. It is tempting because zones bundle links that carry user traffic, but no per-user bandwidth control exists at zone level.

To isolate the SD-WAN traffic from the WAN

Why it fails: An SD-WAN zone groups member interfaces so rules and health checks target the zone; it does not isolate traffic from WAN, which is achieved through separate interfaces, VDOMs or policies. It is tempting because zones do logically separate link sets, but isolation is not their purpose.

Based on the creation date

Why it fails: SD-WAN rules are ordered by their sequence number within the template, not by creation date, so a rule created later can still sit above an earlier one. Creation date is merely metadata, useful for auditing or tracking when a rule was authored, but it plays no part in evaluation order.

By the interface speed

Why it fails: SD-WAN rules are evaluated in the order they appear in the rule list, so interface speed plays no part in sequencing. Speed is tempting because it feels like a natural ranking criterion, and it does influence member selection within a rule, but ordering itself is positional.

Randomly

Why it fails: Evaluation is deterministic.

A routing protocol

Why it fails: Health checks are assigned directly to SD-WAN members within a zone; no routing protocol object is a prerequisite. Routing protocols such as BGP or OSPF are configured separately for dynamic path selection, so they would be the answer only if the question asked how SD-WAN learns remote routes.

A firewall address object

Why it fails: Firewall address objects define IP subnets or FQDNs for policy matching, not SD-WAN member health. They are created when writing firewall policies or performance SLA targets, so they would be correct only if the question asked what identifies traffic in a policy, not what a health check binds to.

An SD-WAN Zone

Why it fails: An SD-WAN zone groups member interfaces, and the health check is assigned to those members, not to the zone object itself. Zones are created when organising multiple WAN links for load balancing, so they would be the answer if the question asked how members are grouped, not what precedes a health check.

The SD-WAN health check probes

Why it fails: Health check probes are referenced by SD-WAN members and SLA targets, not a prerequisite for adding the interface itself. It is tempting because probes are essential for measuring link quality, which is the correct step when configuring SLA-based steering, but the interface must exist before probes can be bound.

Global firewall policies

Why it fails: Global firewall policies are created after the SD-WAN template and its interfaces exist, so they cannot precede interface addition. It is tempting because policies eventually control traffic across SD-WAN members, which is correct when sequencing policy deployment, but they are not a template prerequisite.

The virtual domain (VDOM) settings

Why it fails: SD-WAN interface membership is defined per-VDOM, but the template itself already inherits the target device's VDOM context; VDOM settings are configured on the FortiGate or in a separate system template, not as a prerequisite step inside the SD-WAN template. It tempts because VDOMs do partition interface configuration.

To perform local traffic analysis on the FortiGate only

Why it fails: Central management pushes consistent SD-WAN configuration from FortiManager to managed FortiGates; local traffic analysis runs on the device and is unaffected by where templates are authored. Local analysis is tempting because FortiGates do perform it, but that is a device function, not the purpose of central SD-WAN management.

To allow FortiGates to manage their own SD-WAN interfaces independently

Why it fails: Central management exists precisely to remove per-device independent SD-WAN configuration, enforcing templates across many FortiGates from FortiManager. Independent device management is tempting because FortiGates can configure SD-WAN locally, which suits small deployments, but it defeats the centralised purpose asked about.

To bypass the need for ADOMs

Why it fails: ADOMs remain the administrative container for devices, policies and SD-WAN templates; central management operates within them rather than replacing them. Bypassing ADOMs is tempting because templates simplify multi-device rollout, but ADOM assignment still governs where objects and devices live.

By manually editing each FortiGate config

Why it fails: Editing each device individually is per-device work, so it cannot apply one template to many FortiGates at once. It is tempting because manual configuration is valid for one-off deployments, and it would be the correct approach when a single standalone FortiGate needs bespoke SD-WAN settings.

Through individual CLI console sessions

Why it fails: Separate CLI sessions still configure each FortiGate one at a time, so no simultaneous multi-device deployment occurs. It is tempting because CLI gives full control and is reliable for single-device changes, and it would be correct when troubleshooting or scripting one FortiGate directly.

By creating a global profile

Why it fails: A global profile governs settings such as security profiles or syslog, not SD-WAN template deployment, so it cannot push an SD-WAN template to managed devices. It is tempting because profiles are a FortiManager provisioning construct, and a global profile would be right for applying consistent policy objects across ADOMs.

Device Manager

Why it fails: Device Manager manages individual FortiGate configurations and firmware; it does not aggregate SD-WAN performance monitoring. It is tempting because Device Manager lists all managed devices, but cross-device SD-WAN performance visibility is provided by SD-WAN Monitor within FortiManager, not Device Manager.

Log View

Why it fails: Log View records historical log messages, not live SD-WAN link metrics such as latency, jitter and packet loss per member. It is tempting because it does aggregate FortiGate event data centrally, and would be the right choice for auditing past security or traffic events rather than real-time SLA monitoring.

Policy & Objects

Why it fails: Policy & Objects defines firewall policies, addresses and SD-WAN rules; it holds no live performance telemetry across managed FortiGates. It is tempting because SD-WAN members and health checks are configured there, making it the correct place to build the configuration, not to monitor its runtime behaviour.

Policy Packages

Why it fails: Policy packages bind firewall policy and objects to managed devices; they do not deliver SD-WAN template configuration. They are tempting because they are FortiManager's main provisioning construct, and they would be correct for standardising security policies across the 50 branches, not the SD-WAN settings.

Firmware Images

Why it fails: Firmware images only manage FortiOS version deployment to managed devices; they carry no SD-WAN configuration objects. They are tempting because firmware consistency across 50 branches is a genuine standardisation task, and they would be the right feature if the requirement were matching FortiOS builds rather than SD-WAN settings.

CLI Scripts

Why it fails: CLI scripts push raw command blocks to devices without template abstraction, so per-device variables and drift are not centrally reconciled. They are tempting because scripts can configure anything, and they would suit one-off or highly bespoke changes, but not repeatable standardised SD-WAN provisioning across 50 branches.

The FortiGate automatically creates a dummy interface

Why it fails: FortiManager installation fails with an error when a referenced interface is absent; no dummy interface is fabricated, because interface creation requires explicit configuration, not template inference. It tempts because FortiManager can auto-create some referenced objects, but physical and VLAN interfaces must pre-exist on the target FortiGate.

The installation proceeds and ignores the missing interface

Why it fails: Installation aborts and reports the missing interface rather than silently skipping it, since the SD-WAN member reference cannot resolve and the template is treated as invalid. It tempts because FortiManager ignores unrelated, unreferenced objects, but a referenced interface inside the SD-WAN block is a hard dependency.

The FortiGate enters an 'Emergency' state

Why it fails: A missing interface reference produces an installation error in FortiManager; the FortiGate does not enter Emergency mode, which is triggered by boot or filesystem failures, not template mismatches. It tempts because failed configuration pushes can leave a device in a degraded state, but Emergency mode is a separate boot-level condition.

To increase the number of VDOMs supported

Why it fails: Objects do not affect VDOM limits.

To allow FortiGates to share logs

Why it fails: Shared Objects in FortiManager SD-WAN store reusable configuration such as SLA targets and performance SLAs across multiple FortiGates; they do not aggregate or share log data. Log sharing is tempting because FortiAnalyzer handles centralised logging, but SD-WAN shared objects exist purely for consistent policy objects.

To create a site-to-site VPN

Why it fails: Shared Objects centralise reusable definitions such as health checks and SD-WAN members across multiple policy packages; site-to-site VPNs are built with VPN Manager. It is tempting because both span devices, but a VPN is a tunnel configuration, not a reusable object referenced by templates.

They allow for multiple internet service providers

Why it fails: Multiple ISP support comes from having several WAN interfaces as SD-WAN members, which works without zones. Zones exist to group and abstract member interfaces so identical template rules apply across many branches, which is the actual benefit when managing 100+ sites.

They automatically configure static routes

Why it fails: SD-WAN zones group member interfaces; they do not create or configure static routes, which are defined separately in the routing table. Automatic static route configuration is performed by routing or template features, so zones would be the answer only if the question asked about interface grouping, not route creation.

They increase the speed of the internet connection

Why it fails: Zones are a logical grouping construct and have no effect on link throughput or ISP bandwidth. Internet speed is determined by the underlying WAN circuits and their capacity, so zones would be relevant only if the question asked how member interfaces are organised, not how connection speed is increased.

The firmware version of the device

Why it fails: Health Check status reports SLA probe results such as latency, jitter and packet loss per member, not device firmware. Firmware version appears in device inventory or FortiGuard pages; it would be the answer only if the question asked about managed device software levels.

The number of active users

Why it fails: The SD-WAN Monitor Health Check status reports probe results such as latency, jitter, packet loss and SLA state for monitored links, not user counts. It is tempting because FortiManager dashboards display session and user data elsewhere, but active users are unrelated to health check output.

The current IP address of the interface

Why it fails: Health Check status reports probe state (alive/dead), latency, jitter and packet loss per SD-WAN member, not interface addressing. The interface IP appears in interface or SD-WAN member configuration views. Administrators troubleshooting reachability may expect an address here, but the monitor's health check column reflects SLA probe results instead.

To automate firmware updates

Why it fails: Dynamic Mapping resolves template variables such as interface names and IP addresses against each device's actual configuration during deployment; it performs no firmware management. Firmware updates are handled by FortiManager's firmware upgrade policies or FortiDeploy. This option tempts because SD-WAN template deployment does involve per-device automation, but the mechanism is variable substitution, not software distribution.

To monitor bandwidth usage

Why it fails: Dynamic Mapping resolves tunnel endpoints by binding interface roles to discovered WAN links, so bandwidth monitoring falls outside its function; that telemetry comes from performance SLAs and interface statistics. It tempts because Dynamic Mapping does drive link selection, and monitoring feeds those decisions, but it would be the answer only if the question asked how SD-WAN measures link quality.

To dynamically change the SD-WAN rule based on time

Why it fails: Dynamic Mapping binds SD-WAN members to interface roles by matching live link attributes, not by clock. It cannot alter rules on a schedule, so it fails this scenario. Time-based switching is what schedule objects handle, which would be the right choice when a rule must change at defined hours.

To calculate the latency of paths

Why it fails: Dynamic Mapping binds logical interface references in a template to physical interfaces on each device, so one template deploys across differing hardware. It does not measure path latency; that is performance SLA monitoring's function, which would be the right answer if the question asked how SD-WAN selects the best link.

Only WAN physical ports

Why it fails: SD-WAN members can include VLAN subinterfaces and IPsec tunnels, not just physical WAN ports. Restricting membership to physical WAN ports excludes VLAN-based and tunnel-based transports; the template accepts any interface type with an IP address, so this limitation is incorrect.

Only VLANs

Why it fails: VLANs are valid SD-WAN members, but so are physical ports, IPsec tunnels, and other IP-bearing interfaces. Limiting membership to VLANs alone excludes the physical WAN links and tunnels that SD-WAN templates commonly aggregate, so the restriction is wrong.

Only loopback interfaces

Why it fails: Loopback interfaces carry no forwarding path and cannot serve as SD-WAN members. The template accepts physical ports, VLANs, and IPsec tunnels that provide usable WAN transport; loopbacks exist for router-ID and management stability, not for traffic steering.

To eliminate the need for logs

Why it fails: Centralised policy does not affect logging; logs are configured separately per firewall policy or via FortiAnalyzer. It is tempting because centralised management consolidates configuration, but the actual benefit is consistent SD-WAN rule deployment across many FortiGates, not log elimination.

To reduce the CPU load on the FortiGate

Why it fails: Centralised policy does not offload FortiGate CPU; policies are still evaluated locally on each device. It is tempting because FortiManager centralises configuration, but the real gain is uniform SD-WAN rule rollout across many FortiGates, not reduced processing load.

To allow local admins to override global policies

Why it fails: Local admins cannot override global policies through a Centralized Policy; FortiManager pushes it read-only to managed FortiGates, and per-device overrides require separate local policy configuration. It is tempting because delegated administration is a genuine FortiManager feature, but that is achieved through ADOMs and workspace modes, not Centralized Policy, which exists to enforce uniform configuration across many devices.

The physical port priority

Why it fails: Performance SLA defines health-check probes (protocol, server, thresholds) that decide whether an SD-WAN member is alive and within latency, jitter and packet-loss limits. Port priority is tempting because both affect member selection, but priority is set on the member interface, not by the SLA.

The maximum bandwidth allowed

Why it fails: Performance SLA governs link health measurement, not traffic shaping; bandwidth limits belong to traffic shaping or per-rule bandwidth settings. Bandwidth is tempting because SLA breaches can trigger member removal, but the SLA itself sets probe thresholds, not a throughput ceiling.

The number of tunnels created

Why it fails: Performance SLA configures health-check probes and their thresholds; tunnel count is determined by how many SD-WAN members and overlays you define. Tunnel count is tempting because SLA state influences which tunnels carry traffic, but the setting measures link quality rather than creating or limiting tunnels.