Domain 5: Implement and Operate Secure OCI Networking and Connectivity Solutions (20%)

Domain 5 of the OCI 2025 Networking Professional exam (1Z0-1124-25) tests your ability to secure OCI network infrastructure across multiple layers: packet-level controls (Security Lists, NSGs, ZPR), managed firewalls (Network Firewall, WAF), secure access services (Bastion, Cloud Shell), cross-tenancy networking, and certificate management. At 20% of the exam (~10 questions), this domain demands precise knowledge of how these services interact, overlap, and differ.

1. Security Lists vs. Network Security Groups (NSGs)

Both Security Lists and NSGs are virtual firewalls that control traffic at the VNIC level. Understanding when to use each is fundamental to this domain.

1.1 Security Lists

Security Lists operate at the subnet level. Every VNIC in the subnet is subject to all Security Lists associated with that subnet. A subnet can have up to 5 Security Lists. Every VCN has a Default Security List that cannot be deleted (but its rules can be modified). (OCI Security Lists)

Default Security List rules on creation:

1.2 Network Security Groups (NSGs)

NSGs apply to specific VNICs, not entire subnets. A VNIC can belong to up to 5 NSGs. NSGs are the recommended approach for most use cases because they provide granular, resource-level control. NSGs can reference other NSGs as source or destination in rules, but both NSGs must belong to the same VCN. (OCI Network Security Groups)

1.3 Stateful vs. Stateless Rules

Exam trap: If you create a stateless ingress rule allowing TCP/443, you must also create a stateless egress rule allowing the return traffic (source port 443). Forgetting the return rule is a common mistake. With stateful rules, the return traffic is automatically allowed.

1.4 Comparison Table

Exam trap: Security Lists and NSGs are additive — traffic is allowed if either permits it. You cannot use an NSG to block traffic that a Security List allows. To enforce a deny, you must remove the allow rule from both.

2. Zero Trust Packet Routing (ZPR)

ZPR is a new (2025) intent-based security framework that controls network communication using security attributes rather than IP addresses or network topology. It adds a layer on top of existing security mechanisms. (ZPR Overview)

2.1 How ZPR Works

For a packet to reach its target, it must satisfy all four layers:

1. Route table entry exists           (routing)
2. Security List allows               (subnet firewall)
3. NSG allows                         (resource firewall)
4. ZPR policy allows                  (intent-based policy)

If any layer denies the packet, it is dropped. ZPR does not replace Security Lists or NSGs — it adds an additional layer of enforcement. (ZPR Overview)

2.2 Key Concepts

2.3 ZPL Syntax

ZPL policies follow this pattern:

in <namespace:vcn_attribute> VCN allow <namespace:source_attribute> endpoints
  to connect to <namespace:destination_attribute> endpoints

Example — allow trusted hosts to reach sensitive databases within a specific VCN:

in networks:internal VCN allow hosts:trusted endpoints
  to connect to data:sensitive endpoints

ZPR inspects packets, evaluates the security attributes on both source and destination, and checks against matching ZPR policies. (ZPR Overview)

2.4 Supported Resources

Security attributes can be assigned to resources across multiple OCI services:

(ZPR Overview)

2.5 Key Limits

(ZPR Overview)

2.6 ZPR vs. NSG vs. Security Lists vs. IAM

Exam trap: ZPR does NOT enforce policy on traffic from the internet or from on-premises networks. It only enforces on intra-VCN and inter-VCN traffic (via LPGs and DRGs). This is a critical limitation for exam questions about securing external traffic. (ZPR Overview)

3. OCI Network Firewall

OCI Network Firewall is a managed, next-generation firewall powered by Palo Alto Networks that provides deep packet inspection, IDPS, and TLS decryption for VCN traffic. Fixed throughput: 4 Gbps. (Network Firewall Overview)

3.1 Deployment Models

The firewall is placed in a dedicated subnet and traffic is steered to it using VCN route tables. Route table entries point to the Network Firewall's private IP as the next hop.

3.2 Traffic Inspection Scenarios

North-South (external):   Internet → IGW → Network Firewall → Workload Subnet
                          On-Prem  → DRG → Network Firewall → Workload Subnet

East-West (internal):     Subnet A → Network Firewall → Subnet B
                          VCN-1    → Network Firewall → VCN-2 (via DRG)

3.3 Firewall Policy Components

A Firewall Policy is a separate OCI resource containing rules and lists. One policy can be attached to multiple firewalls.

3.4 Security Capabilities

• Stateful network filtering — L3/L4 rules on source/dest IP, port, protocol (IPv4 and IPv6)
• URL and FQDN filtering — Restrict egress to specific domains; supports wildcards
• Intrusion Detection and Prevention (IDPS) — Signature-based detection; can log, alert, or block
• SSL/TLS inspection — Decrypt and inspect encrypted traffic; supports ESNI (TLSv1.3)
• Intra-VCN inspection — Route inter-subnet traffic through the firewall
• Inter-VCN inspection — Route traffic between VCNs through the firewall
• VXLAN inspection — Inspect traffic via Virtual Test Access Points (VTAPs)

(Network Firewall Overview)

Exam trap: Network Firewall requires a firewall policy to exist before the firewall can be created. Traffic must be explicitly routed to the firewall via route table rules — it does not automatically intercept traffic.

3.5 Hub-and-Spoke with Network Firewall

In a hub-and-spoke topology, the Network Firewall sits in the hub VCN. Spoke VCNs attach to the hub's DRG. Route tables on the DRG attachments direct spoke-to-spoke traffic through the hub VCN's firewall subnet. This centralizes inspection and reduces firewall count.

4. Web Application Firewall (WAF)

OCI WAF protects web applications from OWASP Top 10 vulnerabilities, bot attacks, and application-layer DDoS. (WAF Overview)

4.1 Deployment Models

Exam trap: There is no automated conversion between Edge and Regional WAF policies. You must manually recreate settings to switch between them. (WAF Overview)

4.2 Protection Capabilities

4.3 WAF Actions

4.4 WAF vs. Network Firewall

5. Bastion Service

OCI Bastion provides time-limited, IAM-controlled SSH access to resources in private subnets without requiring public endpoints. It is a fully managed replacement for traditional jump hosts. (Bastion Overview)

5.1 Architecture

Client (SSH)  →  Bastion (public subnet)  →  Target (private subnet)

• Bastion resides in a public subnet
• Associated with a single VCN (cannot span VCNs)
• Oracle-managed — no direct SSH access to the bastion itself
• Integrated with IAM for authorization

5.2 Session Types

Exam trap: Managed SSH sessions require the Bastion plugin to be enabled on Oracle Cloud Agent. This plugin is NOT enabled by default. If the plugin is not running, managed SSH sessions will fail. Port forwarding sessions do not have this requirement. (Bastion Overview)

5.3 Security Controls

• Time-limited sessions — Every session expires after a predetermined duration
• CIDR allowlists — Restrict which client IPs can connect to the bastion
• SSH key authentication — Public key provided at session creation
• IAM policies — Control who can create bastions, sessions, and which targets are accessible

5.4 Bastion vs. Jump Host

5.5 Networking Requirements

The target VCN must have at least one of:

• Service Gateway
• Internet Gateway
• NAT Gateway

Target resource security groups must allow incoming traffic from the bastion on the target port (22 for SSH, or application-specific). (Bastion Overview)

6. OCI Cloud Shell

Cloud Shell is a browser-based terminal providing OCI CLI, Terraform, and other tools without local installation. Its networking behavior has specific constraints relevant to this exam. (Cloud Shell Intro)

6.1 Network Access

6.2 Key Limitations

• No public IP — Cloud Shell sessions do not have a public IP
• No inbound connections — Cannot SSH into Cloud Shell
• No port listening — Outbound-only connectivity
• Home region only — Persistent storage and default access are in the tenancy home region
• WebSocket required — Corporate proxies blocking WebSockets will break Cloud Shell
• Policies at tenancy level only — Cloud Shell IAM policies cannot be scoped to compartments
• VM owned by Oracle — Cloud Shell VMs exist outside your tenancy; cannot be added to dynamic groups; instance principal not available

(Cloud Shell Intro)

Exam trap: Cloud Shell cannot use instance principal authentication because the VM is outside your tenancy. Use API key or session token authentication instead.

7. Cross-Tenancy Networking

Cross-tenancy networking enables VCN peering and DRG attachment across different OCI tenancies using the requestor/acceptor model with Endorse/Admit IAM policies.

7.1 Requestor/Acceptor Model

In every cross-tenancy peering scenario:

1. Acceptor creates an IAM policy admitting the requestor's group
2. Requestor initiates the connection
3. Without the acceptor's policy, the requestor's connection attempt fails

Both tenancies must create their respective policies. Policies must be attached to the root compartment (tenancy level), not individual compartments. (DRG IAM Policies)

7.2 Cross-Tenancy LPG Peering (Same Region)

Requestor tenancy policy:

Define tenancy Acceptor as <acceptorTenancyOcid>
Define group requestorGrp as <requestorGroupOcid>
Define compartment requestorComp as id <requestorCompartmentOcid>

Allow group requestorGrp to manage local-peering-from in compartment requestorComp
Endorse group requestorGrp to manage local-peering-to in tenancy Acceptor
Endorse group requestorGrp to associate local-peering-gateways in compartment requestorComp
  with local-peering-gateways in tenancy Acceptor

Acceptor tenancy policy:

Define tenancy Requestor as <requestorTenancyOcid>
Define group requestorGrp as <requestorGroupOcid>
Define compartment acceptorComp as id <acceptorCompartmentOcid>

Admit group requestorGrp of tenancy Requestor to manage local-peering-to
  in compartment acceptorComp
Admit group requestorGrp of tenancy Requestor to associate local-peering-gateways
  in tenancy Requestor with local-peering-gateways in compartment acceptorComp

(DRG IAM Policies)

7.3 Cross-Tenancy RPC Peering (Different Regions)

Requestor tenancy policy:

Define tenancy Acceptor as <AcceptorTenancyOcid>
Define group requestorGroup as <requestorGroupOcid>
Define compartment requestorCompartment as id <requestorCompartmentOcid>

Allow group requestorGroup to manage remote-peering-from in compartment requestorCompartment
Endorse group requestorGroup to manage remote-peering-to in tenancy Acceptor

Acceptor tenancy policy:

Define tenancy Requestor as <requestorTenancyOcid>
Define group requestorGroup as <requestor-group-ocid>
Define compartment acceptorCompartment as id <acceptorCompartmentOcid>

Admit group requestorGroup of tenancy Requestor to manage remote-peering-to
  in compartment acceptorCompartment

(DRG IAM Policies)

7.4 Cross-Tenancy DRG-to-VCN Attachment

A DRG in one tenancy can attach to a VCN in another tenancy. Both tenancies must create mutual Endorse/Admit policies:

DRG tenancy endorses its drgAdmin group and admits the VCN tenancy's vcnAdmin group. VCN tenancy endorses its vcnAdmin group and admits the DRG tenancy's drgAdmin group. (DRG IAM Policies)

7.5 Cross-Tenancy Policy Keywords

Exam trap: Cross-tenancy policies must be attached to the root compartment of each tenancy. They will not work if attached to a child compartment. The any-tenancy keyword can replace a specific tenancy OCID for broader access but is less secure.

7.6 Peering Requirements

8. OCI Certificates Service

OCI Certificates provides certificate issuance, storage, lifecycle management, and integration with other OCI services. (Certificates Overview)

8.1 Resource Types

8.2 Lifecycle Operations

• Create — CAs, certificates, CA bundles (internal or imported)
• Renew — Automatic or manual renewal with configurable rules
• Revoke — Invalidate compromised certificate/CA versions via CRL
• Version management — Multiple versions per certificate; specify current version
• Delete — Remove resources no longer needed

8.3 Integrations

8.4 Constraints

• Only PEM format is supported
• Certificate chains cannot mix key algorithm families (e.g., RSA and ECDSA chains must be separate)
• Available in all OCI commercial regions

9. Edge Services Overview

OCI edge services protect applications at the network perimeter before traffic reaches VCN resources:

DDoS protection is automatic and free for all OCI customers — no configuration required. It protects against volumetric and protocol attacks at the network edge.

10. Exam Traps and Gotchas Summary

References

• OCI Security Lists
• OCI Network Security Groups
• Zero Trust Packet Routing Overview
• OCI Network Firewall Overview
• OCI Web Application Firewall Overview
• OCI Bastion Overview
• OCI Cloud Shell Introduction
• OCI Certificates Overview
• Local VCN Peering
• Remote VCN Peering
• DRG IAM Policies (Cross-Tenancy)