FCP_FSA_AD-5.0 Practice Questions

The test-network command output explicitly shows that the "system DNS resolve" fails for external domains, including fsavm.fortinet.net. In FortiSandbox, the management interface (port1) handles system-level communication, which includes reaching Fortinet servers to download guest VM images. The failure of the system to resolve the address required for VM downloads indicates a lack of internet connectivity or proper DNS resolution on port1. Conversely, the test shows port3 successfully resolving the same domains, isolating the failure to the system network interface (port1).

A: The exhibit shows system DNS resolution failing entirely for external domains. This highlights a lack of internet reachability on port1, not inherently the use of a private DNS server.

C: The test-network output specifically shows that DNS resolution via port3 is successful (nslookup bing.com: Success), meaning port3 does have internet connectivity.

D: The "FortiGuard Services" section displays green icons for FDN and related services, indicating the device holds active licenses and can authenticate, despite the localized interface failure.

Fortinet. FortiSandbox 4.4 Administration Guide. Network > Interfaces. (This section details that port1 is the management interface utilized for device administration, FDN communication, and downloading Fortinet-provided VM images).

Fortinet. FortiSandbox 4.4 CLI Reference Guide. test-network command. (Details the output of the command and confirms "system DNS" tests refer to the routing and DNS configured for the primary management interface, port1).

To leverage the Real-Time Anti-Phishing (RTAP) service in FortiSandbox, the specifically designated WEBLink file type must be explicitly associated with a VM image in the scan profile's VM Association settings. The RTAP service works by actively browsing the submitted URL inside the assigned Sandboxing VM to observe web download behavior and detect phishing, spam, or malicious characteristics. As shown in the "VM Association" exhibit, the "Web" category only lists htm, js, lnk, url, and WEBLink is noticeably absent. Because the WEBLink file type is not mapped to a VM clone, the appliance will not forward URLs for the dynamic analysis required by the RTAP service.

A: The url extension is already selected under the 'Web' category in the VM Association exhibit; therefore, this statement is factually incorrect regarding the visible configuration.

C: URL submissions to the RTAP service generally take between 30 to 60 seconds to process. A 300-second VM scan timeout is not a prerequisite for RTAP functionality.

D: Active content pre-filtering identifies embedded executables (like macros or scripts) in files to optimize system throughput. It is not the mechanism that routes URLs to the RTAP service.

Fortinet, FortiSandbox 4.4.7 Administration Guide, Document 34-447-817818-20221018, Section: RTAP Service / URL Submission, p. 78. (Validates that the WEBLink file type must be associated with a VM image to submit URLs to RTAP).

Fortinet, FortiSandbox Data Sheet, Specifications: File Type Support. (Explicitly lists url and WEBLink as two distinct supported file classifications).

In a FortiSandbox High Availability (HA) cluster, the primary node functions as the central point for receiving and distributing analysis jobs. When an MTA job (an email) arrives at the primary node, it assumes the role of a load balancer. It distributes the job to an available node within the cluster for scanning and analysis. This destination node can be one of the secondary nodes or the primary node itself, based on the current workload of all members. This mechanism ensures efficient utilization of cluster resources and maintains high throughput for mail scanning.

A. It processes all MTA jobs by itself.

This is incorrect because it defeats the purpose of load balancing and resource sharing in an HA cluster.

C. It forwards the MTA jobs to all secondary nodes for scanning.

This is incorrect as it would result in redundant scanning and inefficient use of system resources.

D. It rejects the MTA jobs and sends a redirect to the sender.

This is incorrect. The primary node is the designated entry point for the cluster and is responsible for accepting and distributing jobs, not rejecting them.

1. FortiSandbox 5.0.0 Administration Guide, Page 100, Section: "HA Cluster".

The document states: "In a cluster, one FortiSandbox is the primary (master) unit and the other units are secondary (slave) units. The primary unit receives files for scanning and distributes them to the secondary units and itself for processing." This directly supports that the primary node acts as a distributor to all cluster members, including itself.

When creating an API user in FortiSIEM, two key configuration steps are required for security and multi-tenancy. First, the administrator must define the specific source IP addresses or subnets that are permitted to send API requests to the interface. This acts as a network-level access control list. Second, in a multi-tenant deployment, the API user can and should be associated with a specific organization. This ensures that the API key only has access to the data and resources belonging to that designated organization, enforcing data segregation and the principle of least privilege.

C. API interfaces use a system-generated API key and a secret (labeled API Password), not a traditional interactive username and password combination for authentication.

D. While the super/global user can create any API user, an administrative user with sufficient privileges can also create an API user scoped to their own organization.

1. FortiSIEM 5.2.5 Administration Guide, Page 51, "Creating an API User".

The guide provides a screenshot and description of the "New API User" dialog box. It explicitly shows the "Organization" dropdown menu, confirming that an API user can be assigned to a specific organization.

The same section details the "Allowed IPs" field, stating, "Enter the IP addresses that are allowed to access the API," which confirms the requirement for IP-based access control.

2. FortiSIEM 6.3.0 Administration Guide, "Creating API Users" section.

This document reinforces the same principles: "From the Organization drop-down list, select the organization that this API user will belong to."

It also states, "In the Allowed IPs field, enter the IP addresses that are allowed to access the API." This directly supports both correct answers.

The guide also clarifies authentication: "FortiSIEM will generate an API Key and API Password for this user," distinguishing it from standard password authentication.

To successfully deploy FortiSandbox using a BCC adapter, the appliance acts as a Mail Transfer Agent (MTA) to receive blind carbon copies of incoming emails. Two strict prerequisites must be met before enabling this feature. First, the upstream Secure Email Gateway (SEG) must be configured to generate and forward these BCC copies to a dedicated sub-domain specifically designated for the sandbox. Second, standard SMTP routing principles dictate that an MX (Mail Exchanger) record must be added to the DNS server for this sub-domain, ensuring that the forwarded emails are correctly routed to the FortiSandbox's listening IP address.

A: The BCC adapter ingests the entire email via SMTP. Extracting files and URLs is a feature of API or ICAP integrations, not the BCC adapter method.

B: Standard email routing requires an MX record for the specific sub-domain to direct SMTP traffic properly, making an A record alone insufficient for this configuration step.

Fortinet, Inc. FortiSandbox Administration Guide. Section: "System > BCC Adapter". This official vendor documentation explicitly lists configuring the upstream MTA sub-domain and adding the DNS MX record as the two mandatory prerequisite steps for BCC adapter deployment.

The hc-settings -si command in FortiSandbox is utilized to configure the cluster failover IP (Virtual IP) for the primary node in a High Availability (HA) cluster. Based on the provided network topology exhibit, the assigned "Cluster virtual IP address" that must be active on the primary management interface (port1) is 10.25.1.50. Therefore, the correct CLI syntax to map this shared virtual IP to the primary node is hc-settings -si iport1 -a10.25.1.50. This ensures that if the primary node experiences an outage, the secondary node can seamlessly inherit the 10.25.1.50 address to maintain continuous client connectivity and management access.

Option A: This command incorrectly assigns 10.25.1.30, which is already the primary node's dedicated physical IP address, rather than the designated cluster virtual failover IP.

Option B: This option applies 10.25.1.40, which represents the physical IP address of the secondary node's port1, not the required shared virtual HA IP.

Option C: This targets 10.25.1.254, which serves as the upstream network gateway or switch IP address, rather than the HA cluster virtual IP.

Fortinet Document Library. FortiSandbox 3.2.2 Administration Guide. Document ID: 389713. Section: "HA-Cluster" -> "Main HA-Cluster CLI commands", Sub-section: "Step 4 - Configure the primary".

The exhibit displays a job detail overview from FortiSandbox. The summary explicitly states the file was "flagged by the PAIX engine." According to official Fortinet documentation, PAIX is an advanced AI and Machine Learning engine introduced in FortiSandbox 5.0 specifically designed to detect zero-day malware, confirming option A. Furthermore, the PAIX engine identified the file's execution as "potentially malicious activity" exhibiting "high-risk behavior." Within the FortiSandbox rating framework, detecting such severe behavioral indicators results in a malicious or high-risk verdict, classifying the file as a definitive threat to be actioned upon, which validates option D.

Option B: The provided original URL ([http://portal.training.lab/fsa_dropper.exe](http://portal.training.lab/fsa_dropper.exe)) is clearly an internal lab environment address used for file submission, not a FortiGuard-verified known malicious URL.

Option C: This statement contains a typographical/grammatical error ("resulted are defined") and does not map to any valid FortiSandbox job status terminology; the actual analysis status is simply "Done."

Fortinet Document Library, "FortiSandbox 5.0.0 Release Notes," Document ID: 729476, Section: "New features and enhancements" > "Scan & Engine" (Confirms the PAIX engine is a new advanced AI feature for malware detection).

Fortinet Document Library, "FortiSandbox 5.0.0 Administration Guide," Document ID: 805567491, Section: "Introduction" > "SOC assist" (Details the AI-generated job reports, behavioral threat analysis, and risk-based verdicts).

A wildcard administrator object contains no fixed username; FortiGate grants GUI/CLI access to any user who successfully authenticates through the external server that is bound to that object. FortiGate supports only authentication sources that can return the clear-text username required for profile mapping. In FortiOS, the only two account types that satisfy this requirement are RADIUS and LDAP remote-authentication servers. No other local or remote method (e.g., TACACS+, local database, PKI) can be bound to a wildcard administrator entry; therefore only RADIUS and LDAP can be used.

• Local administrator – Wildcard flag cannot be enabled for locally defined accounts; a fixed username is required.

• TACACS+ – FortiOS does not permit binding TACACS+ servers to wildcard admin objects.

• PKI/Certificate – Certificate authentication is configured per user and cannot be combined with the wildcard administrator feature.

• Any other option – FortiOS restricts wildcard admin support strictly to RADIUS and LDAP sources.

1. Fortinet, “FortiOS 7.2 Administration Guide”, section “Creating a wildcard administrator account”, p. 412-413: “Wildcard administrators can be authenticated only through RADIUS or LDAP servers.”

2. Fortinet, “FortiOS 7.2 CLI Reference”, command “config system admin”, parameters ‘set wildcard’, ‘set radius-server’, ‘set ldap-server’, pp. 2111-2112.

3. Fortinet KB Article ID 195339, “Technical Tip: Configuring a wildcard admin account”, paragraph 2: “Wildcard administrators are supported with RADIUS and LDAP authentication servers only.”

4. Fortinet NSE 4 Institute Courseware (FortiGate Infrastructure 7.2), Module 2, slide “Wildcard Administrators”: bullet 2 states “Supported auth servers: RADIUS, LDAP.”

The ability to create and install custom Virtual Machines (VMs) is a feature exclusive to on-premises FortiSandbox deployments. This includes both the physical FortiSandbox Appliance and the FortiSandbox VM (virtual appliance). This capability allows administrators to create a sandboxing environment that precisely mirrors their organization's standard endpoint builds, including specific operating systems, patch levels, and installed applications. Such customization leads to more accurate and relevant threat detection, as malware is tested in an environment identical to the one it would target on the network. Cloud-based services do not offer this level of customization.

FortiSandbox Cloud: This is a multi-tenant, Fortinet-managed service. It uses a standardized set of VM images and does not permit customers to upload their own for security and operational reasons.

FortiSandbox as a Service (SaaS): This is another term for the FortiSandbox Cloud service. As a shared platform, it does not support user-created custom VMs to maintain service integrity and security for all tenants.

---

1. FortiSandbox 5.0 Administration Guide, Page 161, "Customized VM" section.

The guide explicitly states, "FortiSandbox supports installing customized Windows VM images for sandboxing." The procedures outlined in this chapter, involving CLI commands and direct system access, are only applicable to on-premises models (Appliance and VM) where the administrator has root-level control.

2. FortiSandbox Datasheet, "Features" section.

The datasheet for on-premises FortiSandbox models (e.g., FSA-3000F) lists "Custom VM Images" as a key feature. In contrast, the FortiSandbox Cloud Service Description outlines a pre-defined set of OS environments, with no mention of customer-level customization, highlighting the feature's absence in the cloud offering.

3. Fortinet Cookbook, "FortiSandbox - Custom VM" Recipe (500038).

This official guide details the step-by-step process for creating, packaging, and installing a custom VM. The entire procedure requires direct CLI and hypervisor access, which is only possible on a customer-managed FortiSandbox Appliance or FortiSandbox VM.

In FortiSandbox 5.0 you first enter

config system network

and then issue two mandatory setters inside that context:

• set ip / – assigns the management interface address

• set gateway  – installs the system-wide default route

Without both commands the appliance cannot place its GUI (HTTPS) replies on the network, so the GUI is unreachable.

B. set dns … – only specifies resolvers; it does not create an address or default route and is therefore unnecessary for basic GUI reachability.

C. set hostname … – cosmetic; does not influence L3 connectivity needed for GUI access.

(any other un-selected option) – does not configure either the interface IP or the default gateway, both required prerequisites for GUI access.

1. Fortinet. “FortiSandbox 5.0 Administration Guide”, Section 2.1 ‘Initial Configuration – CLI’, p. 29: example shows “set ip … / set gateway …” as first steps.

2. Fortinet. “FortiSandbox 5.0 CLI Reference”, Chapter ‘config system network’, p. 54–55: command syntax for “set ip” and “set gateway”.