Use this for last-mile review. Keep it open while drilling mixed foundations questions, and pair it with the Resources when you need the official Oracle wording. Foundations questions usually reward clean classification: identity, governance, network path, service fit, visibility, cost, or resilience.
Read every foundations stem in this order
- Decide whether the stem is asking for identity, networking, compute, storage, database, observability, cost, or security.
- Identify the boundary: tenancy, compartment, VCN, subnet, route table, NSG, security list, or service.
- Choose the simplest OCI service that directly matches the requirement.
- Avoid answers that solve governance with networking, or networking with IAM.
- Check whether the wording asks for visibility, auditability, cost control, or availability.
OCI foundations control map
flowchart TD
T["Tenancy"] --> C["Compartments"]
T --> B["Billing, Budgets, Tags"]
C --> I["IAM Policies"]
C --> N["VCNs, Subnets, Gateways"]
C --> S["Compute, Storage, Databases"]
T --> A["Audit, Monitoring, Logging"]
Read it like this: tenancy is the account boundary, compartments organize and scope governance, and networking controls still live in the VCN/subnet/resource lanes rather than replacing IAM.
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 idea |
| who can do something |
IAM users, groups, policies, dynamic groups |
identity and permission scope first |
| where a resource belongs |
tenancy vs compartment |
compartment is a logical governance boundary |
| how traffic gets somewhere |
route table plus gateway choice |
path first, filter second |
| which storage service fits |
object vs block vs file vs archive |
access pattern and cost first |
| visibility and compliance |
monitoring, logging, audit, budgets, tags |
observe first, then enforce |
| how a workload should run |
VM, bare metal, OKE, or Functions |
management model and runtime shape first |
| how to reduce blast radius |
compartments, least privilege, private tiers |
narrow scope before adding services |
Core OCI vocabulary
| Term |
What it is |
Exam-safe memory cue |
| Tenancy |
top-level OCI account boundary |
identity and billing start here |
| Compartment |
logical container for governance and access |
not a subnet and not a VCN |
| Region |
geographic deployment area |
contains one or more ADs |
| Availability Domain |
isolated data center grouping in a region |
regional resilience building block |
| Fault Domain |
failure-isolation grouping within an AD |
rack/power-style separation cue |
| VCN |
software-defined network |
holds subnets, route tables, security controls |
| Policy |
human-readable IAM permission statement |
who can do what in which scope |
| Dynamic Group |
rule-based group of OCI resources |
lets resources call OCI APIs through policy |
| Resource Principal |
resource identity used by OCI services |
avoids embedding user credentials |
| Tag |
metadata for organization and cost attribution |
not a permission by itself |
Tenancy, compartments, and IAM
Identity primitives
| You need… |
Use… |
Why |
| human administrator access |
users, groups, policies |
classic identity path |
| service or instance access to OCI resources |
dynamic groups and policies |
avoids hard-coded user credentials |
| least-privilege scope |
inspect, read, use, manage |
do not over-grant by default |
| governance separation by team or project |
compartments |
clean policy and budget scope |
| temporary application access |
service-specific identity or resource principal pattern |
avoid human credentials in apps |
| cost or ownership reporting |
tags and budgets |
governance is not just security |
Policy pattern to remember
1Allow group <group-name> to <verb> <resource-type> in compartment <compartment-name>
IAM traps
| Trap |
Better answer |
| calling a compartment a network boundary |
call it a governance and access boundary |
| solving every machine-to-machine problem with users and API keys |
prefer dynamic groups when the principal is an OCI resource |
choosing manage when the task only requires use or read |
keep verbs as narrow as possible |
| forgetting scope |
ask whether the policy belongs in tenancy or a specific compartment |
| expecting tags to grant access |
tags organize and report; policies grant access |
| treating federation as a network feature |
federation is identity integration |
IAM decision reminders
| Question wording |
Stronger first thought |
| “view resources” |
inspect or read level, not manage |
| “use a resource” |
use may fit without full administration |
| “administer resources” |
manage, but scope it carefully |
| “OCI resource needs access” |
dynamic group plus policy |
| “central corporate login” |
identity federation |
Networking basics that keep showing up
Traffic path chooser
| Requirement |
Prefer |
Why |
| public internet ingress and egress |
Internet Gateway |
public connectivity path |
| outbound internet from private subnet only |
NAT Gateway |
no inbound initiation from internet |
| private access to Oracle services |
Service Gateway |
avoids public internet path |
| routing between VCNs or to on-premises |
DRG |
routing hub attachment |
| private workload name resolution |
DNS/private zone/resolver path |
names must resolve to the intended endpoint |
Security control chooser
| You need… |
Prefer |
Why |
| coarse subnet-wide rules |
Security Lists |
simple, subnet-oriented control |
| granular app-tier or instance-tier rules |
NSGs |
cleaner for multi-tier designs |
| traffic destination logic |
Route Table |
decides where packets go |
| traffic allow or deny logic |
Security Lists or NSGs |
decides whether packets are permitted |
| public application entry |
public load balancer or edge path |
expose the edge, not every backend |
| private backend tier |
private subnet plus security controls |
keep internal tiers internal |
Networking traps
| Trap |
Better answer |
| using route tables to block traffic |
route tables pick destinations; security controls filter |
| treating NAT Gateway like a public ingress component |
NAT is outbound-only for private subnets |
| using Service Gateway for generic internet access |
it is for Oracle services, not the public web |
| mixing compartment design with VCN path design |
keep governance scope and network path as separate decisions |
| putting databases in public subnets for admin convenience |
use private placement and safer management paths |
| changing security rules before route tables |
path first, filter second |
Gateway quick map
| Gateway |
Fast memory cue |
| Internet Gateway |
public internet route for public resources |
| NAT Gateway |
private subnet outbound internet |
| Service Gateway |
private route to supported Oracle services |
| DRG |
private routing hub for VCN, on-prem, VPN, and FastConnect patterns |
| Local Peering Gateway |
VCN-to-VCN local peering path |
Compute, storage, and database service picks
Storage chooser
| Requirement |
Prefer |
Why |
| logs, backups, images, data lake objects |
Object Storage |
durable object access |
| low-cost long-term retention |
Archive Storage |
archive economics over retrieval speed |
| VM boot or attached data disks |
Block Volumes |
block device for compute |
| shared POSIX-style file system |
File Storage |
shared filesystem semantics |
| immutable or versioned object retention needs |
Object Storage features |
object-level durability and policy lane |
| Requirement |
Prefer |
Why |
| general virtual machines |
Compute VM instances |
default compute answer |
| dedicated host-style performance |
bare metal shapes |
no hypervisor sharing cue |
| managed Kubernetes |
OKE |
container orchestration answer |
| managed serverless-style functions |
Functions |
event-driven code without server management |
| predictable isolated hardware |
bare metal shapes |
isolation/performance cue |
| scalable stateless pool |
compute pool/autoscaling style answer |
replaceable compute pattern |
Database chooser
| Requirement |
Prefer |
Why |
| Oracle-managed automation focus |
Autonomous Database |
simplified management path |
| more direct configuration control |
DB System |
more hands-on database administration |
| broad foundations exam question |
choose by management model first |
that is usually the real distinction |
| simple key-value or document access |
NoSQL-style service where described |
access pattern drives the fit |
| MySQL workload |
MySQL HeatWave / MySQL service lane where named |
match database engine to requirement |
Service-selection traps
| Trap |
Better answer |
| choosing Kubernetes for every container |
use OKE only when orchestration is actually needed |
| using Object Storage for block-device behavior |
object, block, file, and archive have different access models |
| using Archive Storage for frequently accessed data |
archive optimizes retention cost, not quick access |
| choosing DB System when reduced administration is explicit |
Autonomous Database is often the foundations-level fit |
| choosing Functions for long-running server-style workloads |
Functions are event-driven, not a generic VM replacement |
Observability, governance, and cost control
| Need |
Service or concept |
What to remember |
| metric thresholds and alerts |
Monitoring and Alarms |
detect and notify |
| centralized event records and troubleshooting |
Logging |
operational visibility |
| API call history for compliance |
Audit |
who did what and when |
| cost guardrails |
Budgets |
spend awareness and alerts |
| ownership and cost attribution |
Tags |
reporting and organization |
| resource state reactions |
Events |
trigger action from state changes |
| security posture |
Cloud Guard-style findings |
detect risky configuration |
Governance traps
| Trap |
Better answer |
| treating Audit as performance monitoring |
Audit is API activity history |
| treating tags as access control |
tags help organization and cost attribution, not permission by themselves |
| skipping budgets because the exam is “technical” |
foundations questions often blend service knowledge with governance and cost control |
| using Audit for app performance troubleshooting |
audit is control-plane activity, not app telemetry |
| expecting budgets to prevent all spend |
budgets alert and support governance; design still controls cost |
Pricing and support reminders
| Topic |
Fast rule |
| consumption model |
many cloud costs track actual usage, capacity, storage, transfer, or requests |
| budgets |
alert and manage awareness |
| tags |
attribute spend and ownership |
| right-sizing |
match shape/service to actual workload |
| support |
support plan and documentation are part of cloud operations, not service architecture |
Availability basics
| Requirement |
Better answer |
| avoid single-point placement inside a region |
spread across fault domains or availability domains as appropriate |
| improve app resilience |
use load balancing and health checks |
| improve recoverability |
ensure backups and durable storage choices are in place |
| regional disaster recovery |
use cross-region planning and tested recovery path |
| reduce data loss |
match backup or replication to recovery point needs |
Security and shared responsibility basics
| Concern |
Better first lane |
| who can administer resources |
IAM policies and compartments |
| whether packets are allowed |
NSGs or security lists |
| whether traffic has a route |
route table and gateway |
| protecting data |
encryption, keys, least privilege, and backup |
| proving activity |
Audit and logs |
Decision order that usually wins
- Classify the service lane before picking a product name.
- Separate tenancy, compartment, VCN, subnet, and policy boundaries.
- Choose route/gateway before security filtering in network questions.
- Choose storage/database/compute by access pattern and management model.
- Add visibility, budget, tags, audit, and resilience when the stem asks for operations or governance.
Last 15-minute review
| If you forget everything else… |
Remember this |
| tenancy vs compartment |
tenancy is the account boundary; compartments are logical governance containers |
| route vs filter |
route tables choose the path, security controls allow or deny |
| IGW vs NAT vs Service Gateway |
public internet, private outbound internet, private Oracle-services access |
| object vs block vs file vs archive |
objects, attached disks, shared filesystem, cheap retention |
| monitoring vs logging vs audit |
metrics and alarms, log records, API activity history |
| Autonomous vs DB System |
managed automation versus direct database control |
| tags vs policies |
organization/cost metadata versus authorization |
What strong 1Z0-1085-25 answers usually do
- classify the question as identity, network path, service selection, or governance first
- choose the simplest OCI-native service that directly matches the requirement
- separate compartment scope, IAM permission, and network path instead of blending them
- avoid overpowered answers when a narrower service or narrower permission is enough
- use service purpose and boundary language instead of generic cloud intuition
- keep cost, visibility, and availability in scope when the stem asks for operations