OCI Networking Professional common mistakes
OCI Networking Professional · Understand the traps and how to avoid them.
Treating a VCN as a single flat network and assuming subnets can span an entire region, then being unable to explain why two resources in the same VCN cannot reach each other without a route.
Candidates carry over habits from flat Layer 2 networks or from other clouds where a VCN behaves like a single switch. OCI VCNs are regional but subnets are strictly zonal and tied to a single availability domain or regional scope, and reachability always depends on route tables plus security rules, not on shared membership alone.
What to do instead
Draw the VCN as a region-wide container, place every subnet in its AD or mark it regional, and for any reachability question trace the path explicitly: source subnet route table, destination subnet route table, then security list and NSG rules in both directions. Practice building a two-subnet, two-AD VCN on paper before answering design questions.
Confusing the Internet Gateway with the NAT Gateway and assigning a public IP to an instance behind a NAT Gateway, expecting inbound connections to work.
Both gateways connect a VCN to the internet, so candidates treat them as interchangeable. The Internet Gateway supports bidirectional traffic and requires public IPs, while the NAT Gateway only allows outbound-initiated connections from private subnets and cannot accept unsolicited inbound traffic.
What to do instead
Memorize the directionality rule: Internet Gateway equals inbound and outbound with public IPs; NAT Gateway equals outbound only from private subnets. When a question mentions patching or package downloads from a private subnet, answer NAT Gateway; when it mentions serving traffic to the internet, answer Internet Gateway plus public IP or a load balancer.
Selecting a Service Gateway for traffic destined to an on-premises data center, or a Dynamic Routing Gateway for Object Storage access, and then defending the choice.
The gateway names sound generic, so candidates map them by intuition rather than by peering target. A Service Gateway peers a VCN to supported OCI services through the service's private endpoint, while a DRG connects the VCN to on-premises networks, other VCNs, and remote peering.
What to do instead
Build a one-line mapping and rehearse it: Service Gateway to OCI services, DRG to on-premises and cross-VCN, Local Peering Gateway to another VCN in the same region, Remote Peering Connection over a DRG to another region, Internet and NAT Gateways to the internet. For each scenario question, name the peering target first, then choose the gateway.
Assuming a route rule alone grants access, and answering a connectivity question without checking security lists or network security groups.
Routing and security are taught separately, and candidates latch onto whichever concept the question seems to emphasize. In OCI, packets need both a matching route and an allowing security rule in the relevant direction; security lists apply at the subnet level and NSGs at the VNIC level, and both are evaluated.
What to do instead
Adopt a fixed checklist for every reachability question: route table on the source subnet, route table on the destination subnet, egress rule on the source, ingress rule on the destination, and any NSG membership. State the checklist in your scratch notes and apply it in order, since exam distractors usually remove exactly one of these layers.
Mixing up stateful and stateless behavior when writing security list rules, adding a return-traffic rule for a stateful rule set or omitting one for stateless rules.
Security lists in OCI are stateless by default in the sense that responses are not automatically permitted unless you use stateful rules, and NSGs are stateful. Candidates blur the two and either create redundant rules or leave return traffic blocked.
What to do instead
Remember that NSG rules are stateful and security list rules can be stateful or stateless depending on configuration; when in doubt, add the explicit egress rule and note why. On the exam, if a scenario shows ingress allowed but no return path, check whether the rule set is stateless before blaming routing.
Choosing a Layer 7 load balancer for a TCP-only workload or a Network Load Balancer for HTTP host-based routing, and misstating which listener and backend set types are valid.
Both load balancer shapes look similar in the console, and candidates remember the names but not the layer. The Load Balancer service operates at Layer 7 with HTTP and HTTPS listeners and supports path and host routing, while the Network Load Balancer operates at Layer 4 for TCP and UDP with very high throughput and preserves the source IP.
What to do instead
Anchor each service to a layer and a protocol: Layer 7 equals HTTP or HTTPS listeners, path and host-based routing, and SSL termination; Layer 4 equals TCP or UDP, source IP preservation, and extreme throughput. Read the question for protocol and routing needs before naming a service.
Forgetting that a load balancer backend set health check failure removes an instance from rotation, and answering that the instance is rebooted or the listener is disabled.
Candidates focus on the front-end listener and overlook the backend health check lifecycle. A failing health check only marks the backend unhealthy and stops traffic to it; the instance keeps running and the listener stays up.
What to do instead
Trace the load balancer as listener, then backend set, then health check, then backend. When a scenario says users see errors from one server, check the health check policy, the port, and the path before assuming the instance crashed. Also note that a regional load balancer spans ADs while a flexible shape changes bandwidth, not layer.
Treating a private DNS zone and an internet-facing zone as interchangeable, or assuming a VCN resolver forwards all queries to the internet by default.
DNS in OCI involves private zones attached to VCNs, resolver endpoints, and forwarding rules, and candidates collapse these into a single mental model. Private zones are only visible inside attached VCNs, and the resolver uses forwarding rules and the internet for external names depending on configuration.
What to do instead
Separate the concepts: private zone equals internal name resolution scoped to attached VCNs; resolver equals the VCN's DNS service with endpoints and rules; forwarding rule equals sending specific domains to on-premises DNS. For hybrid questions, confirm the private zone is attached and the forwarding rule targets the right domain.
Ignoring VCN flow logs and the Network Visualizer when a question asks how to diagnose a connectivity problem, and instead proposing to rebuild the VCN.
Troubleshooting tooling is under-studied relative to design, so candidates reach for destructive fixes. OCI provides VCN flow logs, the Network Visualizer for path analysis, and metrics that reveal whether traffic is dropped by security rules or routing.
What to do instead
Memorize the diagnostic ladder: check security rules, check route tables, enable flow logs to see accepted and rejected flows, use the Network Visualizer to trace the path, then check metrics and alarms. For any 'how do you investigate' question, pick the observability tool before the rebuild option.
Assuming a peered VCN inherits routes or security rules transitively, so traffic from VCN A reaches VCN C through VCN B without explicit configuration.
Peering feels like joining networks, and candidates import the transitive routing assumption from other technologies. OCI local and remote peering are non-transitive by default, and each VCN needs its own route rules and security rules for the traffic it carries.
What to do instead
State the non-transitivity rule explicitly: peering connects two VCNs only, and every additional hop needs its own peering plus route and security configuration. When a question describes a hub-and-spoke topology, verify the hub has routes for each spoke CIDR and that spokes route to the hub, not directly to each other.