Use this for last-mile review. Keep it open during mixed OCI developer questions and pair it with the Resources when you want Oracle’s exact service wording.
1Z0-1084-25 usually gets easier when you classify the stem in this order:
- Identity lane: how should code authenticate?
- Interaction lane: synchronous API, asynchronous event, stream processing, or workflow coordination?
- Execution lane: API Gateway, Functions, Events, Notifications, Streaming, or CLI and SDK automation?
- Reliability lane: retries, idempotency, timeout, duplicate delivery, and operational visibility?
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 |
| how code authenticates |
user key vs instance principal vs resource principal |
avoid long-lived credentials when OCI can supply identity |
| exposing a synchronous API |
API Gateway and backend auth path |
front door and auth boundary first |
| async fan-out or decoupling |
events, notifications, or streaming |
classify delivery semantics before coding |
| retries and duplicate effects |
idempotency and safe handlers |
assume retries and at-least-once behavior |
| CLI or SDK automation |
compartment scope, auth choice, and error handling |
operational safety matters as much as feature logic |
Identity chooser
| Runtime situation |
Strongest first fit |
Why |
| developer machine or local script |
user API signing key |
normal human-driven tooling path |
| code running on OCI compute |
instance principal |
avoids embedded runtime secrets |
| code running inside an OCI service boundary |
resource principal |
service-native identity lane |
| one-off troubleshooting by a developer |
explicit user-scoped auth |
keeps human and workload identity separate |
Auth chooser
| You are building… |
Strongest first fit |
Why |
| local tooling or developer automation |
user API signing key |
normal developer path |
| code running on OCI compute |
instance principal |
avoids embedded keys |
| code running inside an OCI service boundary |
resource principal |
service-native identity path |
Identity-boundary table
| Boundary |
What it really answers |
Do not confuse it with |
| user API key |
human or local-tool authentication |
safe default for production runtime code |
| instance principal |
identity of code on OCI compute |
the permission policy itself |
| resource principal |
identity inside OCI service context |
a general external user credential |
| compartment scope |
where access should apply |
how authentication happens |
Auth traps
| Trap |
Better reading |
| keeping long-lived credentials because “it’s easier” |
use instance or resource principals when OCI can provide identity |
| solving compartment-scope mistakes with more code |
auth choice and compartment scope are separate decisions |
| treating user API keys as the default for all workloads |
user keys are not the strongest runtime default |
Interaction-mode chooser
| Requirement |
Strongest first lane |
Why |
| caller waits for a response |
synchronous API path |
response is part of the same interaction |
| react to a platform or app event |
Events |
trigger-based routing |
| notify many receivers |
Notifications |
lightweight fan-out delivery |
| durable ordered event processing |
Streaming |
stronger durability and sequencing semantics |
| small stateless compute glue |
Functions |
execution boundary, not full workflow platform |
| many-step business flow |
workflow orchestration |
better state and failure control |
Service composition map
flowchart TD
Client["Client"] --> Gateway["API Gateway"]
Gateway --> Function["Functions or Backend Service"]
Function --> Events["Events"]
Events --> Notify["Notifications"]
Function --> Stream["Streaming or Async Work"]
Stream --> Worker["Consumers or Follow-On Processing"]
API, event, and async chooser
| Requirement |
Strongest first fit |
Why |
| secure synchronous API entry point |
API Gateway |
controlled front door |
| lightweight event-driven logic |
Functions |
small compute glue path |
| react to OCI or application events |
Events |
event routing lane |
| simple fan-out to recipients |
Notifications |
pub/sub notification path |
| ordered or durable event stream |
Streaming |
stronger stream semantics than simple notification fan-out |
Service-boundary table
| Service |
What it really answers |
Do not confuse it with |
| API Gateway |
controlled ingress and policy front door |
backend business logic |
| Functions |
short compute handler or glue |
full workflow engine |
| Events |
trigger source and routing |
durable queue or stream by itself |
| Notifications |
fan-out delivery |
ordered durable processing |
| Streaming |
retained ordered event path |
simple notification blast |
Retry and delivery rules
| Concern |
Better rule |
| duplicate delivery |
design handlers to be idempotent |
| transient failures |
use backoff and safe retries |
| poison or unrecoverable work |
isolate failure path rather than looping forever |
| auditability |
log enough correlation context to debug replay and failure |
Reliability table
| Symptom |
Strongest first check |
| repeat side effects after retry |
idempotency boundary and duplicate-handling logic |
| transient dependency failure |
timeout, retry policy, and backoff |
| bad payload keeps failing |
isolate, quarantine, or dead-letter the path |
| async processing seems unordered |
verify whether the chosen service even guarantees the needed ordering |
Event and retry traps
| Trap |
Better reading |
| assuming one event means one and only one execution |
plan for retries and duplicate delivery |
| using notifications as full workflow orchestration |
notifications fan out; they do not replace workflow control |
| writing handlers that break on repeat invocation |
safe retries are a design requirement |
| ignoring compartment or auth scope in event-driven systems |
service composition still depends on identity and access boundaries |
Automation and developer-operations cues
| If the question is mainly about… |
Strongest first lane |
| repeated resource changes |
CLI or SDK automation with explicit scope and error handling |
| safe scripting |
retries, logging, and small reversible actions |
| secret handling |
Vault instead of checked-in or embedded values |
| runtime diagnostics |
correlation IDs, logs, and basic metrics |
CLI and SDK quick rules
| If the question is mainly about… |
Strongest first lane |
| resource lookup or management |
correct compartment scope first |
| automation safety |
retries, logging, and explicit error handling |
| runtime auth for code |
instance or resource principal where possible |
| developer machine workflow |
user API key and explicit CLI/SDK config |
Functions and operations cues
| Area |
Strong default |
| secrets |
Vault, not values embedded in code or checked-in config |
| troubleshooting |
correlation IDs, logs, and basic metrics |
| safe release |
small blast radius and clear rollback path |
| runtime behavior |
assume retries, latency spikes, and external dependency failures |
High-confusion pairs
| Pair |
Keep this distinction clear |
| user API key vs instance principal |
human or local-tool auth versus workload runtime identity |
| API Gateway vs Functions |
ingress boundary versus execution logic |
| Events vs Notifications |
trigger routing versus lightweight fan-out delivery |
| Notifications vs Streaming |
basic delivery versus durable ordered event handling |
| retry vs idempotency |
repeated attempt versus safe repeated effect |
Last 15-minute review
| If you only keep one thing from each lane… |
Remember this |
| auth |
instance or resource principals beat long-lived runtime credentials |
| API flow |
API Gateway is the front door, not the business logic engine |
| async flow |
choose events, notifications, or streaming by delivery semantics |
| retries |
idempotency is not optional |
| operations |
secrets, logs, and rollback still matter in “developer” questions |
What strong 1Z0-1084-25 answers usually do
- identify whether the problem is synchronous API flow, async delivery, or workflow safety first
- choose the OCI-native auth path that minimizes long-lived credentials
- separate transport, execution, and retry concerns instead of mixing them together
- treat safe retry and operational visibility as design requirements, not cleanup work