Public Cloud Security 7.6 Architect: Current NSE 7 Cloud Path

FCSS_CDS_AR-7.6 is a legacy code in the Fortinet Public Cloud Security 7.6 architecture lineage. The current Fortinet exam is NSE 7 - Public Cloud Security 7.6.4 Architect, a live Cloud Security exam focused on integrating and administering Fortinet solutions across enterprise public-cloud environments. Fortinet currently describes a 75-minute exam with roughly 35–40 questions and product context around FortiOS 7.6 and FortiWeb 7.4.

The certification label changed in July 2026: FCSS was retired and current candidates now work within the NSE 7 certification family. The exam is broader than one cloud provider. Fortinet’s current objectives include protecting IaaS and CaaS, integrating with cloud-native tools, infrastructure automation with Terraform, Ansible, Azure Bicep, and AWS CloudFormation, monitoring AWS and Azure, and troubleshooting connectivity and SDN connectors.

This is an architecture exam, so candidates should be able to defend design choices. A strong answer connects workload location, routing, identity, availability, automation, visibility, and the specific Fortinet control to the risk it is intended to reduce. Product knowledge matters, but it must be applied to realistic cloud operating models rather than recalled as isolated commands.

Start with workload and trust boundaries before choosing a security component

Public-cloud security designs should begin with what is being protected: internet-facing applications, private services, container platforms, administrative interfaces, east-west service traffic, or hybrid connectivity. Each workload has different exposure and availability requirements. The architect should identify trust boundaries and traffic flows before placing a firewall, web application firewall, or cloud-native control.

Create diagrams for AWS and Azure that mark accounts or subscriptions, networks, subnets, routing domains, gateways, load balancers, identity boundaries, and Fortinet components. Then explain which threats each control addresses and what remains the responsibility of the cloud provider or workload team.

The three retired provider-specific exams—Google Cloud Security 7.6, AWS Cloud Security 7.4, and Azure Cloud Security 7.4—are useful historical depth when you need to compare platform-specific operating models.

IaaS protection depends on deliberate routing through inspection points

Shared-service architectures add governance questions to routing. A central security VPC or virtual network may protect workloads owned by many teams, so changes to route tables, firewall policies, and inspection capacity need clearly assigned ownership. A technical design can be correct and still fail operationally if application teams cannot understand or request changes safely.

Virtual firewalls are effective only when cloud routes send the intended traffic through them. In AWS that may involve VPC routing, transit constructs, gateways, load balancers, or route automation. In Azure it may involve user-defined routes, virtual WAN or hub-spoke patterns, gateways, and load-balancing components. The exact mechanisms differ, but the architectural question is the same: what path does the packet actually take?

Candidates should trace north-south, east-west, and hybrid traffic in both directions and identify where stateful inspection occurs. Pay special attention to asymmetric routing and failover, because cloud orchestration can change a path without changing FortiGate policy. A correct firewall configuration cannot protect traffic that bypasses the appliance.

Use effective route information, packet captures, and session data to validate diagrams. Architecture becomes credible only when the observed path matches the intended path.

CaaS protection adds container and service-lifecycle considerations

Container platforms change workload identity and lifespan. Pods or tasks can be ephemeral, addresses can change, and east-west communication may remain inside a cluster or virtual network. Security architecture should account for image risk, runtime exposure, ingress, egress, service-to-service communication, secrets, and how Fortinet controls integrate without relying on fragile static assumptions.

Current Fortinet objectives explicitly include protecting CaaS. Candidates should therefore understand where network security, web/API security, cloud-native controls, and workload-risk platforms contribute. The right answer may involve more than a virtual firewall if the threat exists inside application code, an API, or a container image.

Design test cases around deployment and scaling. Confirm that policy and visibility remain effective when workloads are recreated, scaled horizontally, or moved within the platform.

Web and API security protect application behavior above the network layer

Public applications often require controls that understand HTTP, APIs, bots, vulnerabilities, and application-layer denial of service. FortiWeb can complement network firewalls by inspecting this behavior closer to the application. The current FortiWeb 8.0 Administrator path provides useful product-level depth for architects who need to understand what a WAF can enforce.

Architects should decide where TLS is terminated, which component sees client identity, how health checks reach the application, and how application policies behave during scaling or failover. These details affect both protection quality and availability.

API exposure deserves explicit attention. Inventory interfaces, authentication models, sensitive data, partner access, and unexpected endpoints. A cloud design that protects only browser traffic leaves an increasingly important part of the application surface under-specified.

Cloud-native identity and Fortinet administration must both follow least privilege

Identity design should include workload identities as well as administrators. Applications that call cloud APIs need narrowly scoped roles, and security tools that discover resources or update routes need only the actions required for those integrations. Prefer short-lived credentials or federated identity where supported, and alert on unusual privilege changes because the control plane can bypass many network defenses.

AWS IAM and Microsoft Entra/Azure RBAC control who can deploy or change cloud infrastructure. Fortinet platforms have their own administrative roles and credentials. A strong architecture limits both layers, uses automation identities deliberately, and keeps privileged access separate from ordinary workload traffic.

Infrastructure automation often needs broad enough permissions to create interfaces, routes, security rules, or monitoring integrations. Scope those permissions to the actual workflow and protect credentials or federation relationships. A pipeline that can rebuild the environment is also a high-value target.

Include emergency access in the design. If routing or identity integration fails, operators still need a controlled way to reach security components without leaving management interfaces permanently exposed.

Infrastructure as code turns architecture into repeatable state

Fortinet’s current exam explicitly includes Terraform, Ansible, Azure Bicep, and AWS CloudFormation. Candidates should know what each tool contributes and, more importantly, how to validate the infrastructure it creates. Successful automation does not guarantee correct routing, safe identity permissions, or working security policy.

Use version control, peer review, reusable modules, environment-specific parameters, and change previews. Keep state and secrets protected. After deployment, compare actual cloud resources with the intended design and run representative traffic tests. This closes the gap between configuration generation and operational proof.

Rollback deserves equal design effort. Network and security automation can remove the very management path needed to fix a mistake, so staged rollout and out-of-band recovery options should be planned before production changes.

Monitoring should combine cloud telemetry with Fortinet security evidence

Monitoring should also prove coverage. Maintain an inventory of expected accounts, subscriptions, regions, networks, and security devices, then alert when a data source stops reporting. A quiet dashboard is not evidence of a quiet environment if a new account or workload was never connected to the monitoring pipeline.

AWS and Azure provide control-plane, network, and service telemetry, while Fortinet devices provide session, threat, policy, web-security, and system evidence. Architecture should define which events are retained, where they are centralized, how identities and resource names are normalized, and who can investigate them.

Candidates should practice one investigation across layers: an infrastructure change, a suspicious flow, and the resulting security decision. Align timestamps and resource identifiers so the timeline can be reconstructed. A cloud alert without firewall context can be incomplete, while a firewall event without cloud-change context can misidentify the root cause.

Cost and retention are also design concerns. Excessive export can be expensive, but insufficient telemetry can make incident reconstruction impossible. Choose data based on security and operational questions rather than collecting everything without a plan.

Troubleshooting AWS and Azure SDN connectors requires ownership clarity

Fortinet integrations may use cloud APIs or SDN connectors to learn dynamic objects and platform context. When those integrations fail, the cause can be authentication, permission, API reachability, object filtering, stale state, or a product configuration issue. Troubleshooting should prove each dependency in sequence.

Current exam objectives explicitly call out AWS and Azure connectivity problems and SDN connector troubleshooting. Build labs where a connector has an expired credential, insufficient role, wrong scope, or unreachable endpoint. Observe how the failure appears in Fortinet logs and cloud audit records.

The broader lesson is architectural: dynamic integrations are powerful because they reduce static configuration, but they create dependencies that must be monitored just like a routing neighbor or a critical service.

Architect-level readiness means reasoning across providers and Fortinet products

Capacity planning belongs in the same architecture discussion. Firewall throughput, TLS inspection, WAF processing, log export, inter-zone traffic, and autoscaling can affect performance and cost during normal peaks or attacks. Define expected load, failure thresholds, and scaling behavior so an incident does not reveal that the security layer itself is the bottleneck.

The current Public Cloud Security Architect target is not simply the sum of the older AWS, Azure, and Google exams. It expects candidates to compare patterns, automate infrastructure, integrate multiple Fortinet solutions, monitor cloud workloads, and troubleshoot under provider-specific constraints. That requires a broader mental model than learning one console deeply.

Use the Fortinet certifications to verify current requirements before scheduling, and keep provider-specific legacy material only where it adds technical depth. Build comparable AWS and Azure labs so you can explain what changes between providers and what Fortinet concepts remain constant.

A strong candidate can defend the traffic path, identity model, availability plan, automation approach, visibility design, and response to common failures. If those decisions can be explained with evidence and tradeoffs, the preparation is aligned with architecture rather than with memorizing an old FCSS code.