Networking for Multicloud Architectures
Networking for Multicloud Architectures
This domain tests the packet path: OCI VCN route tables, security lists and NSGs, DRG route tables, Azure VNet route tables/UDRs and NSGs, private DNS, and hub-and-spoke transit. The exam wants you to prove that both clouds can forward and filter the same flow symmetrically.
Core rules
- OCI route tables choose the next hop for a subnet; security lists apply at the subnet, NSGs at the VNIC. Azure route tables/UDRs choose the next hop; NSGs apply at subnet or NIC. All are stateful, so return traffic for an allowed flow is permitted.
- The DRG is the OCI hub for VCN attachments and interconnect attachments. A VCN route table sending traffic to the DRG is not enough: the DRG route table must also contain a route for the remote CIDR on the correct attachment.
- Azure hub-and-spoke can use VNet peering and a gateway in the hub. Do not build multiple paths that send request and response through different firewalls; asymmetric routing breaks stateful inspection.
- Private DNS is not automatic across clouds. Create conditional forwarders or private zones, and make sure the name used by the application resolves to the private endpoint, not a public IP.
- Summarize routes and keep CIDRs non-overlapping; overlap cannot be fixed by routing.
Worked example
Hub VCN 10.0.0.0/16 holds the DRG and interconnect. Spoke VCN 10.2.0.0/16 attaches to the same DRG. Azure VNet is 10.1.0.0/16. In the spoke route table, 10.1.0.0/16 → DRG. In the DRG route table, 10.1.0.0/16 → interconnect attachment and 10.2.0.0/16 → spoke attachment. In Azure, 10.0.0.0/16 → VNet gateway. Add NSG and security-list rules for the actual port. Reasoning: each hop needs a route, and the DRG must know both the spoke and Azure destinations.
Traps
One-way routes, missing DRG route-table entries, overlapping CIDRs, public DNS names that resolve to public IPs, and adding a second path without controlling return routing.