Free FCP - FortiGate 7.6 Administrator practice test: 30 questions with answers

VDOMs split one FortiGate into independent virtual firewalls, each with its own routing, policies and administrators, which gives the required isolation. Interface aliases only label ports, GUI tabs change nothing on the device, and a second unit is a hardware answer the scenario does not need.

Setting the WAN interface addressing mode to DHCP makes the FortiGate request its address, and the default route can be learned from the ISP's DHCP reply. A static address contradicts the requirement, and a VLAN with no address does not obtain an IP. A loopback is not a WAN port configuration.

The get system status command shows the firmware version, serial number, operation mode and other key facts about the unit. Packet capture, ping and policy listings show different things and do not report the firmware or the operating mode.

A read-only access profile scoped to one VDOM gives the junior administrator visibility of what they need and blocks system changes. Super-admin and global admin profiles grant far more than required, and sharing a password removes accountability.

Each VDOM keeps its own routing table and firewall policies, and an interface belongs to one VDOM at a time unless configured otherwise. VDOMs can have separate administrators, and they do not share a routing table or lose their own policies to global settings.

The implicit deny policy at the end of the list drops any traffic that matches no explicit policy, which is the default behaviour. Accepting traffic by default would be a serious gap, forwarding without inspection bypasses the policy, and FortiGuard classification does not decide the default action.

FortiGate evaluates policies from top to bottom and applies the first match, so a new allow policy placed below a blocking policy is never reached. Moving it above the blocking policy fixes the order. Matching by ID, name or from the bottom is not how the policy list works.

Enabling NAT in the firewall policy with the outgoing interface address translates the private source addresses to the WAN address for outbound traffic, which is the standard source NAT. A VIP is for inbound destination mapping, and a static route with a NAT flag does not translate traffic.

A virtual IP maps the public address to the private server, and an inbound policy that uses it as the destination allows access without exposing the private address. An outbound source NAT pool affects connections from the server, an address group does not map addresses, and a static route does not make the server reachable from the internet.

Application control inspects and identifies applications, so a sensor in the policy can allow or block specific applications even on common ports. Port-based policies cannot separate applications sharing a port, static routes do not restrict applications, and a DNS filter blocks domains rather than applications.

An antivirus profile applied to the web policy scans downloaded files for malware for the protocols it inspects. IPS detects network attacks, web filters block by category, and DNS filters block domains, so none of those scans file content.

Deep inspection decrypts the traffic so that the security profiles can examine the content, and clients must trust the inspection certificate. Certificate inspection does not look inside the payload, and no inspection or blanket DNS blocking does not inspect content.

Two web filter profiles applied to the policies of each group give each group its own rules, which is the standard approach. A single profile cannot differ by group, a browser setting does not enforce the FortiGate rule, and a single shared policy cannot apply different profiles to different groups.

A web filter profile blocks sites by category, which matches the requirement exactly. Antivirus scans file content, IPS detects intrusion signatures, and DLP watches for sensitive data, so none of them blocks sites by category.

A site-to-site IPsec VPN is the standard way to connect two FortiGates so that the networks behind them can reach each other securely. A web portal serves individual users, a VLAN trunk cannot traverse the internet securely, and an unencrypted GRE tunnel does not meet the security requirement.

SSL VPN in tunnel mode through FortiClient runs over HTTPS, which works through most restrictive networks and gives full network access. A VLAN on a laptop, a static route through the internet and DNS entries alone do not create a secure tunnel to internal resources.

Phase 1 must match on the pre-shared key and the encryption and authentication proposals, so a mismatch there causes the failure. Policy names and route counts do not affect Phase 1, and a management time difference does not change tunnel negotiation.

Phase 1 establishes the secure channel and Phase 2 defines the protected traffic, and traffic must be routed or allowed into the tunnel interface. Phase 2 depends on Phase 1, tunnels still need policies for the traffic, and both peers must use a matching IKE version.

Enabling FortiAnalyzer logging in the log settings and pointing the unit to the FortiAnalyzer sends the logs centrally, which is the standard configuration. Manual copying is slow and error-prone, turning off local logging loses the logs if the link fails, and ICMP does not carry logs.

The override setting lets a higher-priority unit reclaim the primary role after it recovers, which is the behaviour the administrator wants. VDOM names, DHCP lease times and policy counts do not determine role selection.

A flow debug on the FortiGate shows the policy and processing decision for each packet, which identifies why the traffic is dropped. A speed test measures bandwidth, a laptop capture shows only what reaches it, and a configuration backup does not record packet decisions.

Heartbeat connectivity and monitored interfaces are the usual causes of failover, and the HA event logs and cluster status record the reason for the change. The front-panel colour, policy counts and weather do not cause or record a failover.

Static routes are preferred by lower administrative distance and priority, so the primary route with the lower value is used, and the secondary takes over on failure. Entry order, interface names and packet size do not control route selection.

Policy-based routing directs traffic by source and other criteria to a specified gateway, which meets the requirement. Subnet masks on destinations do not select by source, a single default route sends everything one way, and changing a MAC address does not route traffic by subnet.

When distances are equal, the route with the lower priority value is preferred. Interface names, policy counts and random selection do not decide route choice.

get router info routing-table all lists the routes the unit knows, which is what the administrator needs. Interface listings, packet captures and ping tests do not display the routing table.

A captive portal presents a login page and checks credentials against the directory, then allows the user's traffic according to the policy. A static route or tunnel does not authenticate users, and a DNS filter does not check directory accounts.

Remote user groups imported from the directory let policies match users by department without creating local accounts. Hand-created local accounts do not scale, a shared guest account removes per-user control, and address objects match devices, not users.

FortiToken two-factor authentication applied to the user adds a one-time code as the second factor, which matches the requirement. A longer password is still a single factor, a DNS filter does not authenticate the user, and a static route is not an identity check.

Two-factor authentication protects accounts even if a password leaks, and restricting management to trusted networks with HTTPS-only access reduces exposure. Shared passwords, internet-facing admin access and clear-text passwords all increase the risk of compromise.