39 of 264 questions · Page 4/4 · Enterprise Firewall and VDOMs · Answers revealed
Drag and drop the steps to configure a FortiGate as a DNS server (DNS proxy) into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Enable DNS proxy, set interface and port, configure upstream, set caching, then allow traffic.
An administrator needs to configure a FortiGate to allow inter-VDOM routing between VDOM-1 and VDOM-2. Which TWO actions are required? (Choose two.)
Correct.
Why this answer
Option A is correct because inter-VDOM routing requires explicit firewall policies on each VDOM to control and permit traffic traversing the VDOM link. Without these policies, the FortiGate will drop the traffic at the VDOM boundary, even if the VDOM link is up and IP addresses are configured.
Exam trap
The trap here is that candidates often assume inter-VDOM routing is automatically allowed once the VDOM link is created, forgetting that firewall policies are mandatory on both sides to explicitly permit the traffic.
An administrator wants to use FortiManager to manage multiple FortiGates, each in a separate customer environment. The administrator needs to isolate configuration changes per customer and ensure each customer's admin can only see their own devices. What FortiManager feature should be used?
ADOMs partition FortiManager into separate management domains, each with its own devices and policy packages, ensuring isolation.
Why this answer
Administrative Domains (ADOMs) in FortiManager allow the administrator to logically partition the management plane, isolating configuration changes per customer. Each ADOM can contain a set of FortiGates, and administrators assigned to an ADOM can only see and manage devices within that ADOM, ensuring strict separation of customer environments.
Exam trap
The trap here is that candidates often confuse VDOMs (a FortiGate-level virtualization feature) with ADOMs (a FortiManager-level management isolation feature), assuming that VDOMs on the managed devices can provide the administrative separation required at the FortiManager level, but VDOMs only virtualize the firewall itself, not the management plane in FortiManager.
How to eliminate wrong answers
Option B (Administrator profiles) is wrong because administrator profiles define permissions (read/write/access control) for a user but do not isolate which devices or configurations the user can see; they work in conjunction with ADOMs but cannot provide device-level isolation alone. Option C (Policy packages) is wrong because policy packages are containers for firewall policies that can be assigned to ADOMs or devices, but they do not enforce administrative isolation between customers; they are a configuration object, not a management boundary. Option D (VDOMs on managed FortiGates) is wrong because VDOMs are a FortiGate feature for virtualizing a single FortiGate into multiple logical firewalls, not a FortiManager feature for isolating management of multiple FortiGates; FortiManager uses ADOMs to manage VDOMs across devices, but VDOMs themselves do not provide the administrative separation required at the FortiManager level.
Drag and drop the steps to configure an HA cluster on FortiGate into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
First set HA mode and priority, then connect heartbeat, then configure management IP and VIP, and finally verify.
A FortiGate HA cluster is configured with VDOMs. Each VDOM is assigned to different physical interfaces. The cluster is in active-passive mode. Which TWO statements about VDOM synchronization in HA are correct?
All configuration, including VDOM-specific settings, is synchronized in an HA cluster.
Why this answer
Option A is correct because in a FortiGate HA cluster, VDOM configuration—including interfaces, policies, and other settings—is fully synchronized between cluster members. This ensures that both the active and passive units have identical VDOM configurations, enabling seamless failover without manual reconfiguration.
Exam trap
The trap here is that candidates often confuse VDOM-level failover behavior with global HA failover, mistakenly thinking a single VDOM failure triggers a full cluster failover, when in reality FortiGate HA only fails over on unit-level failures.
A network engineer is troubleshooting a Security Fabric where a downstream FortiGate (model 60F) is not appearing in the Fabric topology of the root FortiGate (model 600E). Both devices are running FortiOS 7.4. The root FortiGate shows the downstream device as 'Unreachable' in the Security Fabric widget. The engineer has verified that the downstream FortiGate can ping the root FortiGate's management IP. What is the most likely cause of this issue?
Low-end models may not meet the minimum memory requirements for Fabric operations.
Why this answer
The FortiGate 60F has limited memory (typically 512 MB or less), and FortiOS 7.4 enforces a minimum memory requirement for downstream devices to participate in the Security Fabric. When the downstream device has insufficient memory, the root FortiGate marks it as 'Unreachable' even though basic IP connectivity (ping) works. This is a known hardware limitation for lower-end models like the 60F when running newer FortiOS versions.
Exam trap
The trap here is that candidates assume connectivity issues (ping working) imply Fabric should work, but Fortinet deliberately tests the hardware memory limitation as a non-obvious cause for 'Unreachable' status in the Security Fabric topology.
How to eliminate wrong answers
Option A is wrong because HTTPS access from the root to the downstream is required for Fabric establishment, but the root already shows the downstream as 'Unreachable' (not 'Discovered' or 'Pending'), indicating the issue is not about HTTPS reachability; the root has already attempted discovery. Option C is wrong because the management interface VLAN mismatch would prevent the downstream from being discovered at all, yet the root sees the device (as 'Unreachable'), meaning Layer 3 connectivity exists. Option D is wrong because the administrator account on the downstream does not need 'super_admin' privileges for Fabric join; a 'profi_admin' or 'restricted_admin' with appropriate Fabric permissions is sufficient, and the root would not show 'Unreachable' if the account lacked privileges—it would show an authentication failure.
A FortiGate administrator is troubleshooting a scenario where traffic between two VDOMs is not working. The admin has configured inter-VDOM routing. Which TWO steps should the administrator verify? (Choose two.)
Return traffic must be permitted by a policy in the destination VDOM.
Why this answer
Option B is correct because inter-VDOM routing requires firewall policies in both the source and destination VDOMs to permit traffic. The destination VDOM must have a policy allowing the return traffic (from the destination to the source) for the session to be established. Without this, the FortiGate will drop the return packets, breaking the bidirectional flow.
Exam trap
The trap here is that candidates assume a single policy in the source VDOM is sufficient, overlooking that inter-VDOM routing requires explicit policies in both VDOMs to allow the forward and return traffic.
An administrator is deploying a FortiGate in transparent mode to seamlessly integrate into an existing network. The administrator needs to manage the FortiGate remotely over the network. Which configuration is required?
A management IP allows remote access to the FortiGate in transparent mode.
Why this answer
In transparent mode, FortiGate operates as a Layer 2 bridge and does not route traffic, so physical interfaces cannot have IP addresses. To enable remote management, a dedicated management IP must be configured under the VDOM settings, which allows the FortiGate to be reachable via protocols like HTTPS, SSH, or SNMP without participating in Layer 3 forwarding.
Exam trap
The trap here is that candidates often assume transparent mode still requires an IP on an interface (like a VLAN or physical port) for management, but FortiGate transparent mode uses a VDOM-level management IP that is not tied to any specific interface, which is a key distinction from routed mode.
How to eliminate wrong answers
Option B is wrong because creating a VLAN interface and assigning an IP is used in transparent mode only if the management IP is placed on a specific VLAN, but the question asks for the general requirement, and the management IP is configured under VDOM settings, not as a separate VLAN interface. Option C is wrong because assigning an IP address to physical interfaces is not allowed in transparent mode; interfaces remain unnumbered and operate at Layer 2. Option D is wrong because enabling DHCP client on interfaces is not applicable in transparent mode, as interfaces do not have IP addresses and the FortiGate does not obtain an IP via DHCP for management; the management IP is statically configured under VDOM settings.
A FortiGate in transparent mode is deployed in a data center. The admin notices that ARP requests from a downstream switch for the default gateway are not being answered. The FortiGate's management IP is configured on the same subnet as the switch. What is the most likely cause?
In transparent mode, the FortiGate should not have the management IP on the same broadcast domain as its interfaces; it must be on a dedicated management interface or VLAN.
Why this answer
In transparent mode, the FortiGate acts as a Layer 2 bridge and does not participate in ARP for traffic passing through it. However, the management IP is used for administrative access and must be unique on the network. If the management IP is configured on the same VLAN as the downstream switch, it creates an IP address conflict with the switch's own interface or the default gateway, causing the switch to either ignore or not forward ARP requests for that IP.
The FortiGate will not respond to ARP requests for the management IP if it detects a duplicate IP on the same broadcast domain, as per RFC 5227.
Exam trap
The trap here is that candidates assume transparent mode FortiGates always forward ARP transparently, but they forget that the management IP is a Layer 3 exception that must be unique and can cause ARP conflicts if placed on the same subnet as other devices.
How to eliminate wrong answers
Option B is wrong because port security on a switch typically limits MAC addresses per port or disables the port upon violation, but it does not prevent the FortiGate from responding to ARP requests for its management IP; the symptom described is a lack of ARP replies, not a port being err-disabled. Option C is wrong because FortiGate firewall policies operate at Layer 3 and above (IP, TCP, UDP) and do not filter or block ARP, which is a Layer 2 protocol; ARP handling is controlled by the kernel and interface settings, not by firewall policies. Option D is wrong because a full ARP table would prevent the FortiGate from learning new ARP entries, but it would not stop the FortiGate from responding to ARP requests for its own IP address; the device always replies to ARP requests for its own configured IPs regardless of table capacity.
In FortiManager, what is the purpose of an automation stitch?
Automation stitches respond to events with actions like scripts or notifications.
Why this answer
Automation stitches in FortiManager allow administrators to define a set of actions triggered by specific events (e.g., high CPU, failed login). These actions can include running CLI scripts, sending SNMP traps, or email notifications. Stitches enable automated responses to network events.
A FortiGate administrator needs to inspect traffic between two VLANs in the same VDOM. The administrator has configured a firewall policy that applies an antivirus profile, but traffic is passing without inspection. What should the administrator check first?
If the policy uses wrong interfaces, traffic may be matched by a different policy or by implicit deny.
Why this answer
The most common reason for traffic passing without inspection in a VDOM is a misconfiguration in the firewall policy's interface matching. Since the traffic is between two VLANs, the policy must explicitly specify the correct source and destination VLAN interfaces. If the policy uses the wrong interfaces (e.g., a physical interface instead of the VLAN subinterface), the traffic will bypass the policy and its associated security profiles entirely.
Exam trap
The trap here is that candidates often jump to troubleshooting the antivirus profile itself (e.g., subscription, inspection mode, or scan settings) instead of verifying the fundamental policy matching, which is the first thing to check in any traffic inspection issue.
How to eliminate wrong answers
Option A is wrong because the FortiGuard subscription status affects signature updates and cloud-based lookups, but it does not prevent an already configured antivirus profile from being applied to traffic that matches a policy. Option B is wrong because flow-based inspection is a valid mode for antivirus, and if the profile is configured correctly, traffic would still be inspected; the issue here is that the policy itself is not matching the traffic. Option C is wrong because the scan mode (e.g., quick, normal, or full) controls the depth of scanning, not whether the profile is applied at all; traffic would still be inspected regardless of the scan mode if the policy matched.
A FortiGate in NAT mode has a VDOM with interface port1 (10.0.1.0/24) and port2 (203.0.113.0/24). A policy allows traffic from port1 to port2 with source NAT using the IP of port2. A user at 10.0.1.10 initiates a connection to a web server at 198.51.100.1. What will be the source IP after NAT?
Why this answer
When source NAT is configured to use the IP address of the egress interface (port2), the FortiGate performs dynamic PAT (Port Address Translation) and translates the source IP of the packet to the primary IP address of port2 (203.0.113.1). This is the default behavior when 'set srcaddr' is set to the interface IP in the firewall policy. The user at 10.0.1.10 will therefore appear to the web server at 198.51.100.1 as coming from 203.0.113.1.
Exam trap
The trap here is that candidates often assume source NAT uses a random IP from the subnet (Option B) or forget that the source IP must be the egress interface IP, leading them to select the original private IP (Option C) or the destination IP (Option D).
How to eliminate wrong answers
Option B is wrong because source NAT with 'IP of port2' does not use a random IP from the subnet; it uses the specific primary IP of the egress interface, not a pool or dynamic assignment. Option C is wrong because 10.0.1.10 is the original private source IP, which is translated by NAT; without NAT, the packet would be dropped or unroutable on the public internet. Option D is wrong because 198.51.100.1 is the destination web server IP, not the source; confusing source and destination addresses is a common error.
An administrator wants to use FortiManager to push a new firewall policy to a managed FortiGate. Before installing, the administrator wants to review what changes will be applied. Which FortiManager feature should be used?
Install Preview displays the CLI commands that will be executed, enabling pre-installation review.
Why this answer
Install Preview (Option A) is the correct feature because it allows the administrator to see a detailed, side-by-side comparison of the current configuration on the managed FortiGate versus the pending changes that FortiManager will push. This preview is generated by FortiManager's policy compilation engine, which calculates the exact CLI commands and object modifications required to synchronize the device database (ADOM) with the managed FortiGate. It provides a safe, non-disruptive way to validate changes before committing them, reducing the risk of misconfiguration.
Exam trap
The trap here is that candidates often confuse the Install Wizard (which guides the installation process) with Install Preview (which shows the actual changes), leading them to select Option B thinking it includes a review step, but the Install Wizard does not generate a detailed diff of pending modifications.
How to eliminate wrong answers
Option B (Policy & Objects - Install Wizard) is wrong because the Install Wizard is used to select the target devices and initiate the actual installation of policies and objects, not to preview the specific changes that will be applied; it does not provide a granular diff view. Option C (Configuration Rollback) is wrong because rollback is a recovery mechanism used to revert a FortiGate to a previous configuration revision after an installation has occurred, not a tool for previewing pending changes. Option D (Revision History) is wrong because Revision History stores past configuration snapshots for audit and rollback purposes, but it does not show the delta between the current device state and the pending changes in FortiManager's database.
An administrator is configuring a FortiGate HA cluster and wants to ensure that the cluster can tolerate a failure of one unit without administrative intervention. The cluster must also support upgrading firmware with minimal downtime. Which HA mode should the administrator select?
Provides automatic failover and supports rolling firmware upgrades.
Why this answer
Active-passive HA (option C) is correct because it provides automatic failover without administrative intervention when a unit fails, and it supports hitless firmware upgrades by upgrading the standby unit first, then performing a failover to make it active, followed by upgrading the original active unit. This mode uses a single management IP and synchronizes configuration and session state between the primary and backup units, ensuring minimal downtime during both failure and upgrade scenarios.
Exam trap
The trap here is that candidates confuse FGCP (the protocol) with an HA mode, leading them to select option D, when FGCP is simply the underlying mechanism used by both active-active and active-passive modes, not a mode itself.
How to eliminate wrong answers
Option A is wrong because standalone mode offers no redundancy or failover capability, so a single unit failure causes complete service loss. Option B is wrong because active-active HA distributes traffic across all units but does not inherently support hitless firmware upgrades without additional complexity and potential session loss; it also requires careful load-balancing configuration and may not meet the 'minimal downtime' upgrade requirement as cleanly as active-passive. Option D is wrong because FGCP (FortiGate Cluster Protocol) is not an HA mode but the underlying protocol that enables both active-active and active-passive HA; selecting FGCP alone does not specify the operational mode needed for automatic failover and minimal-downtime upgrades.
A FortiGate administrator is deploying a multi-VDOM setup for a service provider. The provider wants each customer VDOM to have its own administrative access, yet the overall device management (including firmware upgrades) should be centralized from the management VDOM. Which TWO statements are true regarding administrative VDOMs?
By default, the management VDOM (or any admin with super_admin profile) can access all VDOMs.
Why this answer
Option A is correct because the management VDOM in a multi-VDOM FortiGate setup is specifically designed to provide centralized management. Administrators logged into the management VDOM can use the `execute` commands or the GUI to manage all other VDOMs, including configuration changes and monitoring, without needing to log into each VDOM individually.
Exam trap
The trap here is that candidates often assume traffic VDOMs cannot have any administrative access, but FortiGate allows per-VDOM admin accounts for delegated management, as long as the administrator is assigned to that specific VDOM.
An administrator is configuring a FortiGate HA cluster in active-passive mode. The company has two ISPs, and the primary FortiGate is connected to ISP1 and ISP2. The secondary FortiGate is connected only to ISP2. The administrator wants to ensure that failover occurs only if both ISP1 and ISP2 connections are lost on the primary device. Which configuration approach should be used?
This ensures that the primary's priority drops to 0 only when both ISP links fail, since link-fail-signal reduces priority by 1 for each failed link.
Why this answer
Option D is correct because it uses link-fail-signal on both ISP interfaces of the primary FortiGate to detect physical link loss, and sets HA priorities (primary=1, secondary=0) so that failover occurs only when both ISP links are down. Link-fail-signal triggers an HA failover only when the monitored interface loses carrier, and since both ISP1 and ISP2 interfaces are monitored, the primary will only relinquish control when both links fail, meeting the requirement.
Exam trap
The trap here is that candidates often confuse link-fail-signal with gateway monitoring or assume that setting HA priorities alone is sufficient, overlooking the need to explicitly enable link-fail-signal on the specific interfaces to trigger failover based on link status.
How to eliminate wrong answers
Option A is wrong because gateway monitoring with virtual router failover monitors reachability to a gateway IP, not physical link status, and setting a failure threshold of 2 would require two consecutive failures on a single monitored gateway, not both ISPs. Option B is wrong because configuring gateway monitoring on ISP1 only would cause failover if ISP1 alone fails, even if ISP2 is still up, violating the requirement that both ISPs must be lost. Option C is wrong because it sets HA priority but does not include the 'set ha-priority' commands on the interfaces; the description is incomplete and the syntax is incorrect for the actual configuration needed.
An admin configures a FortiManager ADOM for a customer with multiple FortiGates. The admin wants to use meta fields to group firewalls by location. After defining a meta field 'Location' and assigning values to devices, where can the admin use the meta field for policy targeting?
This allows policy packages to be targeted to specific groups of devices based on meta fields.
Why this answer
Option D is correct because in FortiManager, meta fields are used within ADOM-level policy packages to filter devices during installation targeting. This allows the admin to select only FortiGates with a specific 'Location' meta field value, enabling policy targeting based on location without manual device grouping.
Exam trap
The trap here is that candidates often assume meta fields are automatically propagated to FortiGate devices or used in policy definitions, but FortiManager treats them strictly as administrative metadata for filtering and targeting during installation, not as runtime variables on the FortiGate.
How to eliminate wrong answers
Option A is wrong because meta fields are not automatically synced to FortiGate devices; they remain within FortiManager for administrative grouping and targeting, and are not used directly in FortiGate firewall policies. Option B is wrong because meta fields cannot be used as variables in policy names; they are used for filtering devices in installation targets, not for naming policies. Option C is wrong because meta fields are not limited to FortiAnalyzer reporting; they are primarily used in FortiManager for device grouping and policy targeting.
An administrator wants to create a separate virtual firewall instance on a FortiGate to isolate a DMZ environment. The DMZ must have its own routing table, firewall policies, and administrators. Which FortiGate feature should be used?
VDOMs create separate virtual firewalls with independent configuration.
Why this answer
Virtual Domains (VDOMs) are the FortiGate feature that allows the creation of multiple independent virtual firewalls within a single physical appliance. Each VDOM operates with its own separate routing table, firewall policies, and administrative domains, making it the correct choice for isolating a DMZ environment with dedicated administrators and routing.
Exam trap
The trap here is that candidates often confuse VLANs (Layer 2 segmentation) with VDOMs (full virtual firewall instances), mistakenly thinking VLANs alone can provide independent routing tables and administrative domains, which they cannot.
How to eliminate wrong answers
Option B (VRRP) is wrong because VRRP is a first-hop redundancy protocol (RFC 5798) that provides high availability for default gateways, not a mechanism to create separate virtual firewall instances with independent routing and policies. Option C (VLANs) is wrong because VLANs operate at Layer 2 to segment broadcast domains and do not provide separate routing tables, firewall policies, or administrative domains; they require a VDOM or similar construct to achieve full isolation at Layer 3 and above. Option D (Security Fabric) is wrong because the Security Fabric is a framework for centralized management and threat sharing across multiple FortiGate devices, not a feature that creates isolated virtual firewall instances on a single unit.
An administrator is planning a multi-VDOM deployment with a management VDOM. Which TWO statements about management VDOMs are correct? (Choose two.)
Correct.
Why this answer
Option A is correct because the management VDOM is specifically designed to handle administrative traffic, including FortiGuard updates. By isolating FortiGuard communications to the management VDOM, administrators ensure that security updates and threat intelligence downloads do not interfere with or consume bandwidth from the data VDOMs, and they can be centrally managed from a single VDOM.
Exam trap
The trap here is that candidates often assume a management VDOM cannot have firewall policies or requires a separate license, but in reality, it can have policies for administrative access and does not incur additional licensing costs.
An enterprise FortiGate is configured with multiple VDOMs, including a management VDOM. The admin logs in to the management VDOM and wants to create a new VDOM and assign interfaces. However, the 'config vdom' command requires entering a VDOM name that is not 'root'. What is the correct next step?
The management VDOM can access the global context via 'config global' to create VDOMs and assign interfaces.
Why this answer
The management VDOM operates within the multi-VDOM context, but VDOM creation and interface assignment are global-level operations. The 'config vdom' command to create a new VDOM must be executed from the global configuration context, not from within any VDOM (including the management VDOM). Therefore, the admin must first run 'config global' to exit the management VDOM and enter the global context, where VDOMs can be created and managed.
Exam trap
The trap here is that candidates assume the management VDOM has elevated privileges to create other VDOMs, but in FortiOS, VDOM management is strictly a global-level operation, not a VDOM-level operation.
How to eliminate wrong answers
Option A is wrong because a VDOM link is used to connect two existing VDOMs for traffic forwarding, not to create a new VDOM or assign interfaces. Option B is wrong because 'config vdom' within a VDOM (including the management VDOM) only allows entering an existing VDOM's configuration; it does not permit creating a new VDOM or assigning interfaces, as those operations require global context. Option D is wrong because the FortiGate is already in multi-VDOM mode (as indicated by the presence of multiple VDOMs); rebooting does not change the context needed to create a new VDOM.
An administrator configures a FortiGate in transparent mode for a VDOM. After switching to transparent mode, the administrator notices that the default route disappears and traffic fails. What must be configured to restore routing?
Why this answer
In transparent mode, a FortiGate VDOM acts as a Layer 2 bridge and does not participate in Layer 3 routing. The default route disappears because the VDOM has no Layer 3 interface to host a routing table. To restore management connectivity and allow the FortiGate to reach remote networks (e.g., for firmware updates or logging), you must configure a management IP address and a default gateway for the VDOM.
This management IP is used solely for outbound management traffic and does not affect the bridged data plane.
Exam trap
The trap here is that candidates assume transparent mode still requires per-interface IPs or static routes for the data plane, when in fact only a single management IP and default gateway are needed for the FortiGate's own control-plane traffic.
How to eliminate wrong answers
Option A is wrong because configuring a static route on the upstream router does not provide the FortiGate itself with a default gateway; the FortiGate in transparent mode has no routed interfaces and cannot use an upstream router's route for its own management traffic. Option C is wrong because NAT mode is a separate operational mode (Layer 3) and cannot be enabled within a transparent-mode VDOM; transparent mode inherently disables routing and NAT. Option D is wrong because assigning an IP address to each interface in transparent mode is not supported; only a single management IP is assigned to the VDOM, not per-interface IPs.
An administrator runs the command 'diagnose sys session filter dport 443' on a FortiGate and sees the following output: proto=6 proto_state=01 duration=3600 expire=3599 What does this indicate about the session?
State 01 indicates SYN_SENT; the session has not yet received a SYN-ACK.
Why this answer
The output shows `proto=6` (TCP), `proto_state=01`, `duration=3600`, and `expire=3599`. In FortiGate's session table, `proto_state=01` represents the TCP state `SYN_SENT`, which means the session has sent a SYN but has not yet received a SYN-ACK, so the three-way handshake is incomplete. The `expire=3599` indicates the session will time out in 3599 seconds if the handshake does not complete, but the session is not yet established.
Exam trap
The trap here is that candidates assume `dport 443` and `expire=3599` mean an established HTTPS session, but the `proto_state=01` value explicitly indicates an incomplete handshake, not a fully established connection.
How to eliminate wrong answers
Option B is wrong because `proto_state=01` is not the established state (which would be `08` for ESTABLISHED); a fully established TCP session would show `proto_state=08` and a much shorter expiry (e.g., 3600 seconds for idle timeout). Option C is wrong because the session is present in the session table with a valid state, meaning it is not being blocked by the firewall policy; blocked traffic would not create a session entry at all. Option D is wrong because `dport 443` only indicates the destination port, not that HTTPS inspection has occurred; inspection depends on the firewall policy's SSL inspection profile, not the port number alone.
Refer to the exhibit. An administrator has configured an active-passive HA cluster. After reviewing the configuration and status, the administrator wants to ensure that the management interface (port2) is accessible on both units using the same IP address. What additional configuration is required?
A virtual IP ensures the management interface is reachable via the same IP on both units.
Why this answer
In an active-passive HA cluster, the management interface (port2) must be reachable on both units using the same IP address. This is achieved by configuring a virtual management IP (also known as a management IP address) under the cluster settings. The virtual management IP is assigned to the active unit and, upon failover, is automatically moved to the new active unit, ensuring continuous management access without requiring separate IP addresses per unit.
Exam trap
The trap here is that candidates often confuse enabling ha-mgmt-status (which allows individual unit management) with configuring a virtual management IP (which provides a single shared IP for the cluster), leading them to incorrectly select Option B.
How to eliminate wrong answers
Option A is wrong because setting the gateway to 0.0.0.0 would remove the default route, making the management interface unreachable from remote networks; it does not provide a shared IP address. Option B is wrong because enabling ha-mgmt-status on the secondary unit only allows the secondary unit to be managed via its own dedicated management IP, not a shared IP address; it does not create a virtual management IP that follows the active unit. Option D is wrong because disabling session-pickup would prevent session synchronization between HA units, degrading failover performance and availability, and has no relation to management interface accessibility.
A FortiGate in an HA cluster with VDOMs enabled experiences a failover. After the failover, traffic that was passing before is now being dropped. The configuration is synchronized between the primary and secondary units. What is the most likely reason?
Without session sync, the new primary lacks session information for existing connections, causing drops until clients retransmit.
Why this answer
The most likely reason is that session synchronization is not enabled between HA members. When a failover occurs, the new primary FortiGate does not have the existing session table entries from the original primary, so it treats incoming packets as new connections and may drop them if they do not match a firewall policy's initial handshake state. Even though the configuration is synchronized, session information is not shared unless session synchronization is explicitly configured, causing traffic to be dropped after failover.
Exam trap
The trap here is that candidates assume synchronized configuration includes session state, but FortiGate HA separates configuration sync from session sync, and session synchronization must be enabled as a separate setting under the HA configuration.
How to eliminate wrong answers
Option A is wrong because VDOM configuration is synchronized between HA members, so the new primary has the same VDOM configuration as the old primary. Option B is wrong because the question states that the configuration is synchronized, which includes firewall policies, so they are identical on both units. Option D is wrong because VDOM link interfaces are part of the synchronized configuration and would be in the same state on the new primary; if they were down, the issue would be a configuration or physical problem, not a failover-specific behavior.
A FortiGate is operating in transparent mode for a VDOM. Which statement about transparent mode is TRUE?
Transparent mode bridges traffic at Layer 2, preserving MAC addresses and performing security inspection.
Why this answer
In transparent mode, a FortiGate VDOM acts as a Layer 2 bridge, forwarding Ethernet frames based on MAC addresses without modifying the source or destination MAC addresses. This allows the FortiGate to inspect traffic between hosts on the same subnet without requiring IP address changes or routing, functioning as a security appliance that is transparent to the network.
Exam trap
The trap here is that candidates often confuse transparent mode with NAT or routing capabilities, assuming VIPs or multi-subnet routing are supported, when in fact transparent mode strictly operates at Layer 2 without IP address manipulation.
How to eliminate wrong answers
Option A is wrong because Virtual IP (VIP) objects are not supported in transparent mode; VIPs require NAT and routing, which are Layer 3 functions, and transparent mode operates strictly at Layer 2. Option C is wrong because interfaces in a transparent mode VDOM do not need IP addresses in the same subnet; they typically have no IP addresses or are assigned management IPs that can be in different subnets, as the FortiGate bridges frames without IP configuration. Option D is wrong because a transparent mode VDOM cannot have multiple IP subnets on the same broadcast domain for inspection; it bridges all traffic within the same broadcast domain and does not perform routing between subnets, which would require Layer 3 forwarding.
An administrator configures a VDOM link between VDOMs A and B. In VDOM A, the VDOM link interface is assigned IP 10.10.10.1/24, and in VDOM B, it is assigned 10.10.10.2/24. A firewall policy on VDOM A allows traffic from a subnet in VDOM A to a subnet in VDOM B. However, traffic fails. The admin checks the routing table in VDOM A and sees a route to the destination subnet via 10.10.10.2. What is the most likely cause?
Traffic entering VDOM B must be permitted by a policy. If missing, packets are dropped.
Why this answer
Option A is correct. In VDOM B, there must be a firewall policy allowing inbound traffic from the VDOM link. Without it, the traffic will be dropped upon entering VDOM B.
An administrator configures a VDOM on a FortiGate and assigns two interfaces (port1, port2) to it. The administrator wants to route traffic between two different subnets within the same VDOM. Which configuration is required?
Standard routing within the VDOM is sufficient to route between subnets on different interfaces.
Why this answer
Option D is correct because routing between two subnets within the same VDOM is standard intra-VDOM routing. Since both interfaces (port1, port2) belong to the same VDOM, no inter-VDOM constructs are needed; the FortiGate simply requires a route (static or dynamic) to forward packets between the subnets. A firewall policy allowing the traffic is also necessary, but the question specifically asks for the routing configuration.
Exam trap
The trap here is that candidates confuse intra-VDOM routing (within the same VDOM) with inter-VDOM routing (between VDOMs) and incorrectly assume that a VDOM link or inter-VDOM routing must be enabled, when in fact standard routing is sufficient.
How to eliminate wrong answers
Option A is wrong because a VDOM link is used to connect two different VDOMs, not to route between subnets within the same VDOM. Option B is wrong because a policy with inter-VDOM link is a firewall rule that references a VDOM link, again for inter-VDOM traffic, not intra-VDOM routing. Option C is wrong because inter-VDOM routing is a global setting that enables routing between VDOMs; it is irrelevant when both interfaces reside in the same VDOM.
A network engineer wants to deploy a FortiGate in transparent mode and have it managed by FortiManager. The FortiGate should not participate in routing, but must be able to send logs to FortiAnalyzer. Which two settings must be configured on the FortiGate to achieve this?
In transparent mode, the management IP is used for management and logging.
Why this answer
In transparent mode, the FortiGate operates as a Layer 2 bridge and does not participate in routing. However, to be managed by FortiManager and send logs to FortiAnalyzer, the FortiGate must have a management IP address (option B) so that it can be reached as a management endpoint. Additionally, a static route (option D) is required to direct traffic to the management and logging servers, since the FortiGate cannot rely on dynamic routing protocols in transparent mode.
Exam trap
The trap here is that candidates assume transparent mode requires no IP configuration at all, but FortiManager and FortiAnalyzer communication still needs a management IP and a static route to function correctly.
A large enterprise operates two FortiGate 600E firewalls in an HA active-passive cluster. They have enabled VDOMs to isolate traffic for different business units: Finance, HR, and Engineering. Each VDOM has its own internet connection through separate ISPs. The cluster has been running smoothly for months. Recently, the IT team noticed that users in the Finance VDOM experience intermittent connectivity drops to their cloud-based ERP system. The drops last 30-60 seconds and occur several times a day. During these drops, ping to the ERP IP address fails. The HA cluster status shows 'synchronized' and no failover events are logged. The Finance VDOM uses a static default route pointing to the primary ISP gateway. The other VDOMs are unaffected. What is the most likely cause of the issue?
VDOM links must be identical on both HA units; a mismatch can cause intermittent traffic drops.
Why this answer
Option D is correct because VDOM link configurations are stored per-VDOM and must be synchronized independently. If the VDOM link configuration is not synchronized between the HA units, the passive unit may have a different or missing VDOM link, causing asymmetric routing when traffic is processed by the passive unit during a transient state (e.g., session ownership change or link flap). This leads to intermittent connectivity drops for the Finance VDOM only, as its traffic is isolated and uses a static default route.
Exam trap
The trap here is that candidates often assume HA synchronization covers all configurations uniformly, but VDOM-specific objects like VDOM links require explicit synchronization and can cause asymmetric routing issues when mismatched between HA peers.
How to eliminate wrong answers
Option A is wrong because the cluster is explicitly described as active-passive, not active-active, so routing loops due to active-active mode are impossible. Option B is wrong because heartbeat interface oversubscription would cause HA synchronization failures or split-brain scenarios, but the cluster status shows 'synchronized' and no failover events are logged, ruling out heartbeat issues. Option C is wrong because 'set ha-mgmt-status enable' only allows management access to the passive unit via dedicated management interfaces; it does not affect route synchronization or cause connectivity drops for a specific VDOM.
A network administrator is configuring inter-VDOM routing between two VDOMs: VDOM-A and VDOM-B. The administrator creates a inter-VDOM link and adds routes pointing to the link. However, traffic from VDOM-A to VDOM-B fails. What is the most likely missing configuration?
Why this answer
In FortiGate, inter-VDOM routing requires firewall policies in each VDOM to explicitly permit traffic across the inter-VDOM link. Without these policies, the FortiGate drops the traffic even if routes are correctly configured, because the inter-VDOM link behaves like a virtual interface that requires policy-based access control.
Exam trap
The trap here is that candidates assume routing alone is sufficient for inter-VDOM communication, overlooking FortiGate's requirement for explicit firewall policies to permit traffic across VDOM boundaries, similar to how policies are needed between physical interfaces.
How to eliminate wrong answers
Option A is wrong because inter-VDOM routing works in both transparent and NAT/route modes; both VDOMs do not need to be in transparent mode. Option C is wrong because the inter-VDOM link is a cross-VDOM connection, not a single-VDOM interface; placing it in the same VDOM would defeat the purpose of inter-VDOM routing. Option D is wrong because the management VDOM is only required for administrative access and has no bearing on inter-VDOM traffic forwarding.
A FortiGate administrator is troubleshooting why a new firewall policy is not being applied to traffic. The policy has been created and installed via FortiManager. What is the quickest way to verify the current state of the policy on the FortiGate?
This shows the current policy configuration on the FortiGate.
Why this answer
Option D is correct because running 'show firewall policy' on the FortiGate CLI displays the currently active policy set in the kernel, including the policy ID and its enabled/disabled status. This is the quickest way to confirm whether the policy installed via FortiManager is actually present and active on the FortiGate, without generating debug logs or querying the management plane.
Exam trap
The trap here is that candidates confuse the management plane (FortiManager revision history) with the data plane (FortiGate kernel policy table), leading them to choose an option that checks the manager instead of the actual device state.
How to eliminate wrong answers
Option A is wrong because 'diagnose debug flow' is a packet-level debugging tool used to trace traffic matching and policy decisions in real time, not a method to verify the static state of a policy. Option B is wrong because 'execute fortimanager reindex' forces FortiManager to rebuild its database indexes, which does not affect or verify the policy state on the FortiGate. Option C is wrong because checking FortiManager revision history shows past configuration changes stored on the manager, not the current runtime state of the policy on the managed FortiGate.
A network administrator is configuring FortiManager to manage multiple FortiGates with different VDOMs. The admin needs to ensure that each FortiGate's VDOMs can be independently managed. What is the correct configuration step?
Per-VDOM ADOM mode allows each VDOM on a FortiGate to be managed as an independent ADOM, enabling granular control.
Why this answer
Option A is correct because FortiManager's per-VDOM ADOM mode allows each VDOM on a FortiGate to be treated as an independent ADOM, enabling separate management of policies, objects, and settings per VDOM. This is essential when different VDOMs serve distinct tenants or departments and must not share configuration contexts.
Exam trap
The trap here is that candidates often confuse per-VDOM ADOM mode with simply adding multiple FortiGates to a single ADOM, failing to realize that independent VDOM management requires a separate ADOM per VDOM, not just per device.
How to eliminate wrong answers
Option B is wrong because using a single ADOM for all FortiGates would merge all VDOMs into one management domain, preventing independent per-VDOM control and violating the requirement. Option C is wrong because configuring each FortiGate as a separate device in the Global ADOM still treats the entire FortiGate as one unit, not allowing per-VDOM separation; the Global ADOM is intended for system-level settings, not VDOM-level management. Option D is wrong because using the same policy package for all VDOMs would force identical firewall policies across VDOMs, contradicting the need for independent management.
In FortiManager, what is the purpose of header and footer policies in a policy package?
Header/footer policies provide a way to enforce mandatory policies.
Why this answer
Header and footer policies in FortiManager are special policy types that enforce a fixed position within the policy list. Header policies are always placed at the top (before all other policies), and footer policies are always placed at the bottom (after all other policies). This ensures that critical security rules, such as default-deny or global allow rules, remain in their intended position regardless of policy package changes or reordering operations.
Exam trap
The trap here is that candidates confuse header/footer policies with policy ordering or scheduling, assuming they are just a way to organize or time-limit policies, rather than understanding they enforce a fixed position in the policy list.
How to eliminate wrong answers
Option A is wrong because header and footer policies are not used for organizational grouping; policy groups (or policy sections) are created using policy packages or policy folders, not header/footer policies. Option B is wrong because time-based policy enforcement is handled by schedule objects within individual policy rules, not by the header/footer policy mechanism. Option D is wrong because IPv4 and IPv6 policies are separated by policy type (IPv4 vs IPv6) within the policy package, not by header/footer policies.
An organization has two FortiGate firewalls in an HA active-passive cluster. They notice that after a failover event, some users cannot access external resources. The administrator checks the HA configuration and finds that failover occurred correctly. What is the most likely cause of the connectivity issue?
If VDOM links are not synchronized, the backup unit may have incorrect link status, causing routing issues.
Why this answer
In an HA active-passive cluster, VDOM links are not automatically synchronized between peers. After a failover, the new primary FortiGate may lack the VDOM link configurations required to route traffic between VDOMs, causing connectivity loss for users relying on inter-VDOM routing. This is a common misconfiguration because VDOM links are treated as local objects and must be explicitly replicated or re-created on the peer.
Exam trap
The trap here is that candidates assume all HA configurations are fully synchronized, but FortiGate explicitly excludes VDOM links from HA sync, requiring manual replication or use of a configuration-only sync method.
How to eliminate wrong answers
Option B is wrong because session-pickup, when enabled, synchronizes existing sessions to the standby unit, but it does not affect the ability to establish new sessions after failover; the issue described is about persistent connectivity, not session state loss. Option C is wrong because HA override controls which unit becomes primary after a failure (e.g., preempting based on priority), but it does not impact connectivity after failover; the administrator confirmed failover occurred correctly. Option D is wrong because gratuitous ARP (GARP) is sent by the new primary to update switch MAC tables; disabling it would cause temporary traffic blackholing until ARP caches time out, but the question states users cannot access external resources persistently, not just transiently.
An administrator needs to ensure that traffic between two VDOMs (VDOM_A and VDOM_B) is inspected by an IPS profile. Which TWO configuration elements are required? (Choose TWO.)
Inter-VDOM links are necessary to route traffic between VDOMs.
Why this answer
An inter-VDOM link is required to route traffic between VDOMs, and placing IP addresses in the same subnet on both ends ensures direct Layer 2 connectivity without routing overhead. This allows the firewall policies in each VDOM to control traffic flow, and applying an IPS profile on the policy in VDOM_A (with the inter-VDOM link as the destination interface) ensures that all traffic leaving VDOM_A toward VDOM_B is inspected by IPS.
Exam trap
The trap here is that candidates often assume an IPsec VPN or NAT is needed for inter-VDOM communication, but FortiGate uses inter-VDOM links with same-subnet IPs and firewall policies to enable direct, inspectable traffic flow.
A network administrator is deploying a FortiGate in transparent mode to replace an existing layer 2 switch. Which statement about transparent mode is true?
Correct. The device behaves like a firewall bridge.
Why this answer
In transparent mode, the FortiGate operates as a layer 2 bridge, forwarding traffic based on MAC addresses without performing routing. All interfaces are in the same broadcast domain, and the FortiGate inspects traffic at layers 3–7 while remaining transparent to the network. This allows it to replace a layer 2 switch while adding firewall functionality.
Exam trap
The trap here is that candidates assume transparent mode disables all routing capabilities, but it actually supports routing when VDOMs are enabled, and the key distinction is that traffic forwarding is MAC-based, not IP-based.
How to eliminate wrong answers
Option B is wrong because transparent mode supports both static and dynamic routing (e.g., OSPF, BGP) when VDOMs are enabled, though it is often used without routing. Option C is wrong because VDOMs are not required for transparent mode; they are an optional feature for multi-tenancy or administrative separation. Option D is wrong because the FortiGate in transparent mode does not act as a router; its management IP is used for administrative access only, and traffic forwarding is based on MAC addresses, not IP addresses.
A FortiManager administrator wants to push a policy package that includes both global header/footer policies and VDOM-specific policies. Which statement about header/footer policies is correct?
Correct. This ensures consistent enforcement.
Why this answer
Option D is correct because in FortiManager, when a policy package includes both global header/footer policies and VDOM-specific policies, the header policies are inserted before the VDOM's own policies in the policy table, while footer policies are appended after them. This ensures that header policies are evaluated first for traffic matching, and footer policies serve as a catch-all or default set of rules at the end of the VDOM policy list.
Exam trap
The trap here is that candidates often assume header/footer policies are only for per-device mapping or must be configured locally on the FortiGate, but FortiManager fully supports creating and managing them centrally for consistent policy enforcement across VDOMs.
How to eliminate wrong answers
Option A is wrong because header/footer policies are available with both per-device mapping and policy package installation, not exclusively with per-device mapping. Option B is wrong because header/footer policies can be configured directly on FortiManager under the global policy package and then pushed to managed FortiGates, not only on the FortiGate itself. Option C is wrong because header/footer policies are manually created and edited by the administrator in FortiManager, not automatically generated; they are user-defined policies that provide a consistent set of rules across multiple VDOMs.
An administrator wants to add custom fields to device objects in FortiManager to track location and contact info. Which feature should be used?
Correct.
Why this answer
Meta fields in FortiManager allow administrators to define custom attributes (e.g., location, contact info) that can be attached to device objects. These fields are stored in the FortiManager database and can be used for filtering, reporting, and policy mapping, providing a flexible way to enrich device metadata without modifying the device configuration itself.
Exam trap
The trap here is that candidates confuse 'meta fields' with 'system templates' because both involve customization, but system templates apply configuration settings to devices, whereas meta fields add descriptive metadata without altering device configurations.
How to eliminate wrong answers
Option B is wrong because system templates are used to standardize configuration settings (e.g., SNMP, admin profiles) across devices, not to add custom fields to device objects. Option C is wrong because custom reports are used to generate tailored views of log and event data, not to define metadata fields on device objects. Option D is wrong because dynamic mapping is a feature for automatically assigning devices to ADOMs or groups based on criteria like IP address or hostname, not for adding custom fields.
A FortiGate administrator notices that traffic from a specific subnet is not being inspected by the Intrusion Prevention System (IPS) profile applied to the firewall policy. The policy is configured with the correct profile, and the IPS engine is enabled. What is the most likely cause?
IPS profiles have protocol-specific settings; if the protocol is disabled, traffic is not inspected.
Why this answer
The most likely cause is that the protocol in the IPS profile is not enabled for the application being used. Even when an IPS profile is applied to a firewall policy and the IPS engine is running, the profile must have the specific protocol (e.g., HTTP, SMTP, FTP) enabled for inspection. If the protocol is disabled or not selected, the IPS engine will bypass traffic of that type, resulting in no intrusion detection or prevention for that traffic.
Exam trap
The trap here is that candidates often assume an IPS profile will inspect all traffic by default once applied, overlooking the need to enable specific protocol sensors within the profile for the traffic to be inspected.
How to eliminate wrong answers
Option A is wrong because encrypted traffic that is not decrypted by SSL inspection would simply be passed without deep inspection, but the question states traffic from a specific subnet is not inspected at all, which points to a protocol-level filtering issue rather than encryption. Option C is wrong because signature-based detection is the standard mode for IPS; if the profile were configured for signature-based detection only, it would still inspect traffic as long as the protocol is enabled. Option D is wrong because the firewall policy mode (accept vs. explicit proxy) affects how traffic is directed to the FortiGate, not whether IPS inspection is applied; IPS inspection is independent of the policy mode.
Ready to test yourself?
Try a timed practice session using only Enterprise Firewall and VDOMs questions.