OCI 1Z0-1111-25 FAQ for exam format, topics, prep strategy, practice, and common candidate traps.
This exam is about visibility and diagnosis judgment. Strong answers usually choose the right signal first, then decide how it should be routed, analyzed, and acted on without creating noise, blind spots, or weak incident flow.
| Question | Short answer |
|---|---|
| Do I need deep SRE experience? | No, but you need strong instincts about what to measure, what to alert on, and how to reduce detection and recovery time. |
| What is the highest-yield area? | Signal selection plus alert quality and routing discipline. |
| What does the exam punish most? | Collecting or alerting on everything without improving diagnosis or response. |
| What hands-on work matters most? | Small realistic exercises covering metrics, logs, APM, alert routing, and noisy-alert cleanup. |
| What should I trust if notes disagree? | The current Oracle exam page and OCI observability documentation. |
No. The exam is observability-focused, but it does not assume expert SRE depth. It expects you to reason clearly about detection, explanation, escalation, and signal quality.
Questions get easier when you classify them into one lane first:
| Lane | What it is really testing |
|---|---|
| metrics | health, thresholds, trend shifts, and broad service state |
| logs | event detail, state changes, and evidence for what happened |
| traces or APM | request path, latency breakdown, and cross-service bottlenecks |
| notifications | who should be told and how response should fan out |
| dashboards and triage | how operators see, correlate, and act on signals |
Signal-selection logic plus actionable alert design is usually the highest-yield combination.
| If the question is mostly about… | Start with… | Strongest first move |
|---|---|---|
| whether something is healthy or breaching | metrics | use the fastest detection lane first |
| why a failure happened | logs or traces | explanation beats more thresholds |
| where a request slowed down | traces or APM | follow the latency path |
| too many pages or noisy alarms | alert quality and routing | reduce noise before adding more signals |
It punishes shallow observability thinking.
Common traps:
| Trap | Better reading |
|---|---|
| “Collect every possible signal.” | more data is not the same as better diagnosis |
| “Alerts prove observability is solved.” | alerts still need actionability, routing, and response context |
| “Logs can answer everything.” | logs help explain events, but they are not the best first lane for every question |
| “More dashboards automatically mean better visibility.” | dashboards help only when they improve operator decisions |
You do not need a full production NOC. You need a small, believable signal path.
Route the miss by signal lane.
| If your misses sound like… | Weak lane | Fix next |
|---|---|---|
| “I chose a slower or noisier signal than necessary.” | signal selection | review metrics vs logs vs traces |
| “I knew the issue existed but picked a bad alert.” | alert quality | review thresholds, windows, and actionability |
| “I gathered evidence but did not route it well.” | notifications and workflow | review topics, subscriptions, and escalation |
| “I mixed diagnosis with detection.” | observability stage separation | review detect vs explain vs respond boundaries |
Use this order:
1Z0-1111-25If a summary sounds more certain than the Oracle source, downgrade it.
Do less broad reading and more signal classification.
| Keep doing | Stop doing |
|---|---|
| rereading metrics vs logs vs traces confusion tables | opening random new observability tooling |
| reviewing the cheat sheet and glossary | treating every issue like a logging problem |
| checking official docs for disputed boundaries | building a large new observability stack late |
| practicing detect vs explain vs route classification | trusting unsupported community summaries over Oracle docs |