OCI 1Z0-1084-25 FAQ for exam format, topics, prep strategy, practice, and common candidate traps.
This exam is about service-composition judgment. Strong answers usually decide how code authenticates, whether the interaction is synchronous or asynchronous, which OCI service owns the execution boundary, and how retries stay safe.
| Question | Short answer |
|---|---|
| What is the most important skill? | Classifying auth, interaction, execution, and retry behavior before naming a service. |
| Do I need to be a strong programmer? | You need practical OCI developer instincts more than algorithm-heavy coding depth. |
| What does the exam punish most? | Mixing ingress, execution, orchestration, and delivery semantics into one vague answer. |
| What hands-on work matters most? | One believable path from auth -> API or event -> function or consumer -> retry-safe completion. |
| What should I trust if notes disagree? | The current Oracle exam page and OCI product documentation. |
The highest-yield skill is service-boundary classification.
Questions usually get easier when you decide which lane owns the problem:
| Lane | What it is really testing |
|---|---|
| identity | how code authenticates and where permissions should apply |
| interaction | synchronous API, event trigger, notification, or stream |
| execution | API Gateway, Functions, SDK or CLI automation, or consumer logic |
| reliability | timeout, retry, duplicate delivery, logging, and rollback-safe behavior |
No. You do need enough engineering discipline to reason about runtime behavior.
| Skill area | Why it matters here |
|---|---|
| auth choice | user API keys, instance principals, and resource principals are not interchangeable |
| service composition | API Gateway, Functions, Events, Notifications, and Streaming have different jobs |
| retry safety | at-least-once behavior means idempotency is a design requirement |
| operational feedback | logs, correlation IDs, and failure-path handling still matter in developer questions |
It punishes answers that name a service without proving why it is the right boundary.
Common traps:
| Trap | Better reading |
|---|---|
| “Functions solves the whole workflow.” | Functions is an execution unit, not automatically the orchestration layer. |
| “Notifications and Streaming are basically the same.” | Notifications is lightweight fan-out; Streaming is durable ordered event flow. |
| “Retry is enough.” | Retry decides whether you try again; idempotency decides whether retry is safe. |
| “User API keys are the default runtime path.” | OCI-native workload identity usually beats long-lived credentials. |
You do not need a huge OCI lab. You need one believable developer path.
Route the miss by lane.
| If your misses sound like… | Weak lane | Fix next |
|---|---|---|
| “I picked the wrong credential pattern.” | identity | review user API keys vs instance principals vs resource principals |
| “I chose the wrong integration service.” | interaction | review synchronous API vs event routing vs notifications vs streaming |
| “I used Functions for everything.” | execution boundary | review ingress, handler, workflow, and consumer responsibilities |
| “I forgot retries can duplicate side effects.” | reliability | review idempotency, backoff, and replay-safe design |
Use this order:
1Z0-1084-25If a summary sounds cleaner than the Oracle source, downgrade it.
Do less broad reading and more classification practice.
| Keep doing | Stop doing |
|---|---|
| rereading the cheat sheet and glossary | opening unrelated new frameworks or SDKs |
| reviewing auth and service-boundary confusion pairs | treating all async services like one bucket |
| checking Oracle docs for disputed behavior | building a large late-stage OCI project |
| practicing auth -> interaction -> execution -> reliability order | trusting unsupported community summaries over Oracle docs |