Select Two (Multi-Select) Questions

Copying files via USB drive.

Why it fails: FortiManager does not support backing up its configuration to a USB drive. It tempts because USB media is a familiar offline backup method for FortiGate devices, but FortiManager backups are taken via the GUI or CLI to FTP, SCP, SFTP or TFTP destinations.

Using the 'Backup' button on the FortiGate.

Why it fails: The FortiGate's Backup button exports that device's own configuration, not FortiManager's database, so it cannot satisfy a FortiManager backup requirement. It is tempting because it is the standard method for backing up a FortiGate, which would be correct if the question asked about the managed firewall rather than the manager.

Automatic cloud sync to FortiCloud.

Why it fails: FortiManager has no native automatic cloud sync to FortiCloud for configuration backups. It tempts because FortiCloud offers hosted logging and management services, but configuration backup requires the scheduled backup to FTP, SCP, SFTP or TFTP, or a manual download.

They can only be run once.

Why it fails: FortiManager scripts are stored objects that can be executed repeatedly against devices, on demand or on a schedule, so a single-run limitation is false. It is tempting because some script types are tied to a one-off provisioning action, and would be correct if the question described a CLI template applied once during device onboarding.

They automatically convert to policies.

Why it fails: Scripts execute CLI or Tcl commands on managed FortiGates; they do not transform into policy objects. The confusion stems from policy-package scripts, which run during installation of existing policies, but no automatic conversion into policies occurs — scripts and policies remain separate object types.

They require a separate license.

Why it fails: Scripts are a built-in FortiManager feature requiring no additional licence; they are available with the base product. The misconception likely comes from licensed add-ons such as FortiGuard services, but scripting capability is included, so no separate purchase governs script creation or execution.

The number of registered devices

Why it fails: Registered device count does not drive report generation load; the factors are the number of logs and the report time range. It is tempting because device inventory feels resource-related, but report performance depends on log volume queried, not endpoints registered to the manager.

The firmware version of the devices

Why it fails: Device firmware version does not affect report generation performance; log volume and report time range do. It is tempting because firmware governs feature availability, but report rendering queries stored logs, so version differences do not change the processing workload.

The CPU temperature

Why it fails: CPU temperature is a hardware health metric, not a report generation factor; log volume and time range determine performance. It is tempting because thermal throttling can slow any system, but FortiManager report performance is governed by the dataset queried, not sensor readings.

FTP

Why it fails: FortiMail retrieves mail using POP3 and IMAP from upstream servers; FTP transfers files and carries no mail-retrieval semantics. It is tempting because FTP is a common transfer protocol, but it lacks the mailbox access commands FortiMail requires, so it cannot fetch messages.

HTTP

Why it fails: HTTP is a web transfer protocol, not a mail retrieval protocol; FortiMail retrieves mail via POP3, IMAP and their secure variants. It is tempting because HTTP underpins webmail interfaces, yet retrieval from a mailbox server requires POP3 or IMAP semantics.

DNS

Why it fails: DNS resolves hostnames to IP addresses and carries no mail retrieval capability. FortiMail retrieves mail using POP3 and IMAP, with DNS merely supporting name resolution for those connections. Treating DNS as a retrieval protocol confuses transport addressing with mailbox access.

ADOM Variables

Why it fails: ADOM variables are metadata scoped to an administrative domain for policy substitution, not device settings propagated by a provisioning template. It is tempting because variables appear in policy configuration, but templates carry concrete objects such as firewall policies, interfaces and routing entries.

Firewall Policies

Why it fails: Firewall policies are security rules applied at the device or network level, not settings delivered through a provisioning template. Provisioning templates carry configuration such as firmware, VPN profiles and certificates. Firewall policies are tempting because they also control device behaviour, but they are managed through policy packages, not provisioning.

Firmware Images

Why it fails: Provisioning templates push configuration objects such as firewall policies, interfaces and ADOM variables to managed devices; firmware images are deployed through separate firmware management, not templates. It is tempting because firmware is a device setting, yet the template mechanism carries no image payload or upgrade scheduling.

Standard Web Browser

Why it fails: A web browser is client software for rendering pages, providing no fabric telemetry, logging, or policy enforcement role. It is tempting because administrators use browsers to reach FortiGate and FortiManager GUIs, but the Security Fabric components are FortiGate, FortiManager, FortiAnalyzer, and Fabric Connectors.

Third-party printer

Why it fails: A printer is an endpoint peripheral, contributing no security telemetry, enforcement, or management function to the fabric. It is tempting because fabric visibility can extend to IoT devices, yet core components are FortiGate, FortiManager, FortiAnalyzer, and Fabric Connectors, not arbitrary networked hardware.

Replacing the ISP

Why it fails: Replacing the ISP is a network connectivity function, not a web application security benefit. It is tempting because FortiWeb sits inline with traffic, but it would be correct only if the question asked about WAN link redundancy; FortiWeb's benefits are application-layer protection such as SQL injection and XSS defence.

Physical security of the server room

Why it fails: FortiWeb operates at the application layer, inspecting HTTP requests; it has no role in controlling physical access to a server room. It is tempting because FortiWeb can restrict access to administrative interfaces, but that scenario concerns logical application security, not locks, cameras, or environmental controls.

Syslog

Why it fails: Syslog exports event and traffic logs to external collectors; it performs no sender verification. Spoofing prevention requires sender authentication checks such as SPF, DKIM and DMARC, which validate the envelope and header identity before acceptance.

Antivirus

Why it fails: Antivirus scans message bodies and attachments for malicious code; it does not validate the sender's identity. Anti-spoofing relies on SPF, DKIM and DMARC authentication, which verify the envelope sender and signing domain rather than payload content.

POP3

Why it fails: POP3 is a mailbox retrieval protocol for clients downloading stored mail; it plays no role in authenticating inbound senders. Spoofing prevention needs SPF, DKIM and DMARC checks applied during SMTP receipt, before messages reach any mailbox.

Change Firmware automatically

Why it fails: Change Firmware automatically is a FortiManager upgrade schedule, not an Install Workflow setting. Install Workflows define per-device deployment steps such as install targets, interface mappings and policy package assignment, so firmware scheduling falls outside their scope. It would be the correct choice when automating firmware upgrades across managed devices.

Delete Policy after Install

Why it fails: Install Workflows offer no option to delete policies after installation; policies persist on the device until replaced or removed manually. It tempts because temporary policy staging sounds useful, but the workflow only controls when and where existing packages install.

It requires all backend servers to be on the same subnet

Why it fails: Layer 7 load balancing operates on HTTP headers, URLs and cookies, so FortiADC forwards requests to real servers across routed subnets; same-subnet placement is not a requirement. The claim is tempting because Layer 2/3 designs and some direct server return modes do constrain server placement, but content-based virtual servers do not.

It only supports TCP-based traffic

Why it fails: FortiADC's Layer 7 load balancing inspects and routes application-layer protocols including HTTP and HTTPS, so restricting it to TCP-only contradicts the scenario's requirement. TCP load balancing operates at Layer 4, where FortiADC distributes connections without parsing requests; that is the correct choice when only transport-level distribution is needed.

It cannot perform health checks on web servers

Why it fails: FortiADC performs Layer 7 health checks on web servers, probing HTTP responses to verify application availability. The claim is tempting because Layer 4 monitors exist, but Layer 7 load balancing specifically includes HTTP/HTTPS health monitoring, making this statement false.

Syslog

Why it fails: Syslog transports event and log messages to a collector; it carries no credential exchange, so it cannot authenticate quarantine portal users. It is tempting because FortiMail generates syslog for mail and authentication events, but that is outbound logging, not a portal login method such as LDAP or RADIUS.

SNMP

Why it fails: SNMP is used for monitoring and polling device statistics and traps; it provides no user credential verification, so it cannot authenticate quarantine portal logins. It is tempting because FortiMail exposes SNMP for health monitoring, but portal authentication requires a directory or RADIUS-style method, not a management protocol.

ICMP

Why it fails: ICMP carries network diagnostics such as echo requests; it transports no authentication credentials, so it cannot validate quarantine portal users. It is tempting because ICMP confirms reachability to the FortiMail appliance, but reachability is not identity verification, which requires LDAP, RADIUS or local accounts.

Install a web certificate on the FortiGate

Why it fails: RADIUS authentication between FortiGate and FortiAuthenticator uses a shared secret and server IP; no web certificate is exchanged for that. Certificates belong to EAP-TLS or LDAPS scenarios, where the FortiGate validates the FortiAuthenticator's identity during a TLS handshake, which is a different integration.

Enable LDAP on the FortiAuthenticator

Why it fails: LDAP governs directory lookups, not RADIUS authentication between FortiAuthenticator and FortiGate, so enabling it does not satisfy the integration steps. It is tempting because FortiAuthenticator commonly uses LDAP as a backend user store, but the required steps involve configuring the RADIUS client and shared secret instead.

Configure SAML on the FortiGate

Why it fails: SAML governs federated web single sign-on, not RADIUS authentication between FortiAuthenticator and FortiGate. It is tempting because FortiAuthenticator supports SAML IdP roles, but that suits browser-based SSO; RADIUS integration instead needs a RADIUS client entry on FortiAuthenticator and a matching RADIUS server object on the FortiGate.

Rename file

Why it fails: DLP actions govern how detected sensitive data is handled in transit, such as block, log or quarantine; renaming a file is a filesystem operation with no DLP sensor or profile trigger. It tempts because file handling sounds data-related, but DLP acts on traffic content, not stored file names.

Create copy

Why it fails: Create copy duplicates an object or policy within FortiManager or FortiGate configuration; it is not a DLP enforcement action. It tempts because copying data sounds like data-loss handling, yet DLP actions operate on matched traffic, offering block, allow, log or quarantine rather than file duplication.

Report templates

Why it fails: Report templates belong to the Log & Report section, not System Settings, which contains administrative configuration such as administrators, profiles, HA and certificates. It is tempting because reporting is configured centrally, but templates are a logging feature rather than a system-level setting.

FortiView widget configuration

Why it fails: FortiView widget configuration sits under Log & Report or dashboard areas, not System Settings, which holds administrative items such as administrators, profiles, HA and certificates. It is tempting because FortiView is a core FortiGate feature, but it is a monitoring view rather than a system-level setting.

All logs must be archived

Why it fails: Reports query indexed logs in the FortiAnalyzer log database, so archiving them removes them from active search and breaks report generation. Archiving suits long-term retention or compliance storage, where logs are moved off to external media rather than kept queryable.

The system must be in collector mode

Why it fails: Collector mode only forwards logs to an upstream FortiAnalyzer or syslog server and stores nothing locally, so no dataset exists to report on. Collector mode is the right choice when a FortiGate or FortiAnalyzer acts purely as a relay in a tiered logging topology.

The FortiGate must be offline

Why it fails: Reports run against logs already received and indexed; the FortiGate being offline neither enables nor is required for this, and live log flow is normally expected. Taking a FortiGate offline is relevant to maintenance or firmware upgrades, not report execution.

TLS certificate validation

Why it fails: TLS certificate validation secures the transport session between mail servers; it is not one of the content checks the AntiSpam profile performs on a message. It is tempting because FortiMail does validate certificates elsewhere, such as for TLS policy or LDAP lookups, where certificate verification genuinely matters.

Attachment file size

Why it fails: Attachment size is enforced by the content or attachment-size limits in a protection or delivery rule, not by AntiSpam scanning. It is tempting because oversized attachments often accompany spam, yet the AntiSpam profile inspects sender reputation, heuristics and DNSBLs rather than byte counts.

License expiry alert

Why it fails: License expiry appears as a widget and alert in Device Manager, not as a status-monitoring method for managed FortiGates. It reports entitlement state; valid monitoring uses the device status column, health monitors, and logs, which reflect reachability and operational state.

Global policy report

Why it fails: Global policy reports summarise policy usage across the estate; they do not monitor managed FortiGate status. Device Manager monitoring relies on status indicators, health checks, and event logs, so a policy report is unrelated to device reachability or health.

Firmware log

Why it fails: Firmware logs record upgrade history, not live device status. Device Manager shows managed FortiGate state through status columns, health monitors, and event logs; a firmware log is an audit trail and cannot indicate whether a device is online or offline.

Deleting the ADOM

Why it fails: Playbooks trigger response actions such as quarantining endpoints, blocking indicators or creating incidents; deleting an ADOM is an administrative FortiAnalyzer task, not a playbook action. It is tempting because playbooks can modify device configuration, but ADOM deletion is outside their connector scope, so it would fit a question about FortiAnalyzer administration.

Changing system time

Why it fails: FortiSoC playbooks orchestrate incident-response tasks such as blocking IPs, quarantining endpoints or enriching alerts; altering system time is not an exposed playbook action. It is tempting because playbooks can run CLI-based tasks, but time changes belong to administrative configuration, not automated response workflows.

Rebooting the FortiAnalyzer

Why it fails: Playbook actions target security response, not appliance lifecycle management; rebooting FortiAnalyzer is an administrative maintenance task performed from the device itself. It tempts because playbooks do execute FortiAnalyzer tasks such as running reports or queries, yet reboot remains outside the automation action set.

Email routing

Why it fails: FortiADC load-balances and optimises application traffic; it does not route or relay email. Email routing is a mail-transfer function handled by FortiMail, which would be the correct selection when the requirement is SMTP relay, spam filtering or mail gateway processing.

DHCP server

Why it fails: FortiADC distributes application traffic across server pools; it does not allocate IP addresses to clients. DHCP serving is a FortiGate or dedicated server role, which would be the correct choice when the requirement is dynamic address assignment on a network segment.

Automatically patch the server vulnerability

Why it fails: FortiWeb cannot patch a backend server's vulnerability; it blocks, alerts, or rewrites the offending request instead. It tempts because vulnerability scanning and virtual patching features exist, which would be correct when FortiWeb shields an unpatched application through signatures rather than modifying the server itself.

Increase the backend server CPU

Why it fails: FortiWeb cannot alter backend server hardware; it acts on the HTTP session itself, blocking, alerting or rewriting the request. Raising CPU capacity belongs to infrastructure scaling, and would be the right response to resource exhaustion on the server, not to a detected request violation.