FGSP only sync sessions and it occur at L3 by default. We can move it at L2 with the set seesion-sync-dev. Configuration sync is an independant feature and occur, by default, at L2 as is part of FGCP and use hbdev command. Configuration sync can be configure to occur at L3 with the command unicast-peers, which is not the case here. If we move the sessions sync at L2, the configuration is already sync at L2 both will occur at L2. https://docs.fortinet.com/document/fortigate/7.2.7/administration-guide/84777/standalone-configuration-synchronization

D is correct https://docs.fortinet.com/document/fortigate/7.2.7/administration-guide/84777/standalone-configuration-synchronization

Answer: D https://community.fortinet.com/t5/FortiGate/Technical-Tip-Suggested-Parameters-to-use-for-a-FortiGate/ta-p/230162

I see a lot of discussion here with regards to the correct answer being either A or D. I think D is correct based on pages 113 and 118 in the Study Guide. Page 118 specifically states that Layer 2 is required for config sync in a FGSP standalone cluster configuration. And that you can enable session synchronization with layer 2 with the set session-syn-dev <interface #> command. I am a bit conflicted in the choice though, so it needs some further studying to be sure.

p113 config sync remains at the layer 3

Answer is A:To have only configuration synchronization in layer 3 p113 When peering over FGSP, by default, the FortiGate devices or FGCP clusters, share information over layer 3 between the interfaces that are configured with peer IP addresses. You can also specify the interfaces used to synchronize session in layer 2 instead of layer 3 using the "session-sync-dev" setting. When a session synchronization interface is configured and FGSP peers are directly connected on this interface, then session synchronization is done over layer 2, only falling back to layer 3 if the session synchronization interface becomes unavailable.

Session synchronization You can specify interfaces used to synchronize sessions in L2 instead of L3 using the session-sync-dev setting. For more information about using session synchronization, see Session synchronization interfaces in FGSP.

The answer is D.

https://docs.fortinet.com/document/fortigate/6.2.14/cookbook/849059/ha-heartbeat-interface And: https://docs.fortinet.com/document/fortiweb/7.4.0/administration-guide/435480/synchronization "The configurations of the active (or primary ) node is automatically synchronized to all the members in the HA group. Synchronization ensures that all appliances in the group remain ready to process traffic, even if you only change one of the appliances. Synchronization traffic uses TCP on port number 6010 and a reserved IP address." session-sync-dev remains the traffic as layer 2. The study guide always only talks about the session sync.

The answer is D.

The answer is D. Page 113: When peering over FGSP, by default, the FortiGate devices or FGCP clusters, share information over layer 3 between the interfaces that are configured with peer IP addresses. You can also specify the interfaces used to synchronize session in layer 2 instead of layer 3 using the "session-sync-dev" setting. When a session synchronization interface is configured and FGSP peers are directly connected on this interface, then session synchronization is done over layer 2, only falling back to layer 3 if the session synchronization interface becomes unavailable.

The answer is D. Page 113: When peering over FGSP, by default, the FortiGate devices or FGCP clusters, share information over layer 3 between the interfaces that are configured with peer IP addresses. You can also specify the interfaces used to synchronize session in layer 2 instead of layer 3 using the "session-sync-dev" setting. When a session synchronization interface is configured and FGSP peers are directly connected on this interface, then session synchronization is done over layer 2, only falling back to layer 3 if the session synchronization interface becomes unavailable.

A, in a FGSP Cluster mode you can set that sessions are replicated over L2 and configuration remain in L3 with session-sync-dev:

The answer is D