FCP_FSA_AD-5.0 FCP - FortiSandbox 5.0 Administrator Questions and Answers

The FortiSandbox 5.0 Administrator Lab Guide explicitly states during the inline scanning configuration: “FortiGate and FortiSandbox communicate through port 4443. Management or API ports grant access through port 4443.” In the same exercise, the guide has you enable API access on port2 specifically so inline scanning can function, which confirms that the integration depends on FortiGate reaching FortiSandbox over TCP/4443 .

In this scenario, the intermediate firewall currently allows TCP/3389, UDP/53, and TCP/443, but not TCP/4443 . That is why inline scanning stopped working after the redesign. TCP/443 is not sufficient here because the documented FortiGate-to-FortiSandbox inline communication port is 4443 , not standard HTTPS 443. The other ports in the options do not match the inline-scanning communication requirement described in the uploaded lab materials. Therefore, the required fix is to allow FortiGate access to FortiSandbox on TCP/4443 .

The correct answer is B. 50 seconds . The Study Guide explicitly states: “FortiGate holds the file while waiting for a verdict from FortiSandbox… The default file inspection timeout, and maximum, is 50 seconds.” This is the clearest direct statement for the default timeout used with inline scanning mode on FortiGate.

The Lab Guide confirms the same design limit from the operational side. During the inline scanning exercise, it notes: “Because of the inline scanning time-out limit (maximum of 50 seconds), it ' s not recommended to submit files for VM inspection.” That reinforces that inline scanning is designed for quick decision phases such as active content, community cloud, antivirus, and static analysis, not long VM dynamic analysis jobs. Therefore, options A, C, and D are incorrect because they are far above the documented inline inspection limit. The default FortiGate inline scanning timeout is 50 seconds .

From the Deployment and System Settings lesson, the Study Guide explicitly states:

" Initial port1 IP configuration must be performed from the console, using the commands shown on this slide. If your management computer is on a separate subnet from FortiSandbox, you must specify a gateway address using the commands shown on this slide. "

The two required commands are:

set port1-ip < IP address > — to assign the IP address to port1 for GUI access

set default-gw < IP Address > — to configure the default gateway so the management computer can reach FortiSandbox from a different subnet

Option B (set api-port port1) is for API access configuration, and Option C (set admin-port port1) is not a valid FortiSandbox CLI command for this purpose.

From the Scanning and Rating Components lesson, the Study Guide explicitly states:

" VM images are downloaded from FortiGuard, using port1. So, you must ensure FortiSandbox has a default route and internet connectivity for port1. "

The exhibit confirms this — the test-network output shows:

System DNS resolve: Failed for both bing.com and fsavm.fortinet.net

fsavm.fortinet.net is the FortiGuard VM image download server

This DNS failure on the system side (port1) confirms there is no internet connectivity on port1 , preventing VM image downloads. Note that port3 internet shows " Warning: VM to access internet: Disabled " — but port3 is only for VM sandboxing traffic, not for downloading VM images.

From the FortiGate Integration lesson, the Study Guide explicitly states:

" The quarantine daemon is involved in submitting files to FortiSandbox. "

" The quarantine daemon also receives the verdicts returned by FortiSandbox. "

" The quarantine daemon is responsible for sending requests for the dynamic lists generated by FortiSandbox. This includes the malware package, URL package, and the extension lists. "

From the Lab Guide (Exercise 3 - Using FortiGate Diagnostics):

" Enter the following commands to enable debugging for the quarantine daemon: diagnose debug application quarantine -1 "

The quarantined daemon (Option B) handles both file submissions to FortiSandbox AND receives verdicts back from FortiSandbox in real time, making it the correct daemon to monitor for verdict reception verification.

From the Scanning and Rating Components lesson, the Study Guide explicitly states:

" The second section of the Scan Profile, VM Association, allows you to define file extensions and VM image associations. This means that specific files are sandboxed by the associated VM image. To assign a file to a VM image, the following conditions must be true:

The file type must be configured to enter the job queue (first section of the scan profile).

The VM image clone value cannot be a non-zero number. "

This directly confirms:

Option B — The VM image clone value must be a non-zero number (clones must be allocated)

Option C — The file type must be configured to enter the job queue via the scan profile Pre-Filter section

Options A and D, while potentially relevant in practice, are not listed as the two required conditions in the Study Guide.

From the Scanning and Rating Components lesson, the Study Guide explicitly states:

" FortiSandbox allows you to modify the number of CPUs and memory assigned to a custom VM. This feature is supported on hardware models and private cloud VMs. "

Hardware models = Device-based (Option C)

Private cloud VMs = Private cloud (Option A)

Azure non-nested mode and FortiSandbox Cloud do not support custom VM creation as per the Study Guide.

From the FortiWeb Integration lesson, the Study Guide explicitly states:

" You can configure FortiSandbox file submission in a file security policy. Any files not detected by the FortiGuard antivirus engine will be uploaded to FortiSandbox. "

" You can configure FortiWeb to send attachments to FortiSandbox for additional scans to detect advanced persistent threats or zero-day attacks. "

From the Lab Guide (Exercise 1 - FortiWeb Integration):

" Click Web Protection > Input Validation > File Security. In the File Security Policy section, click Create New. Configure Send Files to FortiSandbox: Enabled. "

This confirms that File Security (Option A) is the correct location on FortiWeb to configure FortiSandbox file submission settings.

The correct answer is D . The Study Guide states that FortiSandbox has default administrative profiles and specifically says: “The Read Only profile is intended to be used for system-wide monitoring and reporting tasks, whereas the Device profile is intended to be used for monitoring alerts and reporting for a specific device.” That wording directly matches the question requirement to limit access based on the system that submitted the scan request . In other words, FortiSandbox uses administrator profiles to control whether an admin can view broad system-wide activity or only jobs and alerts related to a specific submitting device.

This eliminates the other options. The Study Guide does not describe device groups , log server settings , or netshare groups as the mechanism for restricting admin visibility of scan jobs by submitter. Instead, access control is tied to the admin profile model . The Device profile is the exact fit because it narrows monitoring and reporting to a particular device context rather than the entire system. Therefore, the way to limit an administrator’s access to scan jobs by the submitting system is by configuring administrator profiles that define job access .