Free FCP-FGT-AD practice questions

An administrator manages several FortiGate units that all ship with the same default hostname, making it hard to tell devices apart in monitoring tools and on the CLI prompt. During initial configuration, which change gives each device a distinct identifier shown at the CLI prompt and in the GUI dashboard?

• ASet a unique system hostname on each FortiGate under the global system settings.check_circle Correct
• BSet a unique local-in alias on the management interface of each FortiGate.
• CSet a unique administrator profile name on each FortiGate so logins identify the device.
• DSet a unique SSL certificate common name on each FortiGate to label the device.

Why A is correct: The system hostname is the device name displayed in the CLI prompt and the GUI dashboard, so assigning a unique hostname to each unit directly distinguishes them as the scenario requires.

Why B is wrong: Interface aliases are descriptive labels for individual ports and appear beside those interfaces, but they do not change the device-wide name shown at the prompt or dashboard, so they do not solve the identification problem.

Why C is wrong: Profile names organise access permissions and are easy to confuse with device naming, but they describe privilege sets rather than the unit itself, so renaming a profile does not alter how the device identifies itself.

Why D is wrong: A certificate common name appears during secure session negotiation and can carry a device name, but it is not what the CLI prompt or dashboard displays, so changing it does not meet the stated need.

An administrator wants the FGCP cluster to fail over automatically if the WAN-facing interface on the primary unit loses its link, but is unsure how to make the cluster react to that specific port. Which configuration achieves this?

• AEnable session pickup so the cluster tracks the WAN interface state and migrates sessions when the link drops.
• BRaise the device priority on the WAN interface so the cluster favours whichever unit has that link up.
• CConfigure a second heartbeat interface on the WAN port so heartbeat loss there forces the cluster to switch units.
• DAdd the WAN interface to the HA monitored interfaces list so a link failure on it lowers the unit's score and triggers failover.check_circle Correct

Why A is wrong: Tempting because session pickup is an HA feature, but it only synchronises session tables for smoother failover; it does not monitor interface link state or trigger a failover when a port goes down.

Why B is wrong: Plausible because priority influences primary selection, but device priority is a static administrative preference and is not evaluated per interface link state, so it does not cause an automatic failover on link loss.

Why C is wrong: This confuses heartbeat with port monitoring; heartbeat interfaces detect peer reachability between cluster members, not the up or down state of a data interface like the WAN port.

Why D is correct: Interface monitoring (port monitoring) adds the chosen interface to the HA health calculation, so a link-down event on the monitored WAN port reduces that unit's cluster score and causes the cluster to fail over to the healthy unit.

During initial setup an administrator wants the FortiGate WAN interface to obtain its IP address, subnet mask, and default gateway automatically from the upstream ISP router. Which addressing mode should be configured on that interface?

• AManual, entering the address the ISP provides so the interface uses a fixed configuration.
• BDHCP, so the interface requests its address and gateway from the upstream DHCP server.check_circle Correct
• CPPPoE, so the interface negotiates an address through a dial-up session with the provider.
• DOne-arm sniffer, so the interface receives the address that mirrored traffic carries.

Why A is wrong: Manual mode is the right choice when the ISP issues a static address, but it requires the administrator to type the address and gateway rather than learning them automatically, so it does not match the requirement.

Why B is correct: DHCP mode makes the interface act as a DHCP client, leasing its IP, mask, default gateway, and optionally DNS from the upstream server, which is precisely what the scenario asks for.

Why C is wrong: PPPoE also obtains an address dynamically, but it is used over provider links that require PPP session authentication rather than a plain DHCP server, so it is the wrong fit for an upstream router handing out leases.

Why D is wrong: One-arm sniffer mode places the interface in a passive monitoring role with no IP addressing at all, so it cannot obtain a WAN address and is unrelated to the requirement.

A network administrator is deploying FSSO in DC agent mode for a Windows Active Directory domain with three domain controllers. Each user logon must be captured and forwarded to the collector agent so that the FortiGate can apply identity-based policies. Which component must be installed on each monitored domain controller for this mode to function?

• AA DC agent (dcagent.dll) registered on every monitored domain controller, which intercepts logon events and forwards them to the collector agent.check_circle Correct
• BA collector agent installed directly on every domain controller, so each controller independently sends user-to-IP mappings to the FortiGate.
• CA TS agent on each domain controller to track per-session source ports for users sharing one host.
• DThe FortiGate polling service enabled against each controller, removing the need for any agent on the controllers.

Why A is correct: DC agent mode requires the FSSO DC agent to be installed on each domain controller; it hooks logon events at the source and pushes them to the collector agent, which is the defining characteristic of this mode.

Why B is wrong: It is tempting because the collector agent is central to FSSO, but in DC agent mode the collector is a single (or redundant) service that aggregates events from DC agents, not a per-controller component that talks to the FortiGate alone.

Why C is wrong: The TS agent is used for Citrix or Terminal Server environments to distinguish users on a shared host by port range, not for capturing standard domain controller logon events.

Why D is wrong: This describes agentless polling mode rather than DC agent mode; the question explicitly specifies DC agent mode, which depends on an installed DC agent rather than FortiGate-initiated polling.

An administrator configures a firewall policy with active authentication. After users successfully authenticate, they complain that they are forced to log in again far too frequently during a normal working day. The administrator wants authenticated sessions to persist longer before the FortiGate requires re-authentication. Which setting should the administrator adjust?

• AIncrease the captive portal session TTL on the ingress interface so the portal cookie is retained by the browser for a longer period.
• BIncrease the firewall policy session-ttl so each accepted session stays in the session table longer and avoids triggering a fresh login.
• CIncrease the authentication timeout value under the user settings so the idle period before the FortiGate expires the authenticated session is longer.check_circle Correct
• DIncrease the RADIUS server's accounting interim update interval so the FortiGate refreshes the user's authenticated state on each update.

Why A is wrong: Tempting because the captive portal is involved in login, but there is no separate portal session TTL on the interface that controls firewall authentication lifetime; the authentication timeout governs this.

Why B is wrong: Tempting because session-ttl is a real policy setting, but it controls how long idle traffic sessions persist in the session table, not how long an authenticated user identity remains valid.

Why C is correct: Correct. The authentication timeout under user settings governs how long an authenticated session remains valid while idle, so raising it reduces how often users are prompted to log in again.

Why D is wrong: Tempting because RADIUS accounting can keep sessions alive in some designs, but the interim interval controls usage reporting frequency and does not extend the FortiGate authentication timeout.

An administrator builds a firewall policy that requires users to authenticate before their HTTP traffic is allowed out to the internet. Users report that they are never prompted for credentials and the traffic is simply blocked. The policy has a user group assigned and the action is set to accept. Which configuration detail is required so that unauthenticated HTTP sessions trigger an active authentication prompt?

• AEnable a captive portal on the ingress interface or enable disclaimer-and-portal so the FortiGate can intercept the HTTP session and present a login page.check_circle Correct
• BDisable the explicit web proxy on the ingress interface so that the FortiGate falls back to transparent captive portal prompting for the policy.
• CChange the policy action to deny and add an authentication exemption so the FortiGate prompts before applying the deny verdict to each new flow.
• DAdd an FSSO collector agent connector to the policy so that the agent injects the credentials and removes the need for any interactive prompt.

Why A is correct: Correct. Active authentication on a policy needs a captive portal mechanism, typically enabled on the ingress interface or via the policy, so the FortiGate can intercept the supported HTTP session and serve the login page.

Why B is wrong: Tempting because proxy modes affect prompting, but disabling a proxy that may not even be configured does not enable the policy-driven captive portal and does not address why no prompt appears.

Why C is wrong: Tempting because action and authentication feel linked, but a deny policy drops traffic and never authenticates, and an exemption removes authentication rather than enabling a prompt.

Why D is wrong: Tempting because FSSO authenticates users, but FSSO is passive single sign-on that maps existing logins and never displays a prompt, so it does not produce the requested active login page.

An administrator switches a firewall policy from certificate inspection to full SSL deep inspection so antivirus can scan HTTPS downloads. Immediately afterwards, internal users on managed laptops report browser certificate warnings on most HTTPS sites, while one application that uses certificate pinning fails to connect entirely. The administrator wants deep inspection to function cleanly without weakening it for everyone. Which TWO statements correctly describe the trust requirements that full deep inspection introduces? Select TWO.

• AThe CA certificate that the FortiGate uses to re-sign server certificates must be present in each client's trusted root store, otherwise browsers warn that the substitute certificate is untrusted.check_circle Correct
• BA pinned application still breaks because the FortiGate substitute certificate differs from the one it pins, so that host must be exempted from deep inspection rather than trusting the CA.check_circle Correct
• CThe FortiGate must first obtain and import the private key of every external HTTPS server it inspects before it is able to re-sign that server's certificate for the client.
• DEach client must individually import the original public certificate of every website it visits so the browser can match it against the FortiGate re-signed copy.
• ECertificate validation must be turned off in every browser so each client blindly accepts the FortiGate-generated certificate regardless of which CA actually issued the substitute.

Why A is correct: Correct: deep inspection presents each client a server certificate re-signed by the FortiGate CA, and browsers only trust that chain when the FortiGate re-signing CA is installed as a trusted root on the client.

Why B is correct: Correct: certificate pinning compares the presented certificate against a pinned value, and the re-signed certificate never matches it, so the only clean fix is to exempt the pinned host from decryption.

Why C is wrong: This is tempting because deep inspection does involve certificates, but the FortiGate generates a fresh substitute signed by its own CA and never needs the remote server's private key, which it could not obtain for outbound inspection.

Why D is wrong: This is wrong because clients never pre-import remote site certificates; the single trust dependency that removes warnings is the FortiGate re-signing CA in the client root store, not per-site certificates.

Why E is wrong: This is wrong and insecure, because the supported approach keeps normal validation intact and simply trusts the FortiGate CA, whereas disabling validation would accept any forged certificate from any source.

An administrator builds a firewall policy that references a web filter profile set to proxy-based inspection, while the policy itself has its inspection mode left at flow-based. When traffic matches the policy, how does FortiGate handle the web filter profile's proxy-based inspection?

• AFortiGate applies the web filter profile using proxy-based inspection regardless of the policy inspection mode, because the profile setting takes precedence.
• BFortiGate blocks all traffic on the policy until the inspection modes of the policy and the profile are made to match.
• CFortiGate raises a configuration error and refuses to save the policy until the profile is changed to flow-based.
• DFortiGate silently converts the profile to flow-based inspection and applies the web filter using flow-based logic for that policy.check_circle Correct

Why A is wrong: This is tempting because it assumes the profile's own inspection mode wins, but the policy inspection mode governs how security profiles run, so a flow-based policy cannot execute a proxy-based profile as proxy.

Why B is wrong: This sounds cautious and secure, but FortiGate does not fail closed on a mode mismatch; it reconciles the profile to the policy mode rather than dropping traffic.

Why C is wrong: This is plausible because some mismatches are blocked at save time, but a web filter profile can be referenced by either policy mode, so the configuration commits without error.

Why D is correct: Correct: when the policy is in flow mode, FortiGate runs the web filter profile in flow-based mode, so any proxy-only behaviour in the profile is applied using the flow-based equivalent.

A firewall policy has an application control profile applied but no SSL inspection profile beyond the certificate-inspection default, and users report that an HTTPS-only application is still being detected and blocked correctly. Which capability lets application control identify many encrypted applications without full deep SSL inspection?

• AFortiGate decrypts the TLS payload using certificate inspection and reads the HTTP host header to match the application signature.
• BThe application signatures inspect unencrypted handshake fields such as the TLS SNI and certificate metadata to identify the application.check_circle Correct
• CApplication control falls back to matching the destination IP address against the FortiGuard application IP reputation list.
• DFortiGate replays the session through a sandbox that fingerprints the application before allowing the original flow to continue.

Why A is wrong: Certificate inspection does not decrypt the payload, so it cannot read an HTTP host header inside the encrypted stream; this confuses certificate inspection with full deep inspection.

Why B is correct: Many signatures match cleartext fields in the TLS handshake, notably the Server Name Indication and certificate details, allowing identification without decrypting the session.

Why C is wrong: There is no per-application IP reputation list driving signature matches, so this sounds plausible but misattributes how encrypted applications are recognised.

Why D is wrong: Sandboxing analyses files, not live session identification, and would add latency that does not occur, so this misdescribes the inline matching mechanism.

A FortiGate has two static default routes out of two different ISP links. Both routes have the same administrative distance and the same priority. What is the effect on traffic that uses the default route?

• ABoth routes are installed in the forwarding table and traffic is load balanced across both links using equal-cost multi-path routingcheck_circle Correct
• BOnly the route whose gateway has the lower IP address is installed, and all default traffic uses that single link
• CNeither route is installed because FortiGate rejects duplicate default routes and logs a configuration conflict
• DBoth routes are installed but only the most recently configured one forwards traffic until it fails over to the other

Why A is correct: When two routes share the same distance and priority, FortiGate treats them as equal-cost and installs both, performing ECMP load balancing across the two links according to the configured load-balancing method.

Why B is wrong: FortiGate does not select between equal routes by comparing gateway IP addresses. This sounds like a deterministic tie-breaker but no such rule exists, so it is incorrect.

Why C is wrong: FortiGate accepts multiple default routes; it does not reject them as duplicates. The idea of a conflict rejection is plausible to a newcomer but does not reflect FortiOS behaviour.

Why D is wrong: Equal routes do not behave as an active and passive pair when distance and priority match. This describes failover, which requires differing priority or distance, so it is a tempting but wrong assumption.

An administrator configures a performance SLA that probes a public server through port1 and port2. The probe uses the HTTP protocol against a server reachable only via a static route bound to port1. The SLA shows port1 as alive but port2 is permanently dead, even though port2 has a working default route and can browse the internet normally. What is the most likely cause of the false dead status on port2?

• AHTTP probes are unsupported on secondary SD-WAN members, so only the first member in the zone can use the HTTP protocol and all others must use Ping.
• BThe HTTP probe server is reachable only through the port1 static route, so probes sourced on port2 cannot reach it, making the health check fail for port2 regardless of that link's real internet connectivity.check_circle Correct
• CThe detection interval on port2 is shorter than its configured timeout, which FortiOS treats as an invalid timer set and forces the member into a dead state.
• DPort2 needs the probe server added to its interface allowlist before the SLA can mark it alive, and an empty allowlist defaults every member to dead.

Why A is wrong: Tempting as a plausible feature limit, but wrong: the HTTP probe protocol is available to every member, so member ordering does not restrict the protocol.

Why B is correct: Correct: a health-check server reachable by only one path means probes egressing the other member fail, producing a false dead status that reflects probe routing rather than true link health.

Why C is wrong: Tempting by invoking timer relationships, but wrong: a short interval does not force a dead state; the member fails because its probes cannot reach the server.

Why D is wrong: Tempting because allowlists exist elsewhere, but wrong: performance SLA has no per-interface probe-server allowlist that defaults members to dead.

Two static routes to the same destination subnet exist on a FortiGate. Route 1 uses gateway A with administrative distance 10, and Route 2 uses gateway B with administrative distance 20. Both gateways are reachable. Which route is installed in the FortiGate routing table?

• ARoute 2, because a higher administrative distance reserves more bandwidth and is preferred for primary forwarding
• BBoth routes, because routes to the same destination with different distances are installed and load balanced together
• CNeither route, because conflicting administrative distances to one destination cause FortiGate to discard both entries
• DRoute 1, because the route with the lower administrative distance is considered more trustworthy and is preferredcheck_circle Correct

Why A is wrong: Administrative distance has nothing to do with bandwidth, and higher is not better. This reverses the rule, which is a common mistake, so it is wrong.

Why B is wrong: Routes with different administrative distances are not equal-cost, so only the lower-distance route enters the table. Installing both would require equal distances, so this is incorrect.

Why C is wrong: FortiGate resolves the conflict by selecting the better route rather than discarding both. The idea that a conflict drops all routes is plausible but does not match how distance selection works.

Why D is correct: Administrative distance ranks the believability of routes, and a lower value is preferred. Route 1 at distance 10 is chosen over Route 2 at distance 20, so it is installed in the routing table.

Two FortiGates negotiate IKEv2 phase 1, but the tunnel never establishes. Diagnostics show phase 1 proposals do not match: one peer offers AES256-SHA256 with DH group 14, the other offers AES256-SHA256 with DH group 20. Both peers share the same pre-shared key and the same phase 2 selectors. What is the correct conclusion about why phase 1 fails?

• AThe pre-shared key mismatch is the real cause, because a differing DH group always indicates the authentication payload was computed with different secrets.
• BThe phase 2 selectors are too broad, so the kernel rejects the phase 1 SA before the Diffie-Hellman exchange can complete.
• CThe Diffie-Hellman group must match in at least one common phase 1 proposal, so groups 14 and 20 with no overlap cause the IKE SA negotiation to fail.check_circle Correct
• DIKEv2 ignores the Diffie-Hellman group during the initial exchange, so the failure must come from a mismatched encryption algorithm instead.

Why A is wrong: It is tempting to blame authentication when phase 1 fails, but the scenario states the keys are identical and a DH group is an independent negotiated parameter, so the key is not the fault here.

Why B is wrong: Phase 2 selectors are negotiated only after phase 1 succeeds and cannot block the phase 1 SA, so selector breadth cannot explain a failure that occurs during the phase 1 key exchange.

Why C is correct: Phase 1 builds the IKE SA using a mutually agreed Diffie-Hellman group; if neither peer offers a group the other accepts, the key exchange cannot complete and phase 1 fails even when encryption, hash, and the pre-shared key all match.

Why D is wrong: IKEv2 absolutely requires an agreed Diffie-Hellman group in the initial exchange, and the scenario shows encryption and hash already match, so blaming the cipher is both factually wrong and inconsistent with the diagnostics.

A route-based IPsec tunnel between two sites comes up cleanly and phase 2 shows installed selectors, but no user traffic crosses it. The administrator confirms phase 1 and phase 2 are established and the static route over the tunnel interface is present. Which configuration gap most likely explains why traffic is not passing?

• AThe phase 2 quick mode selectors are set to 0.0.0.0/0, which silently blocks specific subnet traffic until they are narrowed.
• BNo firewall policies permit traffic between the IPsec tunnel interface and the internal interface in the required directions.check_circle Correct
• CDead peer detection is disabled, so the FortiGate refuses to forward data until the first keepalive completes.
• DAuto-negotiate is disabled on phase 2, so the security association stays idle and drops all transit packets despite showing installed.

Why A is wrong: Wide 0.0.0.0/0 selectors are permissive rather than blocking and would carry the specific subnets fine, so broad selectors do not explain a complete absence of traffic on an established tunnel.

Why B is correct: A route-based tunnel presents a virtual interface, and FortiGate still requires firewall policies to allow traffic between that tunnel interface and the LAN; without them the route exists but every packet is denied, which matches an up tunnel with no traffic.

Why C is wrong: Dead peer detection only monitors peer liveness and does not gate data forwarding, so its state has no bearing on whether an already established tunnel passes user traffic.

Why D is wrong: Auto-negotiate only controls whether phase 2 establishes without traffic to trigger it; once selectors show installed the SA is active, so this cannot be the reason an established tunnel passes nothing.

Across a meshed IPsec deployment, two peers establish phase 1 but phase 2 fails to install. The administrator notes that one peer defines its phase 2 quick mode selector as the LAN subnet 10.10.0.0/24 while the other defines the matching selector as the single host 10.10.0.5/32. Why does phase 2 fail in this case?

• APhase 2 fails because the two peers chose different Diffie-Hellman groups for perfect forward secrecy during the quick mode exchange.
• BPhase 2 fails because the phase 1 SA lifetime is shorter than the phase 2 SA lifetime, forcing the child SA to expire immediately.
• CPhase 2 fails because route-based tunnels ignore quick mode selectors entirely, so any configured selector causes the SA to be discarded.
• DThe quick mode selectors must be reciprocal between peers, so a subnet on one side and a single host on the other do not match and phase 2 cannot install.check_circle Correct

Why A is wrong: A PFS group mismatch can break phase 2, but the scenario points specifically at mismatched selectors, not at the PFS group, so this misreads the stated evidence even though it is a real failure mode.

Why B is wrong: Differing lifetimes are negotiated independently and a shorter phase 1 lifetime does not prevent phase 2 from installing; rekeying handles lifetimes, so this is not why the selectors fail to match.

Why C is wrong: Route-based tunnels typically use 0.0.0.0/0 selectors but still honour configured quick mode selectors when set, so they are not ignored and configuring them does not by itself discard the SA.

Why D is correct: Phase 2 negotiation requires each peer's local and remote selectors to mirror the other peer's; 10.10.0.0/24 against 10.10.0.5/32 is not a reciprocal match, so the quick mode exchange is rejected and the SA never installs.