CCNA Central Management Questions

CLI Templates store reusable sets of FortiGate CLI commands that FortiManager can push to many managed devices at once, ensuring consistent configuration across the estate. This satisfies the requirement to apply commands to multiple devices efficiently.

Selecting the target device identifies which gateway or cluster the policy package will be installed onto, since installation is scoped per managed object. Without this selection the workflow cannot proceed, satisfying the requirement to define where the policy is applied.

Workspace Mode in FortiManager allows administrators to make configuration changes in a private workspace without affecting the live configuration. Changes are saved in the workspace and must be committed and then installed to devices. This supports change control because multiple administrators can work independently, and changes can be reviewed before being applied. It provides a staging area for approval workflows.

When workspace mode is enabled, changes are staged in a workspace and not saved to the main database until committed. Committing saves the changes to the FortiManager database. After that, the administrator must install the policy package to push the updated configuration to the FortiGate. This two-step process ensures the change is both saved and deployed.

SD-WAN zones group multiple WAN interfaces into a single logical object, and FortiManager assigns members to that zone rather than to individual interfaces. This satisfies the stem's requirement for grouping WAN interfaces before SD-WAN member assignment, letting you reference one zone across policies and health checks.

Objects created within an ADOM are local to that ADOM and cannot be seen or used by other ADOMs. This provides the necessary isolation. The administrator can create firewall addresses and services in the specific ADOM, and they will be available only to devices within that ADOM. This is the most straightforward and efficient method to achieve the requirement.

Pushing installs the FortiManager policy package onto the managed FortiGate, replacing its local policy configuration with the FortiManager version. The device's policy set is therefore overwritten, ensuring the centralised configuration becomes authoritative and consistent across managed devices.

The Install Wizard allows administrators to select specific devices or groups for installation. By choosing only the devices that require the policy changes, the administrator avoids unnecessary installations to other devices, reducing network load and processing time. This targeted approach is a best practice for efficient policy deployment in large environments.

Firmware Management centralises firmware deployment across managed FortiGate devices, letting administrators stage images, schedule upgrades by device group, and track version compliance from one console. This directly satisfies the stem's requirement for centralised firmware control across multiple devices, rather than per-device manual uploads.

Custom reports are user-defined, letting you select specific datasets, filters and layout in FortiAnalyzer, so they satisfy the stem's requirement for a generatable report type. Unlike fixed templates, they are built from the Log View and Report Wizard, confirming FortiAnalyzer supports them as a distinct report category.

FortiGate-FortiManager (FGFM) is the proprietary protocol used for communication between FortiManager and managed FortiGates. It operates over TCP port 541 and provides secure, reliable transport for configuration, monitoring, and management tasks. FGFM is designed specifically for this purpose and is the default protocol for device registration and management.

Selecting ADOM version 7.0 ensures that the ADOM can only manage FortiGate devices running FortiOS 7.0. This version setting determines the available features and object schemas, and it restricts device compatibility to that specific firmware version. It is the correct choice to meet the requirement of managing only FortiOS 7.0 devices.

An ADOM is a logical container that separates management configurations, including devices, policies, and objects. Devices in the same ADOM can share policy packages and objects, while devices in different ADOMs are isolated. Creating an ADOM for each group of devices that share the same security policies is the correct approach to achieve logical separation and efficient management.

FortiManager treats a FortiGate HA cluster as a single managed device. When a policy package is installed to the cluster, FortiManager communicates with the primary unit, which then synchronizes the configuration to all secondary members. This ensures consistency across the cluster without manual intervention.

Normal mode lets the FortiGate be fully managed by FortiManager, which pushes configuration and policy packages to it. The alternative, backup mode, restricts FortiManager to read-only retrieval, so it cannot satisfy the requirement to manage configuration and policies.

Objects created in the Global Database are inherited by every ADOM, so a mail server or IP range defined once is available to all managed FortiGates without duplication. This directly satisfies the cross-ADOM sharing requirement, unlike per-ADOM objects, which remain isolated within their own administrative domain.

When creating an ADOM, you must specify the firmware version of the managed devices. This determines the available features and object models. For a new branch office with FortiGates running a specific firmware, you must select the correct version to ensure compatibility. This is a required step because FortiManager uses the version to format configuration and policies appropriately for the devices.

A Device Group with a shared Policy Package lets FortiManager install one consistent configuration to all 50 FortiGates in a single coordinated push, avoiding per-device drift and reducing the window of inconsistent policy states that sequential individual installs would create.

Provisioning Templates in FortiManager are used to automatically apply a set of configuration settings to managed devices. They can include system settings, administrative accounts, and other baseline configurations. When a device is added to FortiManager, a provisioning template can be assigned to it, ensuring consistent base configuration. This is the correct feature for automating initial device setup.

Before upgrading, the firmware image must be available on FortiManager. The 'Import Firmware' option under Device Manager > Firmware allows uploading the image. This is a prerequisite for any upgrade, including staged rollouts. Without the image, the upgrade wizard cannot proceed.

Creating administrator accounts with strong passwords and assigning appropriate profiles ensures that only authorized personnel can access FortiManager and that they have the necessary permissions. This is a fundamental step for access control and is required to meet the scenario's goal of restricting access to authorized users.

Install Preview generates the exact CLI script that FortiManager will push to the managed FortiGate during installation, including the sequence of config commands. This lets the administrator validate syntax, ordering, and object references before committing the change, which is precisely the requested pre-install validation step in this scenario.

FortiManager's firmware management allows administrators to schedule automatic download of firmware images from FortiGuard. By configuring a schedule, FortiManager can retrieve new firmware versions as they become available, storing them in the repository for later installation. This reduces manual effort and ensures that firmware is ready when needed, while still allowing controlled installation.

Firmware Management in Device Manager pushes signed images to managed FortiGates over the FGFM tunnel, letting the administrator schedule upgrades across all 100 devices and revert to the previous firmware if a unit fails, satisfying the secure rollback requirement.

FortiManager is designed to handle FortiGate reboots gracefully. After the FortiGate reboots, it will re-establish the management tunnel with FortiManager. FortiManager will then retrieve the current configuration and verify that the installed changes are present. This automatic reconnection and verification ensure that the management link is restored without manual intervention.

Provisioning templates in FortiManager allow administrators to define a set of configurations, including security profiles and firewall objects, that are automatically applied to devices when they are added or when the template is assigned. This ensures consistent configuration across new devices without manual intervention.

Role-based administration in FortiManager allows creating administrator accounts with specific permissions. By assigning an administrator profile that grants read-write access only to the policy package of the specific FortiGate, the regional team can manage firewall policies without access to system settings or other devices. This meets the delegation requirement while retaining overall control.

Provisioning Templates in FortiManager allow administrators to define a set of configuration settings that can be automatically applied to a FortiGate when it is added or when the template is assigned. This includes interface settings, static routes, and administrative accounts. This feature is designed for automated initial configuration, making it the correct choice.

The Add Device wizard in FortiManager is the correct starting point. It allows the administrator to specify the device's IP address, credentials, and the ADOM to which it should belong. Once added, the device is managed and its policies can be viewed and modified. This is the essential first step for integrating a FortiGate into FortiManager.

When adding an HA cluster to FortiManager, you add the cluster using the primary unit's serial number. FortiManager recognizes the HA configuration and manages the cluster as a single entity. When installing policies, FortiManager pushes the configuration to the primary, which then synchronizes to the secondary units. This ensures both units receive the configuration.

Dynamic objects in FortiManager allow you to define objects whose values are resolved at install time based on the FortiGate's own configuration. For example, you can create a dynamic object that represents the WAN interface IP address, and FortiManager will automatically substitute the correct IP for each device when the policy is installed. This ensures that the same policy can be used across devices with different WAN IPs without manual per-device edits.

Importing the configuration pulls the FortiGate's running configuration into FortiManager, creating the device database and policy package baseline. This is the standard step after adding a device so that FortiManager reflects the current state and can manage it. Once imported, subsequent changes can be made centrally and installed back to the device.

FortiManager processes each device in the install scope independently. Online FortiGates receive the compiled configuration and move to a synchronized state, while the unreachable device fails or is skipped and remains flagged as out of sync. When it reconnects, the administrator can install again to bring it current.

In FortiManager, managed FortiGate clusters are treated as a single device. Firewall policies are installed on the cluster as a whole, and the cluster synchronizes the configuration to all units. There is no mechanism to install a policy only on the primary unit. The primary unit is responsible for synchronizing configuration to secondary units. Therefore, it is not possible to target a policy to only the primary unit; the policy will be present on all units.

Administrator Profiles bundle granular permissions, including read-only access to logs and reports, and are assigned to the junior member's account. This satisfies the stem's least-privilege requirement, restricting the user to viewing without granting configuration or deployment rights.

The Global Database in FortiManager is designed to hold objects that can be shared across multiple ADOMs. By creating objects there, they become available for assignment to any ADOM. This is the first step to enable cross-ADOM object sharing. Without this, objects are confined to a single ADOM and cannot be used elsewhere.

An ADOM partitions FortiManager into independent administrative domains, each holding its own devices, policies and objects. This satisfies the delegated administration constraint: administrators gain scoped access to only their assigned ADOM, while policy packages and objects remain isolated from other domains.

This is correct because placing each tenant's devices in a separate ADOM is the fundamental way to achieve isolation. ADOMs are logical containers that separate devices, policies, and objects. By assigning the tenant's administrative user to only their ADOM, they cannot see or modify other ADOMs, ensuring tenant isolation.

Configuration revision in FortiManager automatically saves a copy of the device configuration each time it is changed and installed. It allows administrators to view, compare, and revert to previous revisions. Enabling this feature ensures daily backups are taken when changes occur, and provides a rollback mechanism.

The Install Wizard in FortiManager pushes the current configuration from FortiManager to the selected managed devices. It compares the FortiManager configuration with the device configuration and installs the changes, ensuring all devices are synchronized. This is the intended method for distributing configuration without logging into each FortiGate individually.

In Advanced ADOM mode, FortiManager supports ADOM assignment rules that can automatically assign devices to specific ADOMs based on criteria such as model and firmware version. This allows for automated placement of new FortiGates into the correct ADOM without manual intervention, meeting the scenario's requirement.

Provisioning Templates let you define a device-level model, then assign it to a FortiGate serial number before the unit ever contacts FortiManager. When the FortiGate first registers, FortiManager automatically pushes the pre-staged configuration, satisfying the requirement to pre-configure devices prior to network connection.

The 'Retrieve Config' action pulls the current configuration from the managed FortiGate into FortiManager, updating the device-level database. This allows the administrator to see the actual running configuration and compare it with the policy package. It is essential for identifying configuration drift and deciding whether to import changes or overwrite them.

An ADOM (Administrative Domain) is the primary construct in FortiManager for isolating devices, policies, and objects. Each ADOM has its own database, and devices within an ADOM cannot see or affect devices in another ADOM. This makes ADOMs ideal for multi-tenant environments where complete separation is required.

This is correct because importing the configuration allows FortiManager to retrieve the current device settings, including the CLI changes. The administrator can then review the differences, decide which changes to keep, and update the policy package accordingly. This ensures that FortiManager and the FortiGate are synchronized without losing valid local modifications.

The Diff feature compares the FortiManager policy database against the managed device's running configuration, exposing the exact object or setting causing the conflict. This directly identifies the root cause of the policy installation failure rather than merely reporting that a mismatch exists.

In FortiManager, changes to firewall policies are made in the policy package. To apply these changes to the managed FortiGate, the administrator must install the policy package. This process pushes the updated configuration to the device. Until the installation is performed, the FortiGate continues to use the previously installed policy set. This is the required step to activate the changes.

This is correct because FortiManager administrative profiles allow granular control over permissions. By creating a custom profile with read-write access only to Firewall Objects and Policy & Objects, and assigning the user to the specific ADOM, the subordinate can manage addresses and policies without accessing other ADOMs or system settings. This follows the principle of least privilege.

Retrieving the configuration from the FortiGate pulls the current configuration from the device into FortiManager, updating FortiManager's database to match the device. This resolves the discrepancy by ensuring FortiManager reflects the actual configuration on the FortiGate, which is exactly what the administrator needs.

Importing a standalone FortiGate creates a new Policy Package containing its existing firewall policies, preserving their order and object references. This satisfies the migration constraint: the device's configuration is absorbed into FortiManager's centralised policy model rather than discarded, so the administrator can subsequently manage and push those policies from FortiManager.

The FortiGate must be configured with the FortiManager's IP address or hostname under Central Management. This tells the FortiGate where to send registration requests and from where to accept management commands. This setting is essential for the initial connection and ongoing communication between the FortiGate and FortiManager.

Provisioning Templates in FortiManager allow administrators to define and push standardized configurations to managed FortiGates. They can include system settings like DNS, NTP, and other administrative parameters. When a new device is added, the template can be automatically applied, ensuring consistent base configuration. This is the primary method for automating initial device setup and meeting the requirement.

ADOMs are administrative domains that logically separate devices, policies, and objects. By placing each HA cluster in its own ADOM, the administrator ensures that policies and objects are isolated, and installation targets only the devices within that ADOM. This prevents accidental policy pushes to the other cluster and maintains independence, which is exactly what the scenario requires.

FortiManager's Global Object Database allows administrators to create and manage objects that can be shared across multiple ADOMs. When an object is created in the global database, it can be referenced in policies within any ADOM that has been configured to use global objects. This eliminates the need to duplicate objects in each ADOM, ensuring consistency and reducing administrative overhead.

By default, the FortiGate initiates the connection to FortiManager using the FortiManager protocol (FGFM) on TCP port 541. This outbound connection allows the FortiGate to register with FortiManager even if the FortiGate is behind NAT, because no inbound access to the FortiGate is required. This is the standard method for adding devices behind NAT.

Log forwarding must be enabled and correctly configured on the FortiGate itself before logs can reach FortiManager. Verifying that local configuration confirms whether the device is actually sending logs, isolating the fault at its source.

Administrator profiles in FortiManager define the permissions for administrative users, specifying which areas they can access and what actions they can perform. By assigning profiles, you can restrict users to read-only or limit them to specific ADOMs. This is the primary method to enforce role-based access control and ensure only authorized personnel can modify policies.

Source and destination criteria define which traffic the SD-WAN rule matches, using addresses, users, services and applications. Without these match objects the rule cannot identify flows to steer, so they are fundamental configurable fields when building an SD-WAN rule in FortiManager.

Device Manager displays managed FortiGate devices with their connection status to FortiManager, letting the administrator confirm whether the tunnel is up. This directly satisfies the requirement to verify the FortiGate-to-FortiManager link without inspecting logs elsewhere.

Locking policies for editing demands Workspace Mode because FortiManager must isolate each administrator's uncommitted changes in a private workspace before committing them to the shared ADOM database. Without it, concurrent edits would overwrite one another, so the lock workflow depends on that per-session staging layer.

A policy package in FortiManager is a container for firewall policies, objects, and other settings that can be assigned to one or more managed FortiGates. By creating a dedicated policy package, you can include the policy referencing the global address object and then assign that package only to the specific FortiGates you want. This ensures the policy is installed only on those devices, while other devices remain unaffected. This is the standard method for scoping policy deployment in FortiManager.

The Read_Only administrative profile in FortiManager allows users to view configurations, policies, and device status without the ability to make any modifications. This aligns perfectly with the requirement for a user who should only monitor and not change anything.

A normalized interface is a logical placeholder in FortiManager that maps to a specific physical interface on each managed FortiGate through per-device mapping. Defining the policy against the normalized interface lets FortiManager substitute port1 on one device and wan1 on another during install, which is exactly the cross-device abstraction this scenario requires.

Service objects define protocols and port ranges referenced by firewall policies, and FortiManager installs them with the package so rules resolve correctly on the managed FortiGate. They satisfy the package contents requirement alongside address objects and policies.

The installation preview shows the exact commands that will be sent to the device, allowing the administrator to verify the changes. This helps identify unintended modifications and ensures that only the desired changes are applied. It is a crucial step to avoid downtime and misconfigurations.

Configuration drift occurs when changes are made directly on the FortiGate device, either through CLI or GUI, without updating FortiManager. FortiManager is the central management point, and direct changes can cause the device configuration to differ from the policy package. To prevent drift, all changes should be made through FortiManager. The other options do not typically cause drift.

Administrative profiles in FortiManager define granular permissions, including which ADOMs a user can access and what actions they can perform within those ADOMs. By creating a profile that grants read-write access to the specific ADOM and includes permissions for policy editing and installation, while omitting ADOM-level configuration rights, the administrator can delegate exactly the required capabilities without over-provisioning access.

Provisioning Templates in FortiManager allow administrators to define a model device with pre-configured settings such as management IP, admin credentials, and firewall policies. This is ideal for zero-touch provisioning of remote devices that lack direct internet access, as the configuration can be prepared in advance and installed once the device connects to the manager.

The 'Replace Object' feature in FortiManager allows administrators to replace an object (such as a security profile) with another object throughout the policy package. This efficiently updates all policies that reference the old profile, ensuring consistency and saving time. It is the intended tool for bulk object replacement in policy packages.

This is correct because the Installation Preview shows the CLI commands that will be applied to the FortiGate, including any object creation. If a duplicate object exists, the preview will display the conflicting command, allowing the administrator to pinpoint the issue. This is the most direct way to diagnose installation errors related to object conflicts.

Policy Check is a FortiManager feature that validates firewall policies against a set of predefined or custom rules to ensure compliance and best practices. It can be run manually or automatically before installation. By configuring Policy Check, the administrator can enforce corporate security standards and prevent non-compliant policies from being deployed, thus meeting the requirement for automatic validation.

FortiGates can be configured with a single FortiManager IP or FQDN. If they are set to the primary's IP only, after failover the secondary takes over the primary's IP, so connectivity should be maintained if the IP is virtual. However, if the FortiGates are configured with the physical IP of the primary and the secondary uses a different IP, they will not reconnect. The typical HA setup uses a virtual IP that moves, but misconfiguration can cause this.

Policy packages are ADOM-specific. A policy package created in one ADOM cannot be installed on a device in another ADOM. Therefore, the FortiGate must reside in the same ADOM as the policy package. This is a fundamental requirement for installation; otherwise, the package will not be available for that device.

Compression reduces the on-disk footprint of each log record before it is written, so higher compression ratios store more events per gigabyte. This directly governs how efficiently FortiAnalyzer and FortiManager consume available storage, making it a primary factor in log storage efficiency.

Provisioning Templates in FortiManager allow administrators to define system-level settings, including NTP servers, and apply them to multiple devices. By creating a system template with the required NTP servers and assigning it to all devices in the ADOM, the administrator ensures consistent configuration across all FortiGates with minimal effort. This is the intended use case for provisioning templates.