NSE4 System and Network Administration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use the default 'admin' account for all administrators

  Why it's wrong here

  Using the default 'admin' account is risky because the username is publicly known, enabling attackers to focus solely on password cracking. It also lacks individual accountability since multiple administrators share one identity, making audits and per-user MFA impossible. Fortinet recommends creating unique named administrators with granular permissions and two-factor authentication.

• ✓

  Restrict administrative access to trusted hosts

  Why this is correct

  Restricting administrative access to trusted hosts limits which source IP addresses can initiate management sessions to the FortiGate. By configuring an allowlist of management station IPs on each admin user or the administrative interface, you drastically reduce the attack surface and block brute-force attempts from the internet. This is a fundamental, highly effective hardening measure.

• ✓

  Change the default administrative port

  Why this is correct

  Changing the default administrative port (e.g., 443/TCP for HTTPS, 22/TCP for SSH) hides the management interface from automated scanners that probe common ports. While this is security-by-obscurity and not a primary defense, it significantly reduces opportunistic scanning noise and forces attackers to actively discover the service. It should always accompany strong authentication and host restrictions.

• ✗

  Set a simple password for ease of use

  Why it's wrong here

  Setting a simple password for ease of use directly undermines security because trivial passwords are easily guessed or cracked with dictionary attacks. FortiOS enforces password complexity and length policies; a weak password can quickly lead to full device compromise. Always use long, complex passphrases and consider MFA for administrative accounts.

• ✗

  Disable both HTTPS and HTTP administrative access

  Why it's wrong here

  Disabling both HTTPS and HTTP administrative access would eliminate web-based management entirely, leaving only CLI over SSH or serial connection, which is an overly drastic step that reduces usability and operational flexibility. More importantly, HTTPS is a secure encrypted channel when properly configured with strong ciphers; the risk comes from weak authentication, not the protocol itself. The recommended approach is to keep HTTPS, enforce trusted hosts, and disable insecure HTTP instead.

Go deeper

Related to this question