Fortinet FCP_FSA_AD-5.0 FCP - FortiSandbox 5.0 Administrator Exam Practice Test

From the High Availability and Management lesson, the Study Guide states:

" You must configure the HA group name, password, and the virtual IP only on the primary node. After you configure those, you can add the secondary node to the group using the commands shown on this slide. "

The hc-slave command (shown as hc-worker for secondary) requires pointing to the Primary Node ' s HA interface IP , not the cluster virtual IP or the primary node ' s port1.

From the exhibit:

Primary Node port4 (HA interface) = 10.50.1.30

Secondary Node port4 = 10.50.1.40

Primary Node port1 = 10.25.1.30

Cluster Virtual IP = 10.25.1.50

The secondary node must connect to the Primary Node ' s dedicated HA communication port (port4 = 10.50.1.30) to join the cluster, making Option B the correct answer.

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

" The universal VM license is a single license that grants you access to multiple VMs. Provides a scalable and cost-effective solution with up to 200 VMs on a single unit. Clone count limits shown on the VM Settings view apply to all enabled VM Types. "

" When you enable Adaptive Scan, FortiSandbox dynamically adjusts the number of clones of any local VMs you have enabled. Enabling this option does not affect the number of remote Mac OS or Windows cloud VMs. "

This confirms:

Option A — Deploying remote WindowsCloudVM and MACOSX clones expands capacity beyond local clone limits since remote VMs are not subject to local clone restrictions

Option D — Adding VM licenses directly increases the number of available VMs up to 200 on a single unit

Reorganizing the scan priority list (B) only affects scan order, not capacity. Adding custom VMs (C) would still be subject to the same local clone limits.

From the Lab Guide (Exercise 4 - Using Inline Scanning) , the following is stated:

" FortiGate and FortiSandbox communicate through port 4443. Management or API ports grant access through port 4443. "

And the CLI command used:

" Enter the following command to enable API access on port2: set api-port port2 "

This confirms:

Option B is correct: Port 4443 uses HTTPS only — API ports will not accept HTTP traffic.

Option C is correct: The API port configuration must be performed using the CLI (set api-port port2), as there is no GUI option for this.

Option A is incorrect: The Study Guide states port3 cannot be a management port, and HA communication ports have dedicated roles that are not interchangeable with API ports.

Option D is incorrect: The CLI command sets the API port directly without requiring a separate administrative interface designation.

The best answer is B. enable Pipeline Mode . The FortiSandbox 5.0 Administrator Study Guide states: “The Pipeline Mode feature improves performance by allowing to scan multiple files, one at a time, without shutting down the VM instance after scanning each file.” It further explains that “FortiSandbox will continue scanning files without shutting down the VM instance, as long as the VM status hasn’t changed.” This directly improves the throughput of dynamic VM-based scanning , which is exactly what the question asks for.

The other options do not fit as well. Option A would reduce waiting time for users, but it lowers security because files could be accessed before a sandbox verdict is returned; the EMS lab profile intentionally enables “Wait for FortiSandbox Results before Allowing File Access” with a Low detection level to maintain strong protection. Option C also weakens security by making remediation apply only when the verdict “equals or exceeds the selected FortiSandbox Detection Verdict Level,” so raising it to Medium would ignore Low-risk detections. Option D enables prefiltering logic, which can reduce submissions, but it does not directly accelerate jobs that already require dynamic scanning. Therefore, Pipeline Mode is the only choice that both preserves a high security level and speeds dynamic scan processing.

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 Deployment and System Settings lesson, the Study Guide states:

" Other ports, with the exception of port3, can also be configured as management ports from CLI. "

" You can set additional ports as management port using the CLI command shown on this slide. "

From the Lab Guide (Exercise 4 - Using Inline Scanning) :

" FortiGate and FortiSandbox communicate through port 4443. Management or API ports grant access through port 4443. "

" Enter the following command to enable API access on port2: set api-port port2 "

Ports that are designated as either administration interfaces or API interfaces cannot be selected for 802.3ad aggregate bonding because:

Option A — Port 4 configured as an administration interface is reserved for management traffic and cannot be repurposed for link aggregation

Option C — Port 4 configured as an API interface is dedicated for API communication (port 4443) and is similarly restricted from being used in aggregate bonding configurations

Port 4 in the Lab Guide is specifically referenced as the HA communication and management port, confirming these restrictions apply when special roles are assigned to interfaces.

The uploaded FortiSandbox 5.0 Administrator Study Guide states that each VDOM is handled independently by FortiSandbox, not under the root VDOM’s authorization. It explicitly explains that “each VDOM is treated as a separate input device on FortiSandbox” and that each device must be authorized before FortiSandbox will process its submissions. It further adds that only when auto-authorization is enabled will FortiSandbox automatically authorize VDOMs as files are submitted.

Therefore, the new VDOM does not inherit the root VDOM’s authorized state. Since the question does not say that auto-authorization is enabled, FortiSandbox will not automatically trust or process that new VDOM as if it were already approved. This eliminates A and C. Option D is incorrect because the issue is not that the administrator must manually configure the VDOM on FortiSandbox; the study guide specifically identifies authorization as the required control. For that reason, B is the best answer: the new VDOM must be manually authorized before its submitted files are inspected.

From the Deployment and System Settings lesson, the Study Guide explicitly states what SIMNET cannot do with real traffic:

" When the malware attempts to download a file, FortiSandbox provides a fake download package. This allows the downloader to successfully execute; however, FortiSandbox cannot run its antivirus inspection on the file. "

" If the malware creates a callback connection to an IP, FortiSandbox cannot rate the IP, to determine if it ' s a botnet server. "

This confirms:

Option A (AV inspection) — Cannot be performed because SIMNET provides fake download packages, preventing real antivirus scanning

Option C (IP reputation) — Cannot be performed because SIMNET uses internal IPs for DNS responses, making IP reputation lookups meaningless against real botnet databases

Dynamic scan and URL rating can still occur inside the sandbox even without real internet access.

The Results Analysis section gives direct malware-type definitions. It says: “A downloader attempts to download malicious content from a remote system” , “A dropper installs malicious content” , “A trojan appears to be a legitimate software application” , and most importantly, “A rootkit attempts to hide its components by replacing valid system files.”

That exact wording matches the question statement about malware attempting to replace vital system executables . Replacing valid system files is classic rootkit behavior because the purpose is concealment and persistence by hiding malicious components behind trusted operating-system files. A dropper’s main role is delivering payloads. A trojan is mainly deceptive software that appears legitimate. An exploit takes advantage of a vulnerability. None of those definitions match the described behavior as precisely as the rootkit definition in the Study Guide. Therefore, the malware type being observed is Rootkit .

The exhibit labels 10.25.1.50 as the cluster virtual IP address . The Study Guide explains that in HA configuration, “You must configure the HA group name, password, and the virtual IP only on the primary node.” It also says: “You must also configure an external interface for external communication and an IP address that will be used as a virtual IP for the whole cluster. Devices will interact with the cluster using this virtual IP.”

That is why the command for the primary node must point to the cluster virtual IP , not to the individual port1 addresses of the primary, secondary, or upstream firewall. In the exhibit, 10.25.1.30 is the primary node’s own port1 IP, 10.25.1.40 is the secondary node’s port1 IP, and 10.25.1.254 is the network device. The only address that matches the required cluster virtual IP is 10.25.1.50 , so the correct command is hc-settings -si iport1 -a10.25.1.50 .

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.

The FortiSandbox 5.0 Administrator Lab Guide shows that, when diagnosing FortiMail submission issues, the required FortiMail debugs are sandboxclid and deferd . It explicitly instructs: “Enter the following commands to enable both deferd and sandboxclid debugging” and then shows that the deferd daemon spools the email and later releases the email from the queue folder after FortiSandbox processing.

Because sandboxclid is not one of the answer choices, the best answer among the listed FortiMail debug tools is deferd . It is the FortiMail daemon directly shown in the official lab workflow for troubleshooting submission-and-verdict handling. The other options in the answer list are not the ones the lab uses for FortiMail-to-FortiSandbox submission troubleshooting. So, based on the uploaded guide, diagnose debug application deferd is the correct choice.