Observed behavior:

Devices in the VLANcan ping FortiGate→ gateway reachability OK.

FortiGatecan ping devicesin that VLAN → return path OK.

Inter-VLAN routingworks → FortiGate’s L3 and policies are fine.

Devices in the same VLAN cannot ping each other→ problem is on theL2 switching plane, not L3.

On FortiSwitch (managed by FortiGate), there is a feature calledAccess VLAN(sometimes described in NAC/dynamic segmentation context):

WhenAccess VLANis enabled on a VLAN, the switchdoes not perform normal L2 forwardingbetween hosts in that VLAN.

Instead, all traffic from endpoints in that VLAN isforced upstream to FortiGate, as if every frame were destined for the gateway.

This is used for designs where you wantall intra-VLAN traffic inspected by the firewall, implementing micro-segmentation.

Resulting behavior:

Host → FortiGate: works (frames are forwarded to FortiGate).

FortiGate → Host: works (routed back).

Host A → Host B (same VLAN):

Frame from A goes to FortiGate.

FortiGate seessource and destination in same subnet; depending on policy, it may drop or not have a policy allowing that traffic.

Even if allowed, certain designs still break pure L2 expectations.

In the exam scenario, the key point is:

IfAccess VLAN is enabled,local L2 communication within that VLAN is disabled, so hosts in the same VLAN cannot communicate directly.

That perfectly explains:

Same VLAN hosts can’t ping each other

But they can both reach FortiGate and beyond

Why the other options are less likely / incorrect

B. FortiSwitch MAC address table is missing entries

If MAC table were empty/bad,nothingin that VLAN would work properly, including pinging FortiGate.

C. FortiGate ARP table is missing entries

Then FortiGate couldn’t ping the devices either; but it can.

D. Native VLAN misconfigured on ports

That would affect connectivity to FortiGate too, not only host-to-host.