Domain 8: OCI Networking Best Practices (0% -- Informational)

Domain 8 of the OCI 2025 Networking Professional exam (1Z0-1124-25) carries 0% weight and is not scored independently. However, best practices knowledge is tested implicitly across all seven scored domains. This document consolidates the best practices that Oracle expects candidates to know and apply when answering questions in every other domain.

1. Architecture Design Best Practices

1.1 VCN Design Patterns

Three fundamental topologies appear on the exam:

Hub-and-spoke is the recommended pattern for production environments. The DRG acts as the central virtual router, and transit routing through a hub VCN enables traffic inspection via OCI Network Firewall or third-party appliances before reaching spoke VCNs. (OCI Networking Overview)

1.2 CIDR Planning and IP Address Management

Exam trap: OCI reserves 3 addresses per subnet (network, gateway, broadcast), not 5 like AWS. Questions testing IP capacity use this number. (OCI Networking Overview)

1.3 Subnet Design

Always use regional subnets unless there is a specific legacy requirement for AD-specific subnets. Regional subnets span all availability domains in a region, providing better resilience and simpler management. (OCI Networking Overview)

The recommended tiered subnet architecture:

DMZ Subnet (public)   --> Load balancers, WAF endpoints
Public Subnet         --> Web servers, NAT instances, IDS
Private Subnet        --> Databases, application servers, internal hosts

Every subnet must be associated with exactly one route table, one or more security lists, and one set of DHCP options. If not explicitly specified, these default to the VCN's default resources. (OCI Networking Overview)

Exam trap: A private subnet enforces isolation regardless of whether an Internet Gateway exists in the VCN. Instances in private subnets cannot have public IPv4 addresses, period.

1.4 Multi-Region Architecture

VCNs are regional and cannot span regions. Multi-region designs require:

• Separate VCNs in each region connected via Remote Peering Connections (RPCs) through DRGs
• Duplicate cloud resources (subnets, route tables, security rules) in the secondary region for location-redundant FastConnect
• Inter-region latency monitoring via the OCI Network Command Center (OCI Networking Overview)

2. Security Best Practices

2.1 Defense in Depth

Oracle mandates a multi-layer security approach. Each layer operates independently -- a failure in one layer does not compromise the others:

NSGs are Oracle's recommended approach for granular security. They enable microsegmentation -- controlling traffic between individual VNICs rather than entire subnets. Use security lists as a baseline and NSGs for workload-specific rules. (OCI Security Reference)

2.2 Least Privilege for Network Access

• Never allow SSH (22) or RDP (3389) from 0.0.0.0/0. Restrict to authorized CIDR blocks. Temporarily enable access on demand by updating NSG rules. (OCI Security Reference)
• Use OCI Bastion service for secured access to private resources instead of exposing jump boxes to the internet.
• Restrict gateway creation (Internet Gateway, NAT Gateway, DRG) to network administrators via IAM policies.
• Separate network admin IAM policies from compute/database admin policies. The policy manage virtual-network-family grants full networking control. (OCI Networking Overview)

Exam trap: To make an instance publicly reachable, ALL of these must be true simultaneously: public subnet, Internet Gateway enabled, public IP assigned, AND security rules allowing inbound traffic. Missing any one blocks access.

2.3 Private Subnets by Default

Place all security-sensitive workloads (databases, application servers) in private subnets. Use a NAT Gateway for outbound internet access (patches, updates) and a Service Gateway for private connectivity to Oracle services (Object Storage, Autonomous Database) without traversing the internet. (OCI Security Checklist)

2.4 Encryption in Transit

• Terminate TLS at load balancers (HTTP) or at backend servers (TCP passthrough)
• Enable end-to-end TLS between clients and backends through the load balancer
• OCI load balancers support TLS 1.2 by default
• Traffic to Oracle services via Service Gateway stays on the Oracle backbone -- it does not traverse the public internet (OCI Security Reference)

3. Connectivity Best Practices

3.1 FastConnect Redundancy

Oracle defines three levels of FastConnect redundancy:

A single Layer 3 partner virtual circuit is automatically redundant between OCI and the partner by design -- it maintains two separate BGP sessions on different physical connections. Layer 2 partner circuits require explicit redundant virtual circuit configuration. (FastConnect Redundancy)

Exam trap: L3 partner virtual circuits get built-in redundancy. L2 partner and third-party/colocation circuits do not -- you must configure it yourself.

3.2 BGP Tuning and Failover

• Use AS_PATH prepend to influence Oracle-to-on-premises egress traffic preference
• Use local preference on-premises to control on-premises-to-Oracle traffic preference
• OCI supports BFD (Bidirectional Forwarding Detection) for millisecond-level link failure detection on FastConnect
• During maintenance, Oracle sends RFC 8326 BGP Graceful Shutdown community 65535:0 with AS path prepending. Configure CPE devices to honor this by setting local preference to zero on affected paths. (FastConnect Redundancy)

3.3 VPN as Backup

If redundant FastConnect is not possible, configure Site-to-Site VPN with BGP routing as a backup. Manipulate routing attributes so FastConnect routes are always preferred over VPN routes. Each CPE public IP supports up to 8 IPSec connections (16 tunnels total). Individual tunnel throughput varies by CPE device and internet path. (FastConnect Redundancy)

3.4 Bandwidth Planning

• FastConnect bandwidth can be updated after provisioning -- start with current needs and scale up
• Scale redundant physical connections evenly using cross-connect groups (LAG)
• For third-party/colocation: each redundant connection must be in its own cross-connect group for independent scaling (FastConnect Redundancy)

4. Logging and Monitoring Best Practices

4.1 What to Log

Stream flow logs to multiple destinations: Logging Analytics for real-time analysis, Object Storage for compliance archival, and third-party systems via Kafka. (OCI Monitoring Best Practices)

Exam trap: Flow log entries may show NODATA or SKIPDATA status during high-traffic periods due to capacity constraints. This does not indicate a configuration error.

4.2 Alerting on Network Events

Use the OCI Events and Notifications service to alert on changes to critical network resources. Configure alarms at three severity levels:

• At Risk: Resource approaching inoperability
• Non-Optimal: Resource performing below expected levels
• Resource Status: Resource is up or down

Review alarm thresholds weekly. Thresholds too wide generate alert fatigue; thresholds too tight reduce reaction time before outages. (OCI Monitoring Best Practices)

4.3 Network Command Center Tools

4.4 Key Metrics to Monitor

(OCI Monitoring Best Practices)

Quick Reference: Best Practices Summary

References

• OCI Networking Overview
• OCI Well-Architected Framework: Secure Network Access
• OCI Well-Architected Framework: Monitor Your Workload
• FastConnect Redundancy Best Practices
• OCI Security Reference: Networking
• OCI Security Checklist: Network Security