FCP_ZCS_AD-7-4 Practice Questions

For the virtual machines (VMs) in the 10.0.1.0/26 subnet to send their internet-bound traffic through the FortiGate VM, their default routing behavior must be changed. In Microsoft Azure, this is achieved by creating a User-Defined Route (UDR) table. This table must contain a route for destination 0.0.0.0/0 with the next-hop type set to "Virtual appliance" and the next-hop address set to the FortiGate's internal private IP (10.0.1.4). This UDR table is then associated with the internal subnet, effectively changing the default gateway for all VMs within it to be the FortiGate. The "IP forwarding" setting shown is a necessary prerequisite on the FortiGate NIC, but the UDR is what enables the traffic flow.

A: The internal-facing NIC of a firewall does not require a public IP address. The external-facing NIC (not shown) would handle public-facing traffic and typically has a public IP. B: This statement describes the goal, but it is not true by default. Without the routing change described in option C, the VMs will use Azure's default internet gateway. D: The parameters shown are correct for a Network Virtual Appliance (NVA). "IP forwarding" must be enabled for the FortiGate to route traffic it receives that is not destined for itself.

1. Microsoft Azure Documentation, Virtual network traffic routing: "You can create custom routes,

or user-defined routes (UDRs) in Azure to override Azure's default routing... You can specify a

next hop of Virtual appliance to route traffic to a network virtual appliance (NVA)."

URL: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview

2. Microsoft Azure Documentation, Route network traffic with a route table using the Azure portal:

"For the virtual appliance to be able to forward traffic, the IP forwarding feature must be enabled

for the network interface attached to the VM." This confirms the setting in the exhibit is correct,

making option D incorrect.

URL: https://learn.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal#cre

ate-a-route-table

3. Fortinet Document Library, FortiGate-VM on Azure deployment guide 7.4.0, Section:

"Configuring a user-defined route to route all traffic through the FortiGate": "To route traffic from

the protected subnet through the FortiGate-VM, you must create a routing table with a UDR... Set

Next hop type to Virtual appliance and Next hop address to the FortiGate-VM's private IP

address."

URL: https://docs.fortinet.com/document/fortigate-public-cloud/7.4.0/azure-administration-guide/5

23940/configuring-a-user-defined-route-to-route-all-traffic-through-the-fortigate

In Azure Virtual WAN, enabling branch-to-branch connectivity lets every site build only a single

VPN/ExpressRoute link to its regional Virtual WAN hub. Azure then automatically provides

any-to-any traffic flow across Microsoft’s backbone, so additional branches can be on-boarded

without creating new peerings or tunnels between existing sites. This managed, cloud-transit

model therefore chiefly distinguishes itself by giving very large and rapidly growing branch

footprints the ability to scale simply and quickly.

A. Concerns hub redundancy; branch-to-branch is about inter-site scale, not multiple hub links.

B. Centralized security (e.g., Azure Firewall) is a hub feature, not the defining trait of

branch-to-branch.

C. Architecture is simplified, but reliance on hubs is not reduced—traffic still transits the hub, so

statement is inaccurate.

1. Microsoft Learn – “About Azure Virtual WAN,” section “Branch-to-branch traffic flows”

https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-about

2. Microsoft Learn – “Azure Virtual WAN design considerations,” subsection “Scalability benefits of

branch-to-branch connectivity”

https://learn.microsoft.com/en-us/azure/virtual-wan/design-guide#branch-to-branch-scalability

Azure Route Server is a fully managed service specifically designed to simplify dynamic routing

between Network Virtual Appliances (NVAs) and the Azure virtual network. It functions as a

centralized Border Gateway Protocol (BGP) peering point. NVAs (such as firewalls or SD-WAN

appliances) can establish a BGP session with the Route Server to dynamically exchange and

advertise routes to the Azure Software Defined Network (SDN). This eliminates the need for

complex, manually configured User Defined Routes (UDRs), providing a centralized and efficient

mechanism for route management as described in the question.

A. Azure Virtual WAN: This is a large-scale, unified framework for branch connectivity and

network aggregation. While it includes routing capabilities, it is a much broader solution, not the

specific service for centralizing BGP exchange.

B. Azure VPN Gateway: Its primary function is to provide secure site-to-site or point-to-site

connectivity. It can use BGP, but it acts as a connectivity endpoint, not a central route exchange

hub for NVAs.

C. Azure ExpressRoute: This service provides private, dedicated connectivity to the Microsoft

cloud. It uses BGP for routing over its private circuits but is fundamentally a connectivity service,

not a centralized route management point.

1. Microsoft Azure Documentation, "What is Azure Route Server?": "Azure Route Server

simplifies dynamic routing between your Network Virtual Appliance (NVA) and your virtual

network. It allows you to exchange routing information directly through Border Gateway Protocol

(BGP) routing protocol... without the need to manually configure or maintain route tables."

URL: https://learn.microsoft.com/en-us/azure/route-server/overview

2. Microsoft Azure Documentation, "Azure Route Server FAQ": "Azure Route Server is a service

that's intended to simplify the routing for NVAs in your VNet... It offers a central point where NVAs

can peer BGP with."

URL: https://learn.microsoft.com/en-us/azure/route-server/route-server-faq

3. Microsoft Azure Documentation, "About BGP with Azure VPN Gateway": This document

describes how BGP is used specifically for VPN gateways to propagate routes from on-premises

sites to virtual networks, highlighting its role as part of a connectivity solution rather than a central

exchange hub.

URL: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-bgp-overview

The command diagnose debug cloud-init show is used to display information from the cloud-init service, which handles the initial configuration of a cloud-based virtual machine. The output in option D explicitly states datasource: Azure. This is a definitive indicator provided by the FortiGate operating system that it has identified Microsoft Azure as its underlying cloud platform. This command is a standard troubleshooting and verification tool for FortiGate-VM deployments in cloud environments.

A: The diagnose sys fortiguard-service status output is generic and does not contain any information specific to the cloud provider on which the VM is hosted. B: The get system status output shows a generic, unlicensed FortiGate VM. It lacks any identifiers for the hypervisor or cloud platform. C: The diagnose hardware sysinfo output explicitly shows "manufacturer: Amazon EC2", which confirms the virtual machine is running on Amazon Web Services (AWS), not Azure.

1. Fortinet Documentation: FortiGate-VM on Azure Administration Guide 7.4.1, Page 10,

"Verifying the cloud-init process". This guide states: "You can verify the cloud-init process by using

the diagnose debug cloud-init show command. The output shows datasource: Azure."

URL: https://docs.fortinet.com/document/fortigate-vm-azure/7.4.1/administration-guide/142940/ver

ifying-the-cloud-init-process

2. Fortinet Documentation: FortiGate-VM on AWS Administration Guide 7.4.1, Page 12,

"Verifying the installation". This guide confirms the indicator for AWS instances: "Run the

diagnose hardware sysinfo command. The output should show the manufacturer as Amazon

EC2." This validates why option C is incorrect.

URL: https://docs.fortinet.com/document/fortigate-vm-aws/7.4.1/administration-guide/935000/verif

ying-the-installation

Azure Firewall Premium includes several advanced capabilities not found in the Standard SKU.

Specifically, it introduces Web categories, which allow administrators to permit or deny access to

websites based on classifications like "social media" or "gambling." Additionally, its URL filtering is

enhanced, enabling filtering based on the entire URL string, including the path and query

parameters, whereas the Standard SKU can only filter based on the Fully Qualified Domain Name

(FQDN). These features provide more granular control over outbound web traffic.

A. Content filtering and threat intelligence integration: Threat intelligence-based filtering is

available in both Azure Firewall Standard and Premium, so it is not an additional feature of

Premium.

B. Antivirus detection and AI prevention capabilities: These terms are imprecise. The actual

feature in Premium is a signature-based Intrusion Detection and Prevention System (IDPS), not a

dedicated antivirus engine or an "AI prevention" system.

C. Advanced DDoS protection and VPN diagnostics: These are features of separate Azure

services. Advanced DDoS is part of the Azure DDoS Protection service, and VPN diagnostics are

associated with Azure VPN Gateway, not Azure Firewall SKUs.

1. Microsoft Azure Official Documentation, "Azure Firewall features": This document explicitly

lists "Web categories" and "URL filtering" (with the ability to filter on the full URL) as features of

Azure Firewall Premium, while noting that Standard only supports FQDN filtering. It also confirms

that "Threat intelligence" is available in both SKUs and that "IDPS" is the specific Premium

feature.

URL: https://learn.microsoft.com/en-us/azure/firewall/features

Specific Sections: "Azure Firewall Premium features" and the feature comparison table.

When deploying a single FortiGate-VM from the Azure Marketplace using the standard template,

the process provisions several core resources to establish a functional firewall. The template is

designed to create a FortiGate instance with separate interfaces for external (public) and internal

(private) traffic. By default, this includes two virtual network interfaces (vNICs). To secure these

interfaces at the Azure level, a Network Security Group (NSG) is created and associated with

each vNIC to filter inbound and outbound traffic to the FortiGate itself.

C. One VM Scale set: A VM Scale Set is used for deploying and managing a set of auto-scaling

virtual machines for high availability, not for a single VM deployment.

D. One new route table: A route table is configured after deployment to direct traffic from

protected subnets through the FortiGate. It is not created by the single FortiGate VM template

itself.

1. Fortinet Document Library, FortiGate-VM on Microsoft Azure 7.4.1 Deployment Guide, Page

16: "The FortiGate is deployed with two network interfaces (port1 and port2) by default... A

network security group is created for each interface." This directly confirms that two vNICs and an

NSG for each are created.

URL: https://docs.fortinet.com/document/fortigate-public-cloud/7.4.1/azure-deployment-guide/121

13/deploying-fortigate-vm-from-the-azure-marketplace

2. Fortinet Document Library, FortiGate-VM on Microsoft Azure 7.4.1 Deployment Guide, Page

23: The guide provides instructions for manually creating a route table and associating it with a

subnet as a separate, post-deployment step, confirming it is not part of the initial template

creation for a single VM.

URL: https://docs.fortinet.com/document/fortigate-public-cloud/7.4.1/azure-deployment-guide/555

299/configuring-the-route-table-for-the-protected-subnet

The exhibits show that the Azure External Load Balancer (ELB) has a load balancing rule for port 80, but no rule for port 22. Consequently, the ELB drops incoming SSH traffic, which is why it is never detected by the FortiGate. To resolve this, a rule must be added to the ELB to forward port 22 traffic. An Inbound NAT rule provides a direct 1-to-1 port forwarding mapping from the ELB's public IP to a specific virtual machine instance (one of the FortiGates) in the backend pool. This is a common and direct method for enabling access for stateful, single-session protocols like SSH.

A. Configure a customized port under the Frontend IP configuration: The Frontend IP configuration defines the load balancer's public IP address, not the port forwarding rules that direct traffic to the backend pool. B. Add a new Azure load balancing rule: While possible, this is less precise for SSH. A load balancing rule for a stateful firewall cluster requires enabling "Floating IP" to ensure session integrity, making it a more complex setup than a simple Inbound NAT rule. C. Include the Linux server in the back-end pool options: The backend pool for the external load balancer must contain the FortiGate instances for traffic inspection, not the final destination server, which would bypass the firewall.

1. Microsoft Azure Documentation, "What is Azure Load Balancer?": This document distinguishes

between rule types. It states, "An inbound NAT rule forwards incoming traffic sent to frontend IP

address and port combination to a specific virtual machine... A load balancing rule is used to

distribute incoming traffic from the frontend to all instances within the backend pool." This

supports using an Inbound NAT rule for specific VM access.

URL: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview (See sections

on "Load balancing rule" and "Inbound NAT rule").

2. Fortinet Document Library, "FortiGate-VM on Azure deployment guide 7.4.0": The guide details

configuring the external load balancer. It shows creating load balancing rules for general services

and inbound NAT rules for specific access, confirming that an Inbound NAT rule is a valid and

intended mechanism for this type of scenario.

URL: https://docs.fortinet.com/document/fortigate-public-cloud/7.4.0/azure-deployment-guide/529

576/configuring-the-external-load-balancer (See steps for creating both rule types).

Using FortiGate devices at both the on-premise and Azure ends of a site-to-site VPN establishes

a homogenous security architecture. The primary advantage of this approach is the ability to

maintain consistent security policies, firewall objects, and configuration syntax across the entire

distributed network. This uniformity, often referred to as a "single pane of glass" management

experience, simplifies administration, reduces the potential for misconfigurations that can arise in

multi-vendor environments, and ensures that the security posture applied on-premise is

seamlessly extended to the cloud infrastructure.

A: This is incorrect. The purpose of an IPsec VPN is to provide strong encryption in transit. Using

FortiGate devices does not minimize this fundamental requirement.

B: While FortiGate devices are scalable, this is a general product feature, not a specific

advantage derived from using them at both ends of a single tunnel.

D: This is less precise than option C. While consistent configuration (Option C) simplifies

troubleshooting, it does not eliminate the need for it, nor is the configuration fully "automatic."

1. Fortinet Documentation - Fortinet Security Fabric: The Fortinet Security Fabric architecture is

built on the principle of a unified platform. It "provides broad visibility and control, integrated threat

detection and response, and automated security operations across the entire digital attack

surface." This unified control is the basis for consistent policies.

Source: Fortinet, Inc. (2023). FortiGate / FortiOS 7.4.0 Administration Guide. Fortinet Document

Library, "Security Fabric" section.

https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/321740/security-fabric

2. Fortinet Documentation - Secure SD-WAN for Multi-Cloud: This solution guide explicitly states

the benefit of consistency in a hybrid environment. "Fortinet Secure SD-WAN for Multi-Cloud

provides a consistent security posture and operational efficiency across multiple clouds." This

directly supports the advantage of consistent policies and configuration.

Source: Fortinet, Inc. (2022). Secure SD-WAN for Multi-Cloud Solution Guide. Page 4. https://ww

w.fortinet.com/content/dam/fortinet/assets/solution-guides/sb-secure-sd-wan-for-multi-cloud.pdf

In an Azure environment, standard layer 2 broadcast and multicast traffic, which the FortiGate

Clustering Protocol (FGCP) typically uses for heartbeat and synchronization, is not supported. To

overcome this, FortiGate High Availability (HA) in Azure is configured to use unicast FGCP. The

HA cluster members send heartbeat and configuration synchronization packets directly to each

other's specified private IP addresses over a dedicated HA sync interface. This ensures that the

configuration of the passive unit remains synchronized with the active unit, allowing for a

seamless stateful failover.

B. Using system autoscaling during a failover: Autoscaling is an Azure feature for dynamically

adjusting the number of VM instances based on load, not for synchronizing configuration within an

HA pair.

C. An Azure function distributes the configuration files: The Azure Function in this architecture is

used to call the SDN connector to update Azure's routing tables during a failover event, not to

synchronize the FortiGate configuration files.

D. By configuring FGSP on the primary: FGSP (FortiGate Session Life Support Protocol) is used

for synchronizing sessions between separate, standalone FortiGates or clusters, not for

configuration synchronization within a single HA cluster.

1. Fortinet Document Library, FortiGate-VM on Azure 7.4.2, Deployment Guide: "High availability

for FortiGate-VM on Azure". This guide explicitly states, "In this active-passive HA deployment,

the FortiGate-VMs use unicast to find each other and form a cluster." It details the configuration

steps, including enabling unicast heartbeats.

URL: https://docs.fortinet.com/document/fortigate-vm-azure/7.4.2/azure-deployment-guide/13248

6/high-availability-for-fortigate-vm-on-azure

2. Fortinet Document Library, FortiOS 7.4.4, Administration Guide: "HA FGCP unicast". This

section describes the technical basis for using unicast for FGCP when multicast is unavailable,

which is the case in public cloud environments like Azure.

URL:

https://docs.fortinet.com/document/fortigate/7.4.4/administration-guide/33204/ha-fgcp-unicast

Infrastructure-as-a-Service (IaaS) is the cloud service model that provides fundamental computing

resources, including virtual machines, networking, and storage. This model offers the highest

level of flexibility and management control over IT resources. When deploying a virtual appliance

like FortiWeb in Azure, the IaaS model allows the administrator to select a specific virtual machine

(VM) instance type. This choice directly dictates the allocated resources, such as the number of

vCPUs and the amount of memory, thereby meeting the requirement for granular control. The

consumer is responsible for managing the operating system, data, and applications, while the

cloud provider manages the physical infrastructure.

A. Software-as-a-Service (SaaS): The provider manages the entire stack, including the

application and underlying infrastructure. The consumer has no control over resources like vCPUs

or memory.

B. Platform-as-a-Service (PaaS): The provider manages the underlying infrastructure and

operating systems. The consumer deploys applications onto the platform, with limited or no direct

control over hardware resources.

C. Function-as-a-Service (FaaS): A serverless model where the provider completely manages the

infrastructure. It is designed for running event-triggered code, not for deploying stateful virtual

appliances.

1. Microsoft Azure Documentation: "What is Infrastructure as a Service (IaaS)?". This official

documentation defines IaaS as providing on-demand computing infrastructure that is managed

over the internet. It explicitly states that IaaS gives users control over the hardware that runs their

applications, including the choice of virtual machine specifications.

URL: https://azure.microsoft.com/en-us/resources/overview/what-is-iaas/

2. Fortinet Document Library: "FortiWeb-VM for Azure deployment guide". The guide details the

deployment process, which includes the step of "Choose a size for the virtual machine," where

the user selects an instance type based on CPU and memory requirements. This procedure is

characteristic of an IaaS deployment.

URL: https://docs.fortinet.com/document/fortiweb/7.4.0/azure-deployment-guide/39752/deployingfortiweb-vm-from-the-azure-marketplace (See section: "Deploying FortiWeb-VM from the Azure

Marketplace")

3. National Institute of Standards and Technology (NIST) Special Publication 800-145: "The NIST

Definition of Cloud Computing". This foundational document defines IaaS as the capability to

"provision processing, storage, networks, and other fundamental computing resources where the

consumer is able to deploy and run arbitrary software, which can include operating systems and

applications." This definition underscores the consumer's control over the provisioned resources.

URL: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf (See Page 2,

Section: "Infrastructure as a Service (IaaS)")