Public Cloud Security 7.2: Automation, Transit Architectures, and Cloud Troubleshooting

NSE7_PBC-7.2 is the legacy Fortinet NSE 7 Public Cloud Security 7.2 exam. Fortinet now labels the 7.2 course as an older version. The current Cloud Security architecture exam is NSE 7 Public Cloud Security 7.6.4 Architect, which extends the same core disciplines with newer FortiOS, FortiWeb, FortiCNAPP, automation, and cloud-native integration.

The 7.2 course concentrated on deploying FortiGate VMs in AWS and Azure, using automation, working with AWS Transit Gateway and SD-WAN Connect, troubleshooting cloud deployments, and using FortiCNP for risk management. Those topics make the legacy 7.2 material useful because they represent the transition from “virtual firewall in cloud” thinking toward security architecture integrated with provider networking.

The earlier Public Cloud Security 6.4 provides historical context, while provider-focused AWS Cloud Security 7.4 Administrator and Azure Cloud Security 7.4 Administrator material can deepen the platform-specific operational side. New candidates should still verify the current 7.6.4 objectives before scheduling.

A cloud security architect must understand native routing first

FortiGate can enforce policy only after AWS or Azure forwards the traffic through it. That makes route tables, subnets, network interfaces, gateways, and provider-specific forwarding behavior part of the security design. An incorrect cloud route can bypass inspection or black-hole traffic even when the FortiGate configuration is perfect.

For each flow, document the route at every hop. Include workload subnet, transit service, FortiGate interfaces, return path, and any load-balancing or gateway components. This is especially important for asymmetric designs, because a stateful firewall expects to see both directions of a session.

AWS Transit Gateway changes the shape of centralized inspection

Transit Gateway can connect many VPCs and on-premises networks through a central routing service. Adding FortiGate inspection requires careful attachment and route-table design so that east-west and north-south traffic traverse the security layer without loops or bypasses.

Build a small hub-and-spoke topology. Use separate route tables for ingress and egress behavior where needed, confirm propagation and associations, and test communication between two spokes. Then remove an intended route and diagnose the failure from the transit layer before touching FortiGate policy.

Azure troubleshooting has its own control-plane evidence

Azure uses VNets, user-defined routes, network security groups, load balancers, and other constructs that interact with a network virtual appliance. The same conceptual design can behave differently from AWS because the provider’s routing and availability mechanisms are different.

Use Azure effective routes and flow evidence to verify whether a packet reaches the FortiGate. Confirm interface IP forwarding and any load-balancer or route-table dependency. Avoid translating an AWS fix mechanically into Azure; understand the purpose of the control and then implement the provider-appropriate equivalent.

Infrastructure as code should make security deployments repeatable

Public Cloud Security 7.2 emphasized third-party automation and Terraform. The value is not merely faster deployment. Code creates reviewable intent, repeatability, and a path to recreate infrastructure after failure. It also exposes mistakes consistently, which is useful when combined with testing and version control.

Deploy a small FortiGate environment from Terraform, review the plan, and compare the resulting cloud resources with the code. Then alter one resource manually and observe drift. Terraform infrastructure as code reinforces repeatable deployment and drift detection, but the security engineer still needs to understand every route, interface, and permission the template creates.

Automation credentials deserve the same scrutiny as firewall admin accounts

Cloud templates and management integrations often require service principals, IAM roles, access keys, or managed identities. Those credentials can create infrastructure or alter routing, so they are high-value security assets. Least privilege and credential lifecycle are therefore part of the architecture.

Identify which API actions each automation component needs. Remove permissions that are not required and test whether deployment still succeeds. Rotate or replace credentials in a lab and confirm how the workflow recovers. A design that works only while one permanent administrator key exists is fragile and risky.

SD-WAN and cloud transit can solve different parts of the same connectivity problem

Cloud transit services provide provider-level connectivity, while Fortinet SD-WAN can make path decisions based on performance and policy. Combining them requires clarity about which layer chooses the path and where security inspection occurs. Otherwise, multiple routing mechanisms can create unexpected behavior.

Create a design with more than one path to a cloud environment and define which system should influence path selection. Degrade a link, verify the provider route, verify FortiGate SD-WAN state, and confirm the application path. This isolates whether a failure is caused by the cloud fabric or by the Fortinet overlay.

Risk management has expanded beyond firewall configuration

The 7.2 course introduced FortiCNP for cloud risk management, and current material uses FortiCNAPP. This reflects a broader shift: public cloud security includes workload posture, cloud configuration, and risk visibility in addition to network filtering. A cloud architect should understand how findings from those tools influence network or access decisions.

Take a cloud risk finding and trace the response. Is the problem a public exposure, excessive permission, vulnerable workload, or missing network restriction? Decide which team owns the fix and how Fortinet controls contribute. Network security is one layer of the response, not the only layer.

Current 7.6.4 study should preserve 7.2 reasoning but update the implementation

Fortinet’s present exam adds current FortiOS 7.6, FortiWeb, FortiCNAPP, CaaS protection, CloudFormation, Bicep, Terraform, Ansible, and updated AWS/Azure troubleshooting. That makes 7.2 a useful architectural predecessor, not a complete study plan for 2026.

The NSE 7 certification structure has also changed since the FCSS era. Verify current prerequisites and delivery rules independently of technical study. Certification program changes can happen even when the underlying cloud-design principles remain sound.

A strong final exercise is to create one automated multi-cloud design. Deploy a small protected workload in AWS and Azure, route traffic through FortiGate, generate logs, break a route in each provider, and restore service without weakening policy. Then explain the differences between the two fixes. If you can separate provider networking, Fortinet security, and automation behavior clearly, you are applying the most durable lessons from Public Cloud Security 7.2.

Containerized workloads introduce another routing and policy boundary. Even if the legacy 7.2 exam emphasized IaaS, current Public Cloud Security includes container environments. Use the 7.2 architecture as a base, then ask how traffic reaches containers, where FortiGate or FortiWeb inspection applies, and which cloud-native controls remain responsible for workload identity. The newer exam broadens the architecture rather than discarding the earlier network model.

CloudFormation and Bicep are useful to compare with Terraform because they show the difference between provider-native and cross-provider automation. Implement one small network component with each approach and compare state handling, parameterization, rollback, and permissions. The goal is not to become a full-time developer; it is to understand how the chosen automation mechanism changes operational risk and troubleshooting evidence.

Monitoring should include configuration change events. A route-table edit, security-group change, or identity-policy update can alter exposure without touching the FortiGate. Send or review provider activity logs alongside Fortinet telemetry and practice tracing who changed what. This is particularly useful when a previously protected workload suddenly becomes reachable through a path that bypasses inspection.

Resilience testing should include regional dependency assumptions. A multi-region design can still fail if both regions rely on the same identity service, automation credential, or management endpoint. Draw those dependencies and decide which must be duplicated. High availability is a system property, not simply the existence of two FortiGate instances in different locations.

Current FortiCNAPP-oriented study adds posture and workload risk to the network view. Practice taking a finding such as public exposure or excessive privilege and deciding whether the response belongs in routing, firewall policy, application configuration, IAM, or workload remediation. The architect should choose the control closest to the root cause rather than forcing every problem into a network-security solution.

Before considering a migration from 7.2 knowledge to 7.6.4 complete, run one scenario with both AWS and Azure evidence. Break connectivity in each provider for different reasons, collect provider-side and FortiGate-side diagnostics, and write a short root-cause explanation. If the two investigations look identical, the provider-specific model has probably not been learned deeply enough.

Cloud troubleshooting should also account for service endpoints and private connectivity. A workload may reach a provider service through a private endpoint rather than the public internet, changing which route and inspection path apply. Document whether that traffic should traverse FortiGate and why. Security architecture is clearer when exceptions to centralized inspection are explicit and tied to provider-native controls instead of occurring accidentally.

Load balancers can obscure the original client path and create health-check dependencies. Test how health probes reach FortiGate or protected workloads, which source addresses appear, and what happens when one instance becomes unhealthy. A firewall rule that blocks a required probe can remove a healthy service from rotation, while an overly broad exception may permit unnecessary traffic. Understanding the provider’s health-check model is part of secure availability design.

State and configuration data for Terraform or other automation should be protected because it can reveal resource identifiers, network topology, and sometimes sensitive values. Use secure remote state, access controls, and locking where supported. Then test concurrent changes to understand how the tool prevents one deployment from overwriting another. Operational safety in infrastructure as code depends on protecting the metadata that represents deployed reality.

Multi-cloud consistency should focus on control objectives rather than identical templates. AWS and Azure use different constructs, so forcing the same code structure everywhere can hide important provider differences. Define shared requirements—inspection, least privilege, logging, resilience, and controlled egress—then implement them in each platform using appropriate native services. This produces consistent security outcomes without pretending the platforms are the same.

A final migration exercise can compare an older 7.2 design with a current 7.6.4 target architecture. Identify which components remain valid, which automation should be replaced, where FortiCNAPP or FortiWeb adds new coverage, and which route or HA patterns should be redesigned. The result is a practical modernization plan rather than a simple list of changed exam objectives.