FCSS Public Cloud Security common mistakes
FCSS Public Cloud Security · Understand the traps and how to avoid them.
Treating the cloud provider as responsible for patching the guest OS and FortiGate firmware inside an IaaS VM, and answering shared-responsibility questions as if the provider secures 'the stack' end to end.
Candidates carry over mental models from SaaS or from on-premises hosting, and the shared-responsibility split differs by service model (IaaS, PaaS, SaaS) and by layer (physical, hypervisor, guest OS, data, identity). They memorize 'provider secures the cloud, you secure what's in it' without mapping it to specific controls.
What to do instead
Build a layer-by-layer table for IaaS/PaaS/SaaS and place each control (physical datacenter, hypervisor patching, guest OS patching, FortiGate firmware, security groups, IAM policy, data classification, encryption keys) on the correct side. Practice classifying a specific control rather than reciting the slogan.
Assuming the cloud provider's native firewall (security groups, NSGs, Azure Firewall) covers the same threats as a FortiGate, and answering inspection questions as if security groups perform Layer 7 inspection.
Security groups and NSGs are stateful Layer 3/4 filters with allow-only semantics; candidates conflate 'network firewall exists' with 'traffic inspection exists'. They also forget that many cloud-native filters cannot see east-west traffic between instances in the same subnet.
What to do instead
Separate the functions explicitly: security groups/NSGs for coarse L3/L4 segmentation, a FortiGate (or cloud NGFW) for L7 inspection, IPS, TLS inspection, and application control. When a scenario asks about malware or intrusion detection, route to the inspection appliance, not the security group.
Designing VPC/VNet subnets without planning for the reserved addresses and the provider-imposed minimum subnet size, then being surprised when usable IP counts are lower than expected or a subnet cannot be created.
Each provider reserves addresses (for example AWS reserves five addresses per subnet; Azure reserves addresses per subnet for platform services), and some providers enforce minimum subnet prefixes. Candidates size subnets from the CIDR math alone.
What to do instead
Memorize the reserved-address rules for each provider you are tested on and subtract them when sizing. Check minimum subnet prefix constraints before proposing a CIDR plan, and leave growth room in the VPC/VNet range for future peering and inspection subnets.
Proposing VPC peering as the transit solution for a hub-and-spoke design with many spokes, then discovering peering is non-transitive and the full mesh explodes.
Peering is the first tool candidates learn for connecting two VPCs, and it works perfectly for a pair. The non-transitive property and the N-squared connection count only surface at scale.
What to do instead
For multi-VPC/multi-VNet topologies, default to a transit hub (AWS Transit Gateway, Azure Virtual WAN or hub VNet with peering, GCP Network Connectivity Center) and reserve direct peering for simple two-VPC cases. State explicitly in designs that spoke-to-spoke traffic traverses the hub and the inspection appliance.
Forgetting that route tables must point spoke or workload subnets at the FortiGate's ENI/IP for inspection, and that return traffic needs a route back, so traffic silently bypasses the firewall.
Candidates draw the FortiGate in the diagram but do not trace the packet path through route tables in both directions. Asymmetric routing and missing return routes are the usual root cause of 'the firewall is deployed but not inspecting'.
What to do instead
For every inspected flow, write the forward path and the return path as explicit route-table entries on each subnet, including the appliance subnet and the gateway endpoint. Verify that the workload subnet's default route targets the FortiGate interface, not the internet gateway.
Deploying a single FortiGate VM without a high-availability pair or without considering the provider's HA support (for example floating IP reassignment or API-based failover), then treating the design as production-ready.
Lab deployments use one appliance and candidates transfer that to exam scenarios. Cloud HA differs from on-premises because there is no shared L2 segment for gratuitous ARP; failover relies on provider APIs, route changes, or IP movement.
What to do instead
Default to an active-passive pair across availability zones, and describe the failover mechanism the provider actually supports (API-driven route or IP reassignment, or SDN connector-based HA). Note that HA in the cloud is orchestration, not VRRP over a shared segment.
Picking a FortiGate VM license and instance size from habit rather than from throughput, inspection, and IPsec requirements, and ignoring bring-your-own-license versus on-demand licensing implications.
Candidates memorize model names but not the mapping between vCPU count, licensed throughput, and features such as TLS inspection or IPS that consume extra CPU. Licensing model also affects automation and teardown behavior.
What to do instead
Size from the required inspected throughput and concurrent sessions, not from the raw model name, and remember that enabling TLS inspection or IPS reduces effective throughput. Know which license model fits pay-as-you-go automation versus committed capacity, and check the provider marketplace terms.
Configuring the FortiGate's SDN connector or IAM role with overly broad permissions, or skipping it entirely, so dynamic address objects and autoscale integration do not work.
The SDN connector needs read access to the provider API to resolve tags and instance metadata. Candidates either grant wildcard permissions to 'make it work' or forget the connector and then wonder why tag-based policies never match.
What to do instead
Create a least-privilege role scoped to the required read actions and resources, attach it to the instance profile, and verify the connector status and resolved dynamic objects. Tie security policies to tags or names that the connector can actually resolve.
Treating CSPM findings as a to-do list of individual fixes instead of mapping them to misconfigurations in identity, storage, and network exposure, and ignoring the CNAPP pillars beyond posture.
Candidates equate CNAPP with CSPM alone and remediate symptoms. They miss that most critical findings trace to overly permissive IAM, public storage, or open management ports, and they overlook workload protection and CIEM.
What to do instead
Group findings by root cause (identity, storage exposure, network exposure, missing encryption) and prioritize by blast radius. Remember CNAPP spans CSPM, CIEM, workload protection, and often DSPM; answer questions about 'who can do what' with CIEM, not CSPM.
Assuming encrypted traffic is inherently safe, so TLS-encrypted east-west or egress traffic is allowed to bypass inspection, and answering inspection questions as if the FortiGate can see inside TLS without configuration.
Candidates reason that 'it's encrypted, so we can't inspect it' and accept blind spots. TLS inspection requires certificate deployment, policy configuration, and exceptions for pinned or privacy-sensitive traffic.
What to do instead
Design TLS inspection explicitly: where certificates are presented, which categories are exempted, and how outbound and east-west encrypted flows reach the inspection point. State the blind-spot trade-off for exempted traffic rather than claiming full visibility.
Automating deployment with infrastructure-as-code but hardcoding credentials, security group rules open to 0.0.0.0/0 on management ports, and no state or drift management.
Candidates focus on 'it deploys' and treat the template as a one-time script. Secrets end up in templates, management access is opened for convenience, and manual console changes drift from the code.
What to do instead
Use instance roles or secret managers instead of embedded credentials, restrict management access to a bastion or private path, and treat the template as the source of truth with drift detection and review. Include the FortiGate bootstrap configuration in code.
Ignoring log and telemetry egress from the cloud VPC to the SIEM or FortiAnalyzer, so the inspection appliance is deployed but its logs never leave the VPC.
Candidates design the data path for traffic but not for logs. Egress restrictions, private endpoints, and NAT requirements for the management interface are easy to overlook.
What to do instead
Design the logging path explicitly: which interface sends logs, whether it needs a NAT gateway or private endpoint, and how log volume is budgeted. Verify that FortiAnalyzer or SIEM ingestion is reachable from the management path before declaring the deployment complete.