Free Practice Questions for Fortinet FCP_FSA_AD-5.0 Exam

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 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.

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

" The rating engine analyzes the tracer engine ' s information. " — confirms Option E

" FortiSandbox checks connection attempts to any URLs against the FortiGuard web filtering database. FortiSandbox submits hashes of files generated during sandbox analysis to the Sandbox Community Cloud to check for existing verdicts. Additionally, it compares these file hashes against the FortiGuard Cloud-Based Threat Intelligence database. " — confirms Option B

" After analysis is complete, the rating engine generates a verdict. " — confirms Option D

" Finally, the rating engine generates a report containing all details collected by the tracer engine. "

Option A is incorrect as the rating engine does not rate third-party device effectiveness. Option C is incorrect — verdict sharing is done by the FortiSandbox system through malware/URL packages, not specifically by the rating engine component.

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.

The Study Guide is explicit about the FortiMail–FortiSandbox workflow. It states: “On top of file submissions, FortiMail can also submit extracted URLs from emails to FortiSandbox for inspection. FortiMail queues the email while waiting for a verdict. FortiSandbox inspects all submitted files and URLs. FortiSandbox then generates a verdict and sends that verdict in reply to FortiMail. FortiMail uses the verdict to apply the configured action.”

This directly supports D because FortiSandbox analyzes file and URL objects . It supports B because FortiSandbox generates a verdict and returns it to FortiMail. And it supports E because the integrated workflow includes the email being queued during analysis while FortiSandbox is processing the submitted objects. Option C is incorrect because FortiMail is the device that submits the objects to FortiSandbox, not FortiSandbox itself. Option A is also incorrect because updating FortiGuard databases is not one of the three ATP integration actions described for the FortiMail workflow. Therefore, the correct three answers are B, D, and E .

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 .

From the FortiClient EMS Integration lesson, the Study Guide states that FortiSandbox and FortiClient EMS integration helps break the kill chain by monitoring all downloads, removable media, mapped network drives, and email client file downloads — intercepting threats at the Delivery stage before they can execute on the endpoint.

Additionally, from the Attack Methodologies section: " When a USB is attached to a host protected with FortiClient, FortiClient can send the files on the USB drive to FortiSandbox for analysis, before allowing the user access to the files " — further confirming the Delivery stage focus.

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

" The status command shows information about the system, including firmware level, device serial number, disk usage, Windows VM status, states of the boot and data disks, and more. For VM appliances, it will also show the FortiSandbox license status. "

The key phrase is " For VM appliances, it will also show the FortiSandbox license status " — making the status command the correct choice for verifying license validity on a FortiSandbox VM deployment.

While vm-license -l shows installed Windows/Microsoft Office license keys, and vm-status shows guest VM image information, neither directly reports on the FortiSandbox appliance license validity. The status command is the definitive command for checking overall system and license status.

From the Scanning and Rating Components lesson, the Study Guide explicitly 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. "

" FortiSandbox will continue scanning files without shutting down the VM instance, as long as the VM status hasn ' t changed. If the VM status changes, then the VM instance will shut down and will be restored for the next job. "

This precisely matches the requirement — using one VM instance for multiple sequential scan jobs without shutting down between submissions. The other options serve different purposes:

Adaptive Scan dynamically adjusts clone numbers

VM Scan Ratio controls the percentage of jobs scanned in a VM

Parallel VM Scan runs multiple VMs simultaneously for a single job