The FortiSwitch 7.6 Administrator objectives can be mapped as one packet-and-management path. Physical ports and transceivers create links. VLANs and STP create Layer 2 forwarding. Routing connects networks where configured. FortiLink or standalone management determines where configuration comes from. Deployment topology shapes redundancy and scale. Port security, ACLs, antispoofing, and VLAN security control access. QoS influences treatment. Packet captures and switch information expose what actually happened.
The current FortiSwitch 7.6 Administrator exam groups these skills into FortiSwitch concepts, Deployment and management, Layer 2 control and security, and Monitoring and troubleshooting. Fortinet does not publish domain percentages on the surfaced exam page, so all four groups should be treated as core.
Physical ports sit at the bottom of every switching path
Port mode, speed, transceiver support, split-port behavior, and link state determine whether higher-layer configuration can function. When a VLAN or FortiLink appears broken, the physical interface should be verified before changing policy.
Stack and uplink designs also depend on using the correct physical ports for the intended role.
VLANs define the Layer 2 broadcast and policy boundaries
Tagged and untagged membership determines which Ethernet frames belong to each VLAN and which devices can communicate without routing. A trunk can carry several VLANs, while access-style ports generally attach an endpoint to one local network context.
VLAN mistakes often look like routing or security failures because the endpoint never enters the intended Layer 2 domain.
STP protects redundancy from becoming a loop
Redundant switching links improve availability only when loop prevention selects a safe forwarding topology. STP root choice, port roles, and path cost influence which links forward and which wait in a blocking/discarding state.
The map should show STP beside topology, not as an unrelated protocol.
FortiLink connects switch configuration to FortiGate management
In a FortiLink-managed design, FortiGate provides centralized provisioning and management for attached FortiSwitch devices. That changes the troubleshooting path: an apparent switch configuration issue may originate in FortiGate policy, FortiLink discovery, management reachability, or synchronization.
Standalone FortiSwitch operation uses a different authority model, so candidates need to know which mode the scenario describes.
Deployment topology connects management, redundancy, and scale
Supported FortiSwitch topologies determine how switches connect to FortiGate, to one another, and to endpoints. Stack or tier choices influence failure domains and which links carry management and data traffic.
Topology should therefore be drawn before troubleshooting. The same failed link can have different impact depending on whether it is a FortiLink uplink, stack link, or ordinary access link.
Multi-tenancy creates a logical separation layer
Multi-tenant deployments require administrators to preserve separation while sharing switching infrastructure. VLAN, administrative, management, and security boundaries all contribute.
When one tenant is affected, the troubleshooting scope should remain narrow enough that changes do not disrupt unrelated tenants.
Layer 2 security protects the switching edge
Port security, filtering, antispoofing, ACLs, security profiles, and VLAN security mechanisms control which devices and traffic are accepted. These controls sit after basic connectivity in the map because a link can be healthy while policy intentionally drops frames or packets.
Effective access is the intersection of VLAN placement and security policy.
QoS sits on the forwarding path under congestion
QoS determines how classified traffic is prioritized when resources are constrained. LLDP-MED can help capable endpoints learn voice/network policy information.
QoS troubleshooting requires both policy state and queue/counter evidence; correct markings alone do not prove priority is actually being delivered.
Packet capture links observed traffic to configured state
Packet capture shows what entered or left a point in the network. Switch tables and operational commands show why it took that path. Used together, they can distinguish missing traffic, wrong VLAN, blocked policy, routing failure, or management-plane issue.
A capture should be interpreted only after identifying the interface and traffic direction.
The map becomes a disciplined troubleshooting order
Start with physical link, then VLAN/stack/STP, then FortiLink or management authority, then routing, then security/QoS, then endpoint/application behavior. Use packet capture only where it can answer the remaining question.
The map should include FortiGate policy just outside the FortiSwitch boundary in managed deployments. User traffic may traverse or be controlled by FortiGate even when the access switch is configured correctly. This external policy layer can explain why Layer 2 connectivity is healthy while the application remains blocked.
FortiLink discovery and authorization should be drawn before policy synchronization. A switch that has not been discovered or authorized cannot receive the intended managed configuration. This creates a distinct onboarding state that should not be confused with a healthy FortiLink where one VLAN or port setting is wrong.
Stack state belongs between physical links and management. A stack member can affect available interfaces and topology while the logical configuration still appears centralized. The map should show member health and inter-member links as dependencies below VLAN and STP.
Switching and routing should be separated by the point where a packet leaves one IP network for another. MAC/VLAN tables explain local Ethernet forwarding; route tables explain next-hop selection after Layer 3 lookup. Many troubleshooting mistakes come from looking at the wrong table for the layer being tested.
Port security and antispoofing should be drawn close to endpoint attachment. They can prevent an unauthorized MAC, invalid source behavior, or other local attack before traffic reaches a higher-layer firewall. This is defense in depth at the switching edge.
ACLs and security profiles can sit at different points depending on the FortiSwitch/FortiGate design. The administrator should know which device enforces the control and which logs or counters prove the match. A policy that exists in management is not useful if it is not applied at the traffic path.
QoS and VLAN security can interact because some classifications depend on VLAN, port, device type, or markings. The map should keep policy intent visible: security decides whether traffic is allowed; QoS decides how permitted traffic is treated under contention.
Packet captures should be placed on several possible observation points in the map. Capture before a policy, after a policy, or on an uplink only if that location answers the current question. Comparing two capture points can prove where traffic disappears.
Operational extraction tools should also include configuration and state comparison. If a switch is FortiLink-managed, compare intended managed settings with local operational state. If standalone, compare running configuration with expected topology. Source-of-truth awareness is part of troubleshooting.
Use the final map for blast-radius reasoning. One endpoint affected suggests local port/security. One VLAN affected suggests VLAN/STP/uplink. Several managed switches affected suggests FortiLink/FortiGate/topology. Entire routed destinations affected suggests Layer 3. Scope helps select the first evidence source.
The map should include management traffic separately from user traffic. FortiLink, administrative access, and switch-to-controller communication can fail while local forwarding continues, or user forwarding can fail while the management plane remains healthy. Separating those planes prevents misleading conclusions during partial outages.
Transceiver and split-port configuration should sit below topology because they determine how many physical links exist and at which speeds. A planned stack or uplink design is not feasible if the port hardware or breakout mode does not support it. Physical design constrains logical design.
MAC learning should be drawn between VLAN membership and forwarding. If the expected source or destination MAC is absent from the table, the problem may be endpoint, VLAN, port, or link. If it is learned on the wrong port, a topology or loop issue may be involved.
Routing should include next-hop reachability as well as route presence. A route can exist while ARP/neighbor resolution or the outgoing VLAN fails. The map should therefore connect Layer 3 decisions back down to Layer 2 state.
Security profiles should be connected to traffic inspection or enforcement only where the topology supports them. Candidates should understand the role of FortiSwitch controls versus FortiGate security services rather than assigning every security function to the access switch.
Monitoring should include counters and error trends, not only current up/down state. Rising CRC errors, drops, queue pressure, or repeated FortiLink reconnections can reveal a deteriorating condition before a total outage occurs.
Configuration authority should be annotated on the map. In managed mode, some settings are intentionally derived from FortiGate; in standalone mode, local switch configuration is authoritative. A troubleshooting action that bypasses the intended management model can create drift.
Use the map for change planning as well as incidents. Before adding a VLAN, stack member, ACL, or QoS policy, identify the affected physical ports, management authority, forwarding path, security boundary, and verification evidence. This makes the same mental model useful for proactive administration.
Routing and FortiGate management should be drawn as separate decisions. FortiGate can manage a switch while Layer 3 forwarding still occurs on FortiSwitch in an appropriate design, or user traffic can be routed elsewhere. Management ownership does not automatically define the data-plane gateway.
The completed map should also include a rollback point for changes. A VLAN, STP, ACL, FortiLink, or QoS modification can affect many endpoints quickly. Knowing the previous known-good state and the evidence that validates recovery is part of professional administration, even when the exam question focuses on one feature.
Keep the map version-specific to FortiSwitchOS 7.6 and FortiOS 7.6 so operational assumptions match the live exam.
Version alignment keeps troubleshooting assumptions consistent.
Use the map consistently.
Stay consistent.
For final review, draw one managed FortiSwitch topology and annotate every layer. If a feature has no clear place in the packet or management path, revisit it before the exam.