Nse6 Security Fabric Specialist Topics practice questions

FortiAnalyzer Traffic Log

Why it fails: FortiAnalyzer traffic logs record session flows, not SAML assertion parsing. It is tempting because FortiAnalyzer aggregates authentication events centrally, but the FortiAuthenticator's own SAML debug logs show whether the assertion arrived and was parsed, which traffic logs never capture.

FortiGate Event Log

Why it fails: FortiGate event logs record local system events, not the SAML assertion processing performed by FortiAuthenticator. It is tempting because the FortiGate initiates the SAML request, but the Service Provider that receives and parses the assertion is FortiAuthenticator, so its logs hold the relevant detail.

RADIUS Authentication Log

Why it fails: RADIUS authentication logs cover RADIUS exchanges, not SAML assertions. It is tempting because FortiAuthenticator commonly acts as a RADIUS server, but this scenario uses SAML, where assertion receipt and parsing are logged in FortiAuthenticator's SAML or authentication debug logs instead.

HTTPS

Why it fails: HTTPS is used for GUI management, not for the core Fabric control channel.

SNMP

Why it fails: SNMP is used for monitoring device metrics such as CPU, memory and interface statistics via an SNMP manager. FortiGate-to-FortiAnalyzer log and telemetry exchange uses OFTP on port 514. It is tempting because both involve centralised collection, but SNMP polls status rather than forwarding logs.

Syslog

Why it fails: Syslog is a generic log-forwarding standard used to send events to third-party collectors, not the native FortiGate-to-FortiAnalyzer Fabric channel. That communication uses OFTP over port 514. It is tempting because both transport log data, but FortiAnalyzer expects OFTP for Fabric integration.

By adding it to the FortiAnalyzer

Why it fails: FortiAnalyzer does not manage switches directly.

By enabling LLDP on the port

Why it fails: LLDP only advertises neighbour information; authorisation requires the administrator to approve the FortiSwitch on the FortiGate's managed-switch or Security Fabric page. It tempts because LLDP must be enabled for the FortiGate to discover the switch, but discovery is not authorisation.

By rebooting the switch

Why it fails: Rebooting only restarts the switch; authorisation requires the FortiGate to discover and approve it via the Security Fabric, typically by enabling fabric management on the switch's admin port. Rebooting is tempting when a switch is unresponsive, but it never establishes the management trust relationship.

Service Object

Why it fails: A Service Object defines the TCP or UDP port a policy matches, so it cannot parse HTTP request framing to detect smuggling. It is tempting because services scope traffic handling, but protocol-specific inspection belongs to a Signature or HTTP protocol constraint, not port definition.

Virtual Server

Why it fails: A Virtual Server maps a listening IP and port to backend server pools; it performs no HTTP parsing, so request smuggling evades it. It is tempting because virtual servers front web traffic, but the inspection itself is done by the FortiWeb signature or HTTP protocol constraint applied in the policy.

Server Pool

Why it fails: A Server Pool only lists backend real servers and health checks; it never inspects client HTTP requests for smuggling. It is tempting because pools are central to web traffic distribution, but protocol-specific attack detection is performed by signatures or HTTP protocol constraints, not by the pool definition.

SAML External IDP

Why it fails: This acts as an identity provider, not the MFA mechanism itself.

OpenLDAP

Why it fails: OpenLDAP does not handle MFA token generation natively.

Local Database

Why it fails: Local accounts need an external MFA provider or FortiToken.

Persistence Sharing

Why it fails: Persistence sharing synchronises client-to-server session affinity records, not the session table itself. It is tempting because both concern sessions across cluster members, so it would be correct when you need a client's persistence entry honoured after failover to another FortiWeb.

State Replication

Why it fails: State replication synchronises TCP session state so established connections survive failover; it does not share the FortiWeb session table. It is tempting because the names overlap, so it would be the right answer when the requirement is preserving active connections rather than sharing session records.

Configuration Sync

Why it fails: Configuration sync replicates FortiWeb settings and policies between cluster members, not runtime session entries. It is tempting because cluster members must share configuration, so it would be correct when you need consistent WAF policies, server pools and profiles deployed across all nodes.

HTTP compression

Why it fails: HTTP compression shrinks response payloads between FortiADC and clients; it never rewrites the source address the backend sees. With SSL offloading, FortiADC terminates TLS and proxies the connection, so backends receive the ADC's IP unless a client-IP preservation feature is configured. Compression is genuinely useful for reducing bandwidth on text-heavy web traffic.

SSL session resumption

Why it fails: SSL session resumption caches TLS session state so returning clients skip a full handshake, cutting latency and CPU. It operates entirely within the TLS layer and does not alter the source address of the proxied TCP connection, so backends still see FortiADC's IP after offloading. Resumption is the right choice when reducing handshake overhead matters.

Source IP NAT

Why it fails: Source IP NAT rewrites the client's address to FortiADC's own before forwarding, which is the opposite of preservation — backends then log the ADC, breaking IP-based policy. It is tempting because NAT is a familiar address-translation tool, but it is intended for hiding internal addresses or enabling routing, not retaining the original client IP.

SNMP Traps

Why it fails: SNMP is for management, not user data.

ICMP

Why it fails: ICMP is for network connectivity diagnostics.

HTTP Proxy

Why it fails: HTTP Proxy forwards web requests and cannot ingest identity data, so FortiAuthenticator gains no user attributes through it. It tempts because proxies do relay authentication traffic, and a reverse proxy deployment in front of FortiAuthenticator is legitimate — but that concerns access to the appliance, not receiving user information from an external source.

VLAN tagging

Why it fails: User group information is shared via the fabric connector using FSSO and LDAP, not VLAN tagging, which only segments Layer 2 traffic. VLAN tagging is tempting because it groups traffic logically, but it carries no user-identity data between fabric devices.

DHCP option 43

Why it fails: DHCP option 43 delivers vendor-specific information such as controller addresses, not user group membership. It is tempting because it is used for device provisioning, but sharing user groups in the Security Fabric relies on FSSO and LDAP, not DHCP options.

DNS records

Why it fails: DNS records resolve names and services; they carry no user group membership data between fabric devices. DNS is tempting because it is a common directory-adjacent service, but the Security Fabric shares user groups through FSSO and LDAP instead.

RADIUS port

Why it fails: The RADIUS port need not match: FortiGate sends to the port FortiAuthenticator listens on, and the two sides can legitimately differ in configuration. It is tempting because ports feel like a pairing requirement, yet the actual shared values are the pre-shared secret and the authentication method. Ports are configured per side, not synchronised.

Device MAC address

Why it fails: The device MAC address plays no part in RADIUS authentication; it is a layer-2 identifier irrelevant to the UDP exchange between FortiGate and FortiAuthenticator. It is tempting because MAC-based access control exists elsewhere, but RADIUS matches on the shared secret and authentication method, not hardware addresses.

System hostname

Why it fails: The system hostname is purely local labelling and is never transmitted as a matching criterion in RADIUS authentication. It is tempting because hostnames identify devices in many management contexts, yet FortiGate and FortiAuthenticator authenticate using the shared secret and authentication method, so hostnames may differ freely without affecting the exchange.

Encrypt

Why it fails: Encrypt is not a FortiWeb WAF policy action; actions determine how matched traffic is handled, such as alert, block, bypass or monitor. It is tempting because encryption relates to protecting data, so it would be relevant when configuring HTTPS inspection or TLS offloading rather than a WAF policy action.

Bypass

Why it fails: Bypass is typically a global bypass rule, not a per-policy action.

Home address

Why it fails: A home address is optional directory metadata, not required to create a user; FortiAuthenticator needs a username plus authentication credentials such as a password or token. It is tempting because LDAP-synchronised users often carry address attributes, but local user creation succeeds without any address field.

Operating System Version

Why it fails: Operating system version is endpoint inventory data, irrelevant to defining a FortiAuthenticator user, which requires only identity and authentication attributes. It is tempting because FortiClient and Fabric telemetry report OS details, but FortiAuthenticator stores no OS field when creating a local user.

Keyboard layout mismatch

Why it fails: Keyboard layout affects only local console typing, not the fabric tunnel between FortiGate and FortiAnalyzer. It tempts because console access problems are often blamed on input settings, but Security Fabric failures stem from registration, certificates, or connectivity — not how keys are mapped.

Outdated browser

Why it fails: Browser version is irrelevant because the FortiGate-to-FortiAnalyzer fabric link is a device-to-device tunnel, not a GUI session. It tempts since outdated browsers break web admin pages, but fabric registration and heartbeats use FortiGate's own fabric protocol, independent of any browser.

High CPU on FortiGate

Why it fails: High CPU delays processing but does not by itself break fabric registration; the connection still forms once resources free up. It tempts because overloaded devices do drop sessions, yet the common causes are mismatched serial numbers, disabled fabric settings, or blocked ports.

Inspection Profile

Why it fails: An inspection profile holds the attack signatures and protection rules applied to traffic, not the server definition. It is tempting because profiles are where WAF behaviour is configured, but the server or virtual host being protected is declared separately, so the profile cannot identify the target.

Server Object

Why it fails: Server objects are backend definitions, not the policy itself.

Virtual Host Profile

Why it fails: FortiWeb has no object named Virtual Host Profile; virtual hosts are configured as server objects or policies, while profiles hold protection settings. It is tempting because the term echoes the virtual-host concept in the question, but no such object exists to bind a backend server.

A list of all client machine MAC addresses

Why it fails: MAC addresses are layer-2 identifiers irrelevant to AD identity integration, which relies on LDAP or RADIUS lookups of user accounts. It is tempting because device-based policies exist, but FortiAuthenticator binds identities to users and groups, not to client hardware addresses.

The AD database file export

Why it fails: FortiAuthenticator queries AD over LDAP in real time; exporting the AD database file is neither required nor supported for identity integration. It is tempting because offline directory data sounds useful, but live LDAP bind credentials and a reachable domain controller are what the integration needs.

Fabric SSO

Why it fails: Fabric SSO allows single sign-on authentication across Fabric devices for administrative access, not for sharing routing and object definitions. It streamlines user login but does not synchronize network objects or routes. Therefore, it does not meet the requirement of sharing dynamic routing information among FortiGates.

Fabric Connector

Why it fails: Fabric Connector is used to integrate third-party devices or virtual machines into the Security Fabric, not to share dynamic routing and object definitions among FortiGates. It allows external devices to be recognized and monitored by the Fabric, but it does not provide the synchronization of routes and address objects that you need here.

FortiManager integration

Why it fails: FortiManager integration centralizes management and policy deployment, but it does not provide real-time synchronization of dynamic routing and objects directly among FortiGates in the Security Fabric. While FortiManager can push configurations, the Fabric's native synchronization feature is more immediate and designed for dynamic environments.

To synchronize user databases

Why it fails: Automation Stitch executes configured actions across Fabric devices in response to triggers, not directory synchronisation. User database synchronisation is handled by Fabric connectors such as LDAP or FSSO agents. It is tempting because both features span multiple devices within the Security Fabric.

To scan for vulnerabilities

Why it fails: Vulnerability scanning is performed by FortiGate's built-in IPS signatures and dedicated scanners, not by Automation Stitch. Stitch orchestrates response actions across Fabric devices when a trigger fires. It is tempting because automated remediation often follows vulnerability detection, but detection and orchestration are separate functions.

To load balance traffic

Why it fails: Traffic load balancing is handled by virtual servers and SD-WAN rules on the FortiGate, not by Automation Stitch. Stitch coordinates automated actions across Fabric devices in response to events. It is tempting because both involve distributing work, but the mechanisms and purposes differ entirely.

Content Routing Policy

Why it fails: Content Routing Policy matches requests to virtual servers and pools based on HTTP content, not cryptographic processing. It tempts because it governs how HTTPS traffic is directed, but SSL offload requires a profile defining certificate and cipher handling on the virtual server.

Server SSL Profile

Why it fails: A Server SSL Profile defines encryption parameters for FortiADC's connections to backend real servers, not for decrypting client-side traffic. It tempts because it is an SSL object, but offloading client SSL requires a Client SSL Profile bound to the virtual server.

Layer 7 Persistence Rule

Why it fails: Layer 7 Persistence Rule maintains session affinity by inspecting HTTP headers or cookies, which is irrelevant to cryptographic processing. It tempts because it operates at the application layer where HTTPS traffic is handled, but persistence governs server selection, not SSL termination.

Transparent mode

Why it fails: This refers to network deployment, not policy inspection behavior.

Learning mode

Why it fails: Learning mode builds a behavioural baseline of normal traffic and never blocks SQL injection, so the enforcement requirement fails. It is tempting because learning is the correct initial phase when deploying a new FortiWeb policy, letting you profile legitimate requests before switching to protection.

Detection mode

Why it fails: Detection mode only raises alerts on SQL injection without dropping the request, so malicious traffic still reaches the application and the blocking requirement is unmet. It is tempting because detection suits baselining and tuning a new policy before enforcement, where observing false positives matters more than prevention.

Install a web certificate on the FortiGate

Why it fails: RADIUS authentication between FortiGate and FortiAuthenticator uses a shared secret and server IP; no web certificate is exchanged for that. Certificates belong to EAP-TLS or LDAPS scenarios, where the FortiGate validates the FortiAuthenticator's identity during a TLS handshake, which is a different integration.

Enable LDAP on the FortiAuthenticator

Why it fails: LDAP governs directory lookups, not RADIUS authentication between FortiAuthenticator and FortiGate, so enabling it does not satisfy the integration steps. It is tempting because FortiAuthenticator commonly uses LDAP as a backend user store, but the required steps involve configuring the RADIUS client and shared secret instead.

Configure SAML on the FortiGate

Why it fails: SAML governs federated web single sign-on, not RADIUS authentication between FortiAuthenticator and FortiGate. It is tempting because FortiAuthenticator supports SAML IdP roles, but that suits browser-based SSO; RADIUS integration instead needs a RADIUS client entry on FortiAuthenticator and a matching RADIUS server object on the FortiGate.