Browse Oracle Certification Guides

OCI 1Z0-997-25 Cheat Sheet

December 13, 2025

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

On this page

Use this for last-mile review. This exam rewards architectures that stay correct under failure, growth, and change, not just architectures that look powerful on paper.

1Z0-997-25 usually gets easier when you classify the question in this order:

  1. Continuity lane: HA, DR, backup, RTO, and RPO.
  2. Boundary lane: region, compartment, VCN, subnet, or edge placement.
  3. Control lane: keys, IAM, network controls, logging, and automation.
  4. Operability lane: observability, rollback, scaling, and repeatable change.

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
service continuity target RTO and RPO recovery objective before service choice
many-network design hub-and-spoke routing and segmentation centralize path logic without widening blast radius
security architecture compartment, network, key, and audit layering controls should reinforce each other
cost versus resilience simplest design that still meets continuity goals do not overbuild
change risk rollback, observability, and repeatability architecture includes day-2 control
landing-zone design tenancy, compartments, identity, network, tags governance first, services second
multi-region design data replication, DNS, runbook, and test evidence failover must be executable

Read every professional-architecture stem in this order

  1. Identify the business target: availability, recovery, residency, scale, security, cost, or operations.
  2. Locate the boundary: tenancy, compartment, region, VCN, subnet, identity, key, or data tier.
  3. Choose the smallest architecture that satisfies the target with explicit failure handling.
  4. Add observability, automation, policy, and rollback before calling it production-ready.
  5. Reject answers that make one control plane solve every concern.

Continuity chooser

Requirement Strongest first reading Why
tolerate local component or availability-domain failure HA keep service running inside the active design
recover from larger-site or region loss DR separate recovery design from local redundancy
restore lost data or state after corruption backup and restore backups do not equal active failover
explicit time and data-loss target map RTO and RPO first objectives should drive service choice
survive regional failure multi-region DR design local HA is not regional recovery
prove recovery readiness test and evidence untested failover is only an assumption

Enterprise architecture map

    flowchart TD
	  RegionA["Primary Region"] --> Replicate["Replication and Sync Path"]
	  Replicate --> RegionB["Secondary Region"]
	  RegionA --> Edge["Public Edge and App Tiers"]
	  RegionA --> Data["Protected Data Tier"]
	  RegionB --> Standby["Standby / Recovery Path"]
	  Edge --> Observe["Monitoring, Audit, Automation"]
	  Standby --> Observe

Fast rule: if the stem cares about strict continuity, your answer should make replication, failover, and observability explicit rather than implied.

Landing-zone baseline

Area Strong professional answer includes
identity federation or clear user lifecycle plus least-privilege groups
compartments environment, workload, data sensitivity, or ownership boundaries
network VCN strategy, subnet tiers, route tables, gateways, DRG, DNS
security keys, secrets, logging, audit, Cloud Guard-style posture controls
operations tagging, budgets, monitoring, runbooks, automation, break-glass path
deployment repeatable IaC or Resource Manager-style change path

Landing-zone traps

Trap Better reading
starting with a workload before governance exists professional architecture needs guardrails first
one shared compartment for everything blast radius and least privilege become unclear
network design without DNS and logging path success and operations evidence both matter
manual console build for repeatable environments repeatability and drift control are part of architecture

HA, DR, and recovery chooser

Question Stronger first reading
what must stay running during smaller failures HA inside the primary design
what survives larger environment loss DR architecture and failover plan
how much data can be lost RPO
how fast service must return RTO
whether the plan is trustworthy tested failover and recovery runbook
where failover happens AD, region, or external site boundary
how users reconnect DNS, load balancer, traffic manager, or app routing plan

Recovery traps

Trap Better reading
assuming backups alone solve DR backups and DR are related but not identical
treating replication as a complete recovery plan failover procedure and verification still matter
oversizing the architecture without checking the actual target continuity target should drive complexity, not fear
active-active chosen by reflex conflict handling, cost, and operations complexity may exceed need
no failback plan return-to-normal is part of recovery architecture

Multi-region DR checklist

Area What to define
data replication method, consistency, lag, and recovery point
compute standby capacity, image/artifact source, scaling process
network cross-region routing, DNS, and security rules
identity operator and workload access during failover
runbook failover trigger, owner, steps, verification, failback
evidence test history and measurable RTO/RPO results

Blast-radius and placement table

Boundary What it should help you control
region large failure domain and residency boundary
compartment governance and administrative scope
VCN or subnet segmentation traffic isolation and workload separation
public edge tier deliberate exposure and traffic entry
protected data tier narrower access path and stronger control layering
key vault / key scope encryption responsibility and blast radius
automation scope how far one template or pipeline can change production

Networking and blast-radius control

Concern Strongest first fit
many VCNs and shared services DRG-centered hub-and-spoke
clear segmentation isolate by function, environment, and blast radius
safe public exposure keep edge services deliberate and separate from private tiers
controlled route logic route tables for path, NSGs or security lists for filtering
centralized inspection transit design with explicit routing and inspection points
hybrid enterprise path DRG plus VPN or FastConnect based on throughput and reliability

Segmentation traps

Trap Better reading
centralizing everything into one wide-trust network hub-and-spoke should still preserve narrow boundaries
public entry directly into sensitive tiers edge and private tiers should stay distinct
assuming DRG centralization solves governance routing convenience does not replace segmentation discipline
every spoke can talk to every spoke by default hub-and-spoke still needs route and security intent
one route table for every tier different tiers often need different paths

Networking traps

Trap Better reading
using route tables like security controls routes decide path; filtering controls decide access
exposing internal services publicly for convenience strong answers keep private tiers private
centralizing everything without segmentation central routing is not a license to collapse boundaries
ignoring DNS in private designs names must resolve to the intended private endpoint
confusing load balancing with routing hub design distribution and transit are different jobs

Security architecture cues

Missing piece Why it weakens the answer
clear compartment boundaries governance and least privilege become muddy
key management and encryption plan data protection is incomplete
audit and logging baseline incidents become harder to investigate
rollback or recovery plan production change risk stays unmanaged
secret lifecycle credentials become unmanaged operational risk
break-glass control emergency access becomes either impossible or overbroad

Layered-control table

Layer Main job Do not confuse it with
compartment and IAM design who can manage or access what network filtering
network controls which paths and packets are allowed encryption at rest
keys and encryption protect data and sensitive operations user-role scoping
audit and logging prove and investigate actions active traffic blocking
automation and policy make changes repeatable and guardrailed manual recovery improvisation

Identity, key, and data-boundary traps

Trap Better reading
encryption mentioned, key ownership ignored key control and rotation are part of the design
broad admin role used for automation automation needs least privilege too
logs centralized but not protected evidence stores need access control and retention
data copied for analytics without governance copies inherit sensitivity and residency concerns
audit exists only in one compartment professional designs consider full investigation scope

Service-selection reminders

Requirement Stronger first instinct
reduce database admin burden managed/autonomous database service when it meets constraints
precise database control DB system or lower-level option when required
stateless scale load-balanced compute or container platform
event-driven glue functions/events-style service where lifecycle is short
durable object data object storage with lifecycle and access controls
shared POSIX-style access file storage pattern
block-device semantics block volume pattern

Service-selection traps

Trap Better reading
choosing the most powerful service by default choose the simplest service that meets constraints
managed service assumed to solve governance identity, network, keys, audit, and backup still matter
Kubernetes for every container problem operational burden must be justified
database scaling before query and connection review diagnose bottleneck before increasing capacity

Cost and operability cues

Pressure Better first move
high cost under stable load right-size and simplify before adding more HA complexity
too much operations burden prefer managed services when they reduce risk materially
unclear runtime health improve observability before broad redesign
hidden egress or duplication trace cross-zone, cross-region, and duplicated data paths
too many bespoke environments standardize landing-zone modules and policies
large DR cost align standby posture to actual RTO and RPO

Day-2 operations table

Day-2 concern Strong architect answer usually includes
deployment risk rollback path and tested change procedure
incident triage metrics, logs, alerts, and ownership clarity
scale growth predictable scaling boundary and cost visibility
recovery confidence tested failover or restore workflow
drift control IaC state, policy checks, and change review
compliance evidence audit trails, log retention, and periodic access review

Automation and change-control map

Need Stronger first answer
repeatable environment IaC / Resource Manager-style template
guardrail enforcement policy, tagging, and approval workflow
safe rollout staged deployment plus rollback path
drift detection state comparison and controlled remediation
emergency access audited break-glass process

Decision order that usually wins

  1. Start from the business objective and failure target.
  2. Choose region, compartment, network, identity, and data boundaries deliberately.
  3. Match HA, DR, backup, and replication to the actual RTO and RPO.
  4. Layer IAM, network controls, keys, audit, and automation instead of relying on one control.
  5. Prove the design through monitoring, tests, runbooks, and cost ownership.

Last 15-minute review

If you only keep one thing from each lane… Remember this
continuity RTO and RPO should drive the architecture
networking central routing and narrow segmentation should work together
security compartment, network, keys, and audit belong together
cost scale safely first, then optimize spend
operations observability and rollback are part of architecture, not just operations
landing zone governance, network, identity, and logging come before workload sprawl
multi-region replication plus runbook plus test evidence equals credible DR

High-confusion pairs

Pair Keep this distinction clear
HA vs DR keep running through smaller failures versus recover from larger environment loss
DR vs backup failover or recovery design versus stored recovery data
route design vs security design path selection versus access control
compartment boundary vs subnet boundary governance scope versus traffic-isolation scope
replication vs tested recovery data movement versus verified failover behavior
load balancer vs DRG traffic distribution versus routing hub
encryption vs key governance protected data versus controlled key ownership and rotation

What strong 1Z0-997-25 answers usually do

  • classify the problem first as placement, network, resilience, or automation and control
  • choose the simplest architecture that still reduces blast radius and supports recovery
  • separate operational control from pure infrastructure capability
  • prefer answers that preserve observability, repeatability, and clear failure handling
  • keep landing-zone governance visible even in service-specific scenarios
  • tie every added complexity to a stated risk, recovery target, or operating requirement
Revised on Sunday, May 10, 2026
Study Plan
Sample Questions