FCP_FSA_AD-5.0 Questions and Answers

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

From the FortiClient EMS Integration lesson, the Study Guide explicitly states:

" It is always a good idea to place the files that are submitted by FortiClient, high on the Job Queue Priority since these are files that end users need immediate access to. In most cases, end users might not be willing to wait for a long time to access these files and placing the FortiClient submitted files high on the Job Queue Priority ensures that these files receive high priority for scanning from FortiSandbox. "

Looking at the exhibit, the Job Priority Configuration shows:

Positions 1-4: On-Demand inputs (highest priority)

Position 5: FortiGate InlineBlock

Positions 6-11: Other sources including FortiWeb, File RPC, Device, FortiClient

As a best practice, FortiClient should rank after On-Demand (positions 1-4) but before FortiGate inputs — since end users need immediate file access, FortiClient submissions should be near the top but On-Demand scanning takes highest precedence.

The Study Guide explains the default behavior first: “You must authorize FortiClient EMS on FortiSandbox. FortiSandbox automatically authorizes all FortiClient endpoints managed by an authorized FortiClient EMS.” It then adds the key point for this question: “To change the default FortiClient authorization behavior, use the command shown on this slide to authorize FortiClient endpoints using FortiSandbox CLI. By default, FortiClient inherits its authorization status from the managing EMS or FortiGate.”

Because the question specifically shows the CLI command set device-authorization -a , it is asking about the behavior after changing the default . The default inheritance model described in option A applies before the override. After this command, FortiSandbox is set to authorize FortiClient endpoints directly and automatically , which makes C the correct answer. Option B is incorrect because the command is specifically about FortiClient endpoints , not other devices in general. Option D is too broad and does not match the Study Guide’s explanation, which is limited to FortiClient authorization behavior.

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

" You must configure the HA group name, password, and the cluster virtual IP. The worker nodes provide load balancing. The primary node distributes scan jobs to the worker nodes. "

" You must configure the HA group name, password, and the virtual IP only on the primary node... Devices will interact with the cluster using this virtual IP. "

From the exhibit topology:

Cluster Virtual IP address = 10.25.1.50

Primary Node port1 = 10.25.1.30

Secondary Node port1 = 10.25.1.40

Worker Node port1 = 10.75.1.10

The worker node must be configured to point to the Cluster Virtual IP (10.25.1.50) , not the individual primary node IP. This is because worker nodes join the cluster by connecting to the cluster virtual IP address.

Therefore the correct command is: hc-worker -a -sI0.25.1.50 -p < password >

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.

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.