FCP-ZCS-AD-7-4 Sample Questions & Answers

By default, Azure VMs are not allowed to forward IP packets that are not destined for them. To function as a router or firewall, the FortiGate VM requires IP forwarding to be explicitly enabled on its Azure NICs. This is an Azure-level setting. Secondly, even if Azure allows the forwarding, the FortiGate itself, being a firewall, will block traffic by default. A firewall policy must be created on the FortiGate to explicitly allow traffic to pass from one interface to another. NSGs control traffic to/from the NICs, but don't control the forwarding capability within the VM itself.

This statement is false. The Pay-As-You-Go (PAYG) licensing model integrates the FortiGate software license cost directly into the Azure bill. The VM comes pre-licensed, and no manual license upload is required. This model is designed for flexibility and on-demand usage. The Bring-Your-Own-License (BYOL) model is the one that requires purchasing a license from Fortinet separately and uploading the license file to the VM.

Azure Route Server is specifically designed for this purpose. It acts as a BGP route reflector, allowing BGP-enabled devices (like on-premises gateways and FortiGate NVAs) to peer with it and exchange routing information dynamically. This simplifies the management of routing in the virtual network, as it injects the learned routes into the VNet's routing table, eliminating the need for extensive manual UDR management. Virtual WAN is a broader hub-and-spoke connectivity solution. Load Balancer distributes traffic, it doesn't participate in BGP route exchange. Traffic Manager is a DNS-based load balancer.

The Local Network Gateway is the Azure resource object that represents the on-premises side of the VPN connection. It holds the configuration details of the remote (on-premises) network, including the public IP address of the VPN device and the address prefixes of the on-premises network that Azure needs to route to. The Virtual Network Gateway represents the Azure side of the connection. The Connection is the resource that links the Virtual Network Gateway and the Local Network Gateway together.

For the SDN connector to function, the identity it uses (whether a Managed Identity or Service Principal) must have sufficient permissions to read resource information from the Azure API. The Reader role is the minimum required permission. If the Managed Identity does not have this role assigned at a scope that includes the VMs (such as the VNet, Resource Group, or Subscription), the FortiGate will be unable to query the Azure API for VMs and their tags, resulting in an empty dynamic address object. Tags in Azure are generally case-insensitive, but the most fundamental issue is permissions. The object should populate regardless of traffic. A reboot is not typically required.

An Azure Availability Set is the feature designed to provide resiliency against hardware failures within a datacenter. It distributes VMs across different fault domains (racks with independent power and network) and update domains (groups of VMs that can be rebooted at the same time). Placing the two HA FortiGate VMs in the same Availability Set ensures they will be on different fault domains, protecting the cluster from a single rack failure. A VM Scale Set is for scaling, not just HA for a pair. Resource Groups are for logical organization. A Proximity Placement Group does the opposite; it co-locates VMs for low latency.

The standard mechanism in Azure for overriding the default system routing is to use User Defined Routes (UDRs). By creating a route table with a route for 0.0.0.0/0 (representing all internet traffic) and setting the next-hop type to 'VirtualAppliance' with the private IP of the hub FortiGate, all outbound traffic from the associated spoke subnets will be forced through the firewall for inspection. While enabling gateway transit is necessary for some peering scenarios, it doesn't by itself force traffic to a firewall NVA. NSG rules and Azure policies can block traffic but do not redirect it.

FortiWeb's core function is to be a Web Application Firewall (WAF). It is deployed as a reverse proxy that sits in front of web applications, inspecting incoming HTTP/HTTPS traffic for threats like those mentioned in the OWASP Top 10 (SQLi, XSS, etc.). While it has Layer 4 capabilities, its primary value is at Layer 7. It can perform SSL offloading, but its purpose is not encrypting backend traffic. It is not a DNS load balancer.

Azure Virtual WAN is a managed networking service that provides a global transit backbone for large-scale site-to-site, point-to-site, and ExpressRoute connectivity. Its key benefits include providing a unified hub for any-to-any connectivity (transitive routing between all connected sites) and centralizing management, which simplifies the overall network topology. It does not automatically configure on-premises devices, nor does it have built-in WAF capabilities.

The diagnose sys ha history read command displays the HA event history log. This log contains detailed information about HA state changes, failover triggers, synchronization status, and other events related to the HA cluster's operation. It is the primary tool for post-mortem analysis of a failover event. get system ha status shows the current real-time status but not the historical events. diagnose sys top shows real-time process utilization, and get router info routing-table displays the routing table; neither is for diagnosing HA event history.