Browse Oracle Certification Guides

OCI 1Z0-1124-25 Cheat Sheet

March 28, 2026

OCI 1Z0-1124-25 cheat sheet for key facts, traps, service mappings, and final review.

On this page

Use this for last-mile review. Keep it open during mixed OCI networking questions and pair it with the Resources when you want Oracle’s exact networking wording.

1Z0-1124-25 usually gets easier when you read the stem in this order:

  1. Path lane: where should traffic go?
  2. Filtering lane: what should be allowed or denied?
  3. Private-connectivity lane: DRG, VPN, FastConnect, service gateway, or NAT?
  4. Troubleshooting lane: route, filter, DNS, then gateway or attachment state.

OCI answer sequence

Use this when the stem mixes ingress, async delivery, reliability, security, or operations.

    flowchart TD
	  S["Scenario"] --> I["Classify the interaction mode"]
	  I --> E["Pick API Gateway, Events, Notifications, Streaming, or Functions"]
	  E --> R["Check retry, idempotency, ordering, and dead-letter behavior"]
	  R --> S2["Check Vault, IAM, private exposure, logs, and auditability"]

Fast lane picker

If the question is mainly about… Start with… Usual winning move
where traffic should go route and gateway choice path first
what traffic should be allowed NSGs or security lists filter second
private connectivity DRG, VPN, FastConnect, or service gateway classify path type first
public exposure internet gateway and edge design keep the edge deliberate
a broken connection route, filter, DNS, then gateway state do not guess randomly
subnet design public/private placement and route intent subnet purpose before instance details
traffic distribution load balancer shape and backend health distribution before security fine-tuning
name resolution private/public DNS view and resolver path names must match the chosen path

Read every networking scenario in this order

  1. Identify the communicating endpoints and whether traffic is north-south, east-west, or hybrid.
  2. Decide whether the path should be public, private internet egress, private Oracle-services access, or private hybrid transport.
  3. Confirm the route target and route propagation story.
  4. Confirm filtering with NSGs, security lists, or upstream inspection.
  5. Check DNS resolution and resolved endpoint only after the path exists.

Network boundary table

Boundary What it really answers Do not confuse it with
route table where traffic is sent whether traffic is permitted
NSG or security list whether traffic is allowed how traffic reaches a destination
gateway which network boundary is crossed DNS or name resolution
DNS which target name resolves to route selection or filtering
subnet where resources live and which route table/security context applies IAM or compartment policy
DRG attachment which network joins the private routing hub end-to-end firewall logic

Gateway and path map

    flowchart TD
	  Internet["Internet"] --> IGW["Internet Gateway"]
	  Private["Private Subnet"] --> NAT["NAT Gateway"]
	  Private --> SGW["Service Gateway"]
	  OnPrem["On-Premises or Other Network"] --> DRG["DRG"]
	  DRG --> Private

Fast rule: choose the traffic path first, then decide which control filters it.

Gateway chooser

You need… Strongest first fit Why
public internet ingress or egress Internet Gateway direct public edge path
private subnet outbound internet only NAT Gateway egress without public IP on the instance
private access to Oracle services Service Gateway stay off the public internet for Oracle services
on-premises or cross-VCN routing hub DRG attachment-based private routing control
private subnet outbound internet only NAT Gateway no inbound internet exposure
public edge ingress to a service Internet Gateway plus edge/load-balancing design explicit public entry point

Subnet and route reminders

Topic Fast rule
public subnet route to Internet Gateway plus public-IP-bearing resources where appropriate
private subnet no direct internet ingress path by design
route table chooses next hop; wrong route can break a valid architecture
multiple route tables useful when tiers need different network behavior
overlapping CIDRs create peering, routing, and migration pain
compartment governance boundary, not packet path

NSGs versus Security Lists

You need… Strongest first fit Why
simple subnet-wide filtering Security Lists broader subnet boundary
granular workload-level control NSGs narrower app or workload scope
least-privilege tiering NSGs easier to model app-specific traffic

Filtering and inspection traps

Trap Better reading
using security lists for every tier because they are already there NSGs often express workload boundaries more cleanly
changing both NSGs and security lists blindly change the narrowest layer that owns the traffic rule
using routes as a security boundary routes send packets; filters and inspection decide what is allowed
forgetting return traffic logic both directions of the flow still matter
assuming private path means safe path private reachability is not least privilege by itself

Path and control order

Ask this first Then ask this
does a valid path exist to the target do rules permit the traffic on that path
is the path private or public by design is the workload attached to the correct gateway or DRG route
does the name resolve to the intended endpoint do filters permit the resolved destination

Connectivity chooser

Requirement Strongest first fit Why
lower-cost quick private setup IPSec VPN simpler hybrid path
steadier bandwidth and lower-latency expectations FastConnect dedicated private connectivity
centralized routing for many attachments DRG hub-and-spoke cleaner route control
many VCNs with centralized inspection or shared services DRG-centered architecture clearer network governance
OCI service access without internet traversal Service Gateway private Oracle-services path

Hybrid and private-path traps

Trap Better reading
choosing FastConnect automatically because it sounds more professional choose it for throughput, predictability, and hybrid scale needs
treating DRG like the private link itself DRG is the routing hub, not every underlying path
debugging application firewalls before proving the private route exists path first, filter second
assuming VPN and FastConnect are interchangeable except for price path stability, throughput, and enterprise expectations differ
forgetting route propagation and attachment state DRG design is more than creating the object

DRG and hybrid reminders

Topic Fast rule
DRG private-routing hub for attachments and transit patterns
attachment how a VCN or external network participates in DRG routing
propagation/import/export route learning and distribution logic matter to reachability
on-prem path transport plus route plus filter must all align
transit design central hub patterns simplify many-network connectivity but raise design responsibility

Path and control traps

Trap Better reading
using route tables as if they filter traffic routes choose path; NSGs and Security Lists filter traffic
treating DRG like a generic security control DRG is a routing hub, not a firewall
exposing resources publicly because private connectivity is “harder” strong answers keep exposure deliberate
choosing Security Lists automatically for all workloads workload-level control often points to NSGs
mixing subnet placement with IAM policy scope network placement and authorization are separate concerns
forgetting service dependencies such as DNS or load balancer health path success depends on multiple layers

Load balancing and edge reminders

Need Stronger first fit
public app entry point public load balancer with private backends
internal tier distribution private load balancer
backend availability health checks plus multiple backends
TLS or edge control explicit edge or load-balancing/security design
avoid single-instance exposure place the load balancer at the edge, not the app host

DNS and name-resolution reminders

Topic Fast rule
private endpoint private DNS must resolve to the private target
public endpoint public DNS and public path must align
split-horizon behavior internal and external clients may need different answers
hostname success does not prove the route or filters are correct
service discovery naming choices can hide the real path if you do not test resolution

DNS and troubleshooting order

Step What to verify
route route tables, attachments, and intended next hop
filter NSGs and Security Lists
name resolution DNS records and resolved targets
gateway state IGW, NAT, Service Gateway, or DRG configuration
backend health load balancer target status if traffic should be distributed

Private-path troubleshooting table

Symptom First checks
private instance cannot reach the internet route to NAT, subnet type, and egress policy
private workload cannot reach Oracle service service gateway path and relevant route attachment
on-premises cannot reach OCI subnet DRG attachment, route propagation, and hybrid path state
hostname works publicly but not privately DNS view and resolved target versus intended private endpoint
load balancer listener is up but app fails backend health, NSG/security list, route, and app port reachability
one subnet works and another fails subnet-specific route table and security differences

Troubleshooting traps

Trap Better reading
restarting instances before checking routes and filters path logic should be verified first
checking only one control plane route, security, DNS, and gateway state all interact
blaming DNS when the private path is missing confirm the network path exists first
blaming gateways when the resolved endpoint is wrong DNS can send traffic to the wrong target
forgetting health checks and backend sets traffic distribution failures are not always route failures

High-confusion pairs

Pair Keep this distinction clear
route table vs NSG path selection versus packet filtering
NSG vs security list workload-scoped control versus subnet-wide control
NAT Gateway vs Internet Gateway outbound-only access for private subnets versus public edge access
Service Gateway vs NAT Gateway private Oracle-service access versus general outbound internet egress
DRG vs VPN or FastConnect routing hub versus private transport mechanism
DNS failure vs path failure name resolution issue versus missing route or blocked traffic
subnet vs compartment network placement versus governance scope
load balancer vs gateway traffic distribution/control point versus path boundary crossing

Decision order that usually wins

  1. Classify the issue as subnet placement, route/path, filter, DNS, hybrid transport, or load balancing.
  2. Choose the intended public/private path before touching security rules.
  3. Verify route target, DRG attachment state, or gateway type.
  4. Verify filters and only then verify DNS resolution to the intended endpoint.
  5. For distributed traffic, check backend health and listener/backend mapping before changing the network design.

Last 15-minute review

If you only keep one thing from each lane… Remember this
gateways IGW public, NAT outbound only, SGW Oracle services, DRG private routing hub
filtering NSGs narrow, Security Lists broad
connectivity VPN and FastConnect solve different private-path needs
troubleshooting route, filter, DNS, gateway
architecture keep public edge and private lanes deliberate
subnet vs compartment placement boundary versus governance boundary
load balancing a healthy path still needs healthy backends

What strong 1Z0-1124-25 answers usually do

  • classify the issue first as path construction, filtering, private connectivity, or name resolution
  • separate routing decisions from security-control decisions
  • choose the narrowest network control that still solves the problem cleanly
  • keep public exposure deliberate instead of mixing public and private responsibilities casually
  • verify DRG, route propagation, DNS, and backend health instead of guessing at the failing layer
  • keep hybrid transport choice tied to reliability and throughput needs, not branding
Revised on Monday, June 15, 2026
Study Plan
Sample Questions