Cloud Network Architecture and Models
The CNEcl exam tests how well you can translate business requirements into a cloud network design using provider constructs rather than physical hardware. Questions focus on reference models, the shared responsibility boundary, software-defined networking, and the trade-offs between flat, hub-and-spoke, and transit architectures.
Core concepts
- Shared responsibility: the provider secures the physical fabric, hypervisor, and managed-service infrastructure; you own VPC/VNet configuration, route tables, security groups, IAM, and data classification.
- Underlay vs overlay: the provider's physical network carries encapsulated tenant traffic (VXLAN, Geneve); overlay addressing is independent of physical addressing.
- Regional scope: VPCs/VNets are regional; availability zones give fault isolation. Cross-region traffic needs peering, transit, or gateways and incurs latency and egress cost.
- Hub-and-spoke: centralizes inspection, DNS, and egress. Spokes attach to a transit gateway or firewall; direct peering alone is non-transitive.
- Managed data-plane services such as load balancers, NAT, and DNS are configured by you but patched by the provider.
Worked example
Two same-region VPCs must talk and share one egress. A naive design peers VPC A to VPC B; that works for A to B but not for a third spoke. Correct design: attach all VPCs to a transit gateway, put a NAT gateway in an egress VPC, point spoke default routes (0.0.0.0/0) at the transit gateway, and add a transit gateway route table entry sending 0.0.0.0/0 to the egress VPC. Validate with flow logs.
Traps
- Treating peering as transitive.
- Assuming managed services remove all customer configuration duty.
- Planning overlapping CIDRs that block later peering.
- Confusing stateful security groups with stateless network ACLs.