Fortinet FCP_ZCS_AD-7.4: Azure Cloud Security Administration

The Fortinet FCP_ZCS_AD-7.4 exam represents Azure cloud-security administration with Fortinet technologies. The subject combines Azure virtual networking, user-defined routes, network security groups, load balancers, availability constructs, identities, and the Azure control plane with FortiGate-VM security, VPN, inspection, segmentation, and centralized policy. Fortinet maps Azure Cloud Security Administrator to NSE 6 in Cloud Security.

The exam is easiest to approach by keeping Azure responsibilities and Fortinet responsibilities explicit. Azure decides how virtual networks and resources are connected, which native rules apply, and which identities can modify cloud state. FortiGate enforces the security policy placed in the packet path. If those layers are mixed together, administrators can waste time editing firewall rules for traffic that Azure never delivered to the appliance.

A strong preparation model therefore starts with the Azure packet path, then adds FortiGate behavior, and finally adds the control-plane automation that can change cloud resources around the firewall.

VNets, subnets, and user-defined routes decide whether FortiGate sees the traffic

A virtual appliance can only inspect packets Azure routes through it. VNet design, subnet boundaries, user-defined routes, peering, gateways, IP forwarding, and next-hop selection determine whether the FortiGate-VM is actually in the path. An incorrect UDR can bypass inspection, create asymmetric routing, or send traffic to an unavailable next hop.

Draw each lab topology with the source subnet, effective route, FortiGate interface, destination subnet, and return route labeled. Do this for inbound internet traffic, outbound traffic, east-west traffic, and hybrid connectivity. Azure’s effective-route information is useful because the intended route table is not always the same as the effective path after system routes, peering, and other constructs are considered.

The AWS, Azure, and Google Cloud networking comparison is helpful for separating universal routing ideas from the Azure-specific mechanisms you need to recognize under exam pressure.

Network security groups remain part of the design even when FortiGate is present

NSGs provide stateful native filtering at subnet or network-interface scope. FortiGate provides richer security services, but NSGs can still prevent traffic from ever reaching the appliance or workload. A denied connection should therefore be evaluated at both layers instead of assuming FortiGate is the only policy engine in the environment.

The detailed Azure network security group model is useful because priorities, service tags, source and destination definitions, and effective rules can all explain behavior that looks like a firewall problem from inside FortiOS.

Use the layers intentionally. Native controls can reduce unnecessary exposure and protect management paths, while FortiGate can enforce deeper inspection, segmentation, VPN, and threat prevention. Overlapping rules without a clear purpose make both audits and troubleshooting harder.

Azure load balancers can be part of the FortiGate high-availability design

Cloud HA does not behave like a physical firewall pair connected to the same switching fabric. Azure designs may use load balancers, health probes, availability zones, route changes, and automation to keep traffic flowing when one FortiGate instance fails. The administrator needs to understand what each Azure component contributes to failover.

Ask what the load balancer is balancing. It may present a frontend IP and distribute connections to multiple FortiGate instances rather than directly to application servers. Health probes decide whether an instance remains eligible, and the backend path still needs correct FortiGate routing and policy. If the probe is too shallow, Azure can consider an appliance healthy even when it cannot forward production traffic.

Study the entire failover sequence: failure detection, backend eligibility, next-hop behavior, session impact, and recovery. The label “HA” is not enough if you cannot explain how a new connection reaches the surviving firewall.

FortiGate NAT and Azure address behavior must be read together

Cloud addressing can make the source or destination visible to FortiGate different from what a candidate expects. Public IP mappings, load balancers, private addresses, and FortiGate NAT can all influence what appears in the firewall session. A policy that looks correct based on the original client address may not match if another Azure component changes the traffic representation first.

When a rule does not match, verify the addresses and interfaces FortiGate actually sees. Use session information, traffic logs, packet captures, Azure effective routes, and load-balancer diagnostics rather than changing policy based on the architecture diagram alone.

This is the cloud extension of ordinary FortiGate administration: routing, NAT, policy, and session state remain important, but Azure determines much of the network environment around them.

Hybrid connectivity requires end-to-end routing on both sides

Azure environments often connect to branches, data centers, and other clouds. FortiGate can terminate IPsec VPNs, participate in dynamic routing, and enforce policy across those links. A tunnel showing as up is only evidence about the control relationship; it does not prove the correct application routes, policies, or return paths exist.

For a failed hybrid application, confirm which prefixes Azure and FortiGate know, which next hop the workload uses, which policy applies, whether NAT is intended, and how the remote environment returns traffic. Many “VPN issues” are actually route or policy issues that happen to occur across a tunnel.

Build a lab where the tunnel remains established while one UDR or remote route is removed. The resulting symptom is a useful reminder that tunnel state and data-plane reachability are separate measurements.

Managed identities and API permissions can become network dependencies

Automation around cloud firewalls may need to read or modify Azure resources. Managed identities, service principals, role assignments, and API permissions therefore become part of the network-security design. A Fortinet component can detect a failover condition or resource change correctly but still be unable to update Azure because its identity lacks permission.

Document which identity performs each automated task, which resources it can modify, and why those rights are necessary. Granting broad Owner-style privileges to make an integration work quickly can create a control-plane risk that is much larger than the networking problem being solved.

Troubleshoot control-plane actions separately from packet forwarding. A healthy FortiGate can fail an API-driven route update, and a successful API call can coexist with a firewall policy that still denies the data flow.

Logging should combine Azure state with FortiGate traffic evidence

Azure can provide information about effective routes, NSGs, load-balancer health, resource changes, and identity activity. FortiGate provides sessions, traffic logs, policy matches, NAT behavior, VPN state, and security inspection results. A strong investigation uses both because neither platform has complete visibility into every layer.

For a failed connection, start with the effective Azure path, then confirm whether FortiGate receives the packet, which policy it matches, whether it leaves toward the workload, and whether the return traffic follows the expected route. This evidence chain prevents random changes and makes escalation more useful because each team receives a proven fault boundary.

During HA events, correlate timestamps carefully. Azure may be changing backend health or routes at the same time FortiGate peers are changing role, which can create short transitional states that are easy to misinterpret if the logs are viewed separately.

Application security belongs above the network layer

Public web workloads can face SQL injection, API abuse, bot attacks, authentication abuse, and application-specific vulnerabilities that an NSG or network firewall cannot fully understand. FortiWeb can provide application-layer controls while FortiGate continues to handle network inspection and segmentation. The products should be positioned according to the actual traffic path, including DNS, load balancing, TLS termination, and backend routing.

The FortiWeb administration model of protected hosts, SSL, web policies, API security, bot mitigation, and server health is relevant to Azure applications that require more than network-layer protection. Keep those responsibilities separate so WAF tuning does not become confused with VNet routing or NSG policy.

An application firewall cannot repair a bad route, and an NSG cannot understand whether a user is authorized to access a specific object in an API. Each layer should solve the problem it can actually observe.

Cross-cloud comparison should make Azure terminology more precise

Use the cross-cloud security map to compare common objectives such as identity, network segmentation, detection, data protection, and key management. Then return to the actual Azure constructs: VNets, subnets, UDRs, NSGs, load balancers, availability zones, identities, role assignments, and resource groups.

Compare those choices with AWS cloud security and Google Cloud security only after the Azure design is clear. The purpose of comparison is to sharpen architecture judgment, not replace provider-specific knowledge with generic cloud vocabulary.

A candidate who can state the security objective and then name the correct Azure control is much more prepared than one who only remembers that every cloud has “routes, firewall rules, and load balancers.”

Use deliberate failure testing to prepare for operational questions

Create a small Azure lab with external, internal, and workload subnets. Route one controlled path through FortiGate, apply an NSG that is deliberately restrictive, and then introduce one fault at a time: remove a UDR, deny an NSG, change a FortiGate policy, fail a load-balancer probe, or remove an automation permission.

For each fault, collect the evidence before fixing it. Record the effective route, NSG state, FortiGate session or traffic log, load-balancer health, and application result. Over time, this builds a mental library of symptoms that helps you identify the faulty layer quickly.

Readiness means you can explain why a proposed change belongs in Azure, FortiGate, or the application layer, and you can point to evidence that proves the neighboring layers do not need to be changed.