Fortinet NSE7_PBC-7.2: Public Cloud Security Architecture

The Fortinet NSE7_PBC-7.2 exam represents the Public Cloud Security 7.2 architecture generation. Fortinet’s course for this version focused on deploying FortiGate virtual machines in public clouds, using third-party automation, securing AWS and Azure network paths, working with AWS Transit Gateway and SD-WAN Connect, troubleshooting Azure connectivity, and using FortiCNP for cloud-risk visibility. The underlying challenge is architectural: the engineer must know which decisions belong to the cloud platform, which belong to FortiGate, and how the two control planes combine into one secure packet path.

Fortinet now uses Public Cloud Security 7.6.4 Architect under NSE 7 Cloud Security. The current course expands the design with newer automation, SDN connectors, FortiCNAPP, and current AWS and Azure patterns, but the 7.2 material remains useful because the same routing, interface, HA, automation, and hybrid-connectivity principles still govern cloud deployments.

The earlier Public Cloud Security 6.4 article establishes the previous generation, while the existing Public Cloud Security 7.6 architecture article shows the modern destination. This article focuses on what the 7.2 generation contributed in between.

Cloud-native networking determines whether FortiGate sees the traffic at all

Public-cloud firewalls do not sit on physical Ethernet segments that the network team controls end to end. VPCs or VNets, subnets, virtual NICs, route tables, native security controls, gateways, load balancers, and cloud transit services decide whether a packet ever reaches FortiGate. A correct firewall policy cannot inspect traffic that the provider sends around the appliance.

Draw three flows for every deployment: inbound from the internet, outbound from a workload, and east-west between workloads or networks. Mark every native cloud object along the path and then the FortiGate interfaces, routes, NAT, and policy. This makes ownership visible and prevents teams from changing both cloud routing and FortiOS at the same time.

The cloud security fundamentals model is useful because network controls are only one part of cloud protection. Identity, workload configuration, data, posture, and the provider control plane can create risk even when FortiGate is configured perfectly.

FortiGate-VM deployment should have a repeatable interface and routing model

Public-cloud instances use virtual interfaces, provider-assigned addresses, metadata, and platform-specific forwarding requirements. External, internal, management, and HA roles should be named consistently so automation can reproduce the topology without hidden assumptions.

After deployment, validate basic forwarding before enabling advanced inspection. Confirm one inbound session, one outbound session, and one east-west session, then inspect the FortiGate route table, session state, NAT, and packet path. If the appliance boots but traffic bypasses it, the problem belongs to cloud routing or interface attachment, not to IPS or application control.

Treat cloud-specific settings such as IP forwarding, source/destination checks, public IP association, and next-hop route configuration as part of the firewall architecture. They are external dependencies on the FortiGate data plane.

AWS Transit Gateway and SD-WAN Connect introduce another routing domain

The 7.2 generation placed notable emphasis on AWS Transit Gateway and SD-WAN Connect. These services can centralize routing between VPCs, branches, and security appliances, but they also add route tables, attachments, propagation, BGP, and policy that must agree with FortiGate.

A Transit Gateway attachment being healthy does not prove that the desired prefix is propagated or associated with the correct route table. Likewise, BGP over SD-WAN Connect can be established while the preferred route is filtered or has the wrong attributes.

The AWS cloud security administration article provides a useful platform-level companion. For exam preparation, trace a branch-to-AWS application flow through the branch overlay, Transit Gateway, FortiGate, workload subnet, and return path.

Azure troubleshooting should separate platform routing from FortiOS state

Azure uses VNets, subnets, user-defined routes, NICs, NSGs, public IPs, load balancers, and related services to shape traffic. A FortiGate policy can be correct while a UDR points to another next hop or while an NSG blocks the connection before FortiGate sees it.

Use Azure effective routes and native diagnostics alongside FortiGate routing, sessions, packet captures, and traffic logs. The strongest troubleshooting sequence proves whether the packet reached the FortiGate interface, whether FortiOS accepted it, and whether the return route remained symmetric.

The Azure cloud security administration article gives the platform-specific view. The 7.2 architect skill is knowing how to combine that evidence with FortiGate state rather than blaming one platform by default.

Infrastructure as code should make the design reproducible and reviewable

Public-cloud security deployments are frequently created through Terraform, CloudFormation, ARM or Bicep, or other automation. Infrastructure as code lets interfaces, routes, security controls, and FortiGate instances be versioned and reviewed, but it also makes one template error repeatable across many environments.

Separate the responsibilities of the cloud template from the FortiGate configuration. The infrastructure code may create networks, load balancers, and instances, while FortiManager or FortiOS defines security policy, routing, and inspection. Keeping these layers explicit improves rollback and ownership.

The hybrid-cloud architecture model helps because public-cloud security usually connects to data centers, branches, identity systems, and centralized operations rather than living inside one isolated account or subscription.

High availability depends on cloud services as well as FortiGate

Public cloud does not reproduce every Layer 2 behavior used by physical firewall clusters. HA may depend on multiple instances, availability zones, health probes, load balancers, route changes, cloud APIs, or Fortinet-specific automation.

The architect should be able to explain which component detects the failure, which object changes, how traffic is redirected, which state can be preserved, and which permissions allow the automation to act. An instance-level design does not automatically protect against a zone or regional failure.

Test degraded-state capacity. The surviving FortiGate and the cloud path must handle the traffic and inspection load that moves during failure. A failover that technically redirects traffic but overloads the surviving instance is not a successful architecture.

FortiCNP adds risk context beyond the firewall packet path

The 7.2 course introduced FortiCNP for cloud-native risk management. This is important because cloud security includes misconfiguration, workload exposure, identity risk, and software or data posture that a network firewall cannot fully assess.

Use posture findings to prioritize remediation rather than assuming every cloud misconfiguration deserves the same urgency. Public exposure, sensitive data, workload criticality, identity permissions, and exploitability influence consequence.

The cross-cloud security concept map is helpful because it separates network, identity, posture, detection, data, and key-management responsibilities across AWS, Azure, and Google Cloud.

Hybrid connectivity should be validated as routing plus security, not simply tunnel status

FortiGate-VM often connects cloud workloads to data centers, branches, or other clouds through IPsec, SD-WAN, Transit Gateway, virtual WAN services, or private connectivity. A tunnel being up proves only one part of the path.

Verify cloud route tables, FortiGate routing, advertised prefixes, firewall policy, NAT, and the remote return path. When several connectivity options coexist, document which path is preferred and how failover behaves so traffic does not bypass required inspection or become asymmetric.

Practice one failure in the cloud route table, one BGP policy failure, and one FortiGate rule failure. The user symptom can be identical, but the evidence and correct repair are different.

AWS and Azure should be compared by security objective, not copied literally

Public-cloud architecture becomes easier to transfer between providers when the engineer compares categories rather than product names. Both AWS and Azure need segmented networks, route control, identity, load balancing, high availability, logging, automation, and workload protection, but the implementation details differ enough that copying one design verbatim can create subtle failures.

Build the same security requirement in both providers: two availability zones, inbound application traffic, outbound internet access, east-west inspection, hybrid connectivity, and a recovery path. Then compare the route tables, interface behavior, load-balancing model, identity used by automation, and logging available to operations.

That exercise develops the architect skill the exam is really testing: preserve the security objective while adapting to the control plane of the platform.

Operational evidence should be planned before the first incident

Cloud incidents often involve two teams and two evidence sources: native cloud diagnostics and FortiGate diagnostics. The architecture should define which logs, flow records, route information, session data, and administrative change history will be retained before anyone needs them.

Use timestamps and change records consistently. A route-table modification, auto-scaling event, FortiGate policy install, and load-balancer health change can happen within minutes of each other, and later investigation needs enough evidence to distinguish cause from coincidence.

Centralized logging is especially valuable in dynamic environments because instances and addresses may change after the original event. Historical evidence should survive the workload that generated it.

Migration planning should compare 7.2 assumptions with the current 7.6.4 model

Moving from a 7.2 design to a current cloud-security architecture should begin with an inventory of what the older environment depends on: FortiGate-VM topology, automation templates, Transit Gateway or Azure routing, native controls, VPN, dynamic objects, and FortiCNP workflows.

Then map those functions to the current design, including newer SDN connector behavior and FortiCNAPP. The goal is not to replace every older mechanism simply because a newer product exists; it is to identify which controls remain sound, which need version updates, and which new risk-management capabilities fill a real gap.

Document the migration in stages so networking, application, and security teams can validate packet paths and policy after each change instead of troubleshooting an all-at-once redesign.

Move from Public Cloud Security 7.2 into the current 7.6.4 architect path

Fortinet’s current certification structure lists Public Cloud Security 7.6.4 Architect as the active NSE 7 Cloud Security exam. Current candidates should use the active objectives and product versions for scheduling.

Preserve the 7.2 skills around FortiGate-VM deployment, AWS Transit Gateway, SD-WAN Connect, Azure troubleshooting, infrastructure as code, HA, cloud routing, hybrid connectivity, and cloud-risk posture. These are the architecture concepts that transfer.

A strong capstone deploys a FortiGate-VM topology from code, forces inbound and east-west traffic through it, connects a branch or data center, validates HA, then breaks one cloud route and one FortiGate policy and identifies each fault without weakening unrelated security.