Browse Exams — Mock Exams & Practice Tests

1Z0-1084-25 Syllabus — Learning Objectives by Topic

Learning objectives for OCI 2025 Developer Professional (1Z0-1084-25), organized by topic with quick links to targeted practice.

Use this syllabus as your checklist for 1Z0‑1084‑25.

What’s covered

Topic 1: Authentication & Authorization for OCI Applications

Practice this topic →

1.1 User API keys, request signing, and local development

  • Explain OCI API request signing at a conceptual level and why it is required for API calls.
  • Differentiate user API signing keys from other auth methods and identify where they are appropriate (local dev).
  • Recognize common configuration artifacts (config file profiles, key files) used by CLI/SDKs (concept-level).
  • Given a scenario, choose an auth method that supports local development without excessive risk.
  • Identify common auth failure causes (wrong key, wrong tenancy/region, missing permissions) conceptually.
  • Explain why key rotation and least privilege reduce credential risk.

1.2 Instance principals and resource principals

  • Explain instance principals and why they reduce the need for long-lived credentials in compute workloads.
  • Explain resource principals conceptually and identify when they are used (inside OCI services).
  • Given a scenario, choose instance/resource principals to avoid embedding secrets in application code.
  • Use dynamic groups conceptually to scope permissions to workloads (not human users).
  • Identify the risk of over-broad dynamic group matching rules and how to tighten scope (concept-level).
  • Given a scenario, choose the least-privilege policy pattern for an application.

1.3 IAM policy thinking for developers

  • Interpret a policy statement and identify subject, verb, resource-family, and compartment scope.
  • Choose the minimal verb (read/use/manage) required for application functionality.
  • Given a scenario, scope policies to a compartment rather than tenancy-wide.
  • Recognize that network access does not equal authorization; IAM still controls actions.
  • Identify common policy pitfalls: wrong compartment, wrong resource family, too-broad permissions.
  • Given a scenario, design access for an app that must call multiple OCI services safely.

Topic 2: OCI APIs, SDKs, and CLI — Correct Usage Patterns

Practice this topic →

2.1 OCI CLI concepts and common operations

  • Recognize common CLI operations: listing resources by compartment, filtering, and selecting regions (concept-level).
  • Explain why compartment scope is required for many resource listings.
  • Given a scenario, choose CLI usage for scripting and quick validation tasks.
  • Identify common CLI failure causes (permissions, region mismatch, missing namespace) conceptually.
  • Recognize safe scripting practices (avoid printing secrets, prefer least privilege).
  • Given a scenario, choose a CLI-based workflow to validate a deployment.

2.2 SDK usage patterns: compartments, pagination, and retries

  • Explain why APIs often require compartment identifiers and how that shapes application design.
  • Recognize pagination as a common API pattern and why developers must handle it (concept-level).
  • Describe retries at a high level and why transient failures should be expected in distributed systems.
  • Given a scenario, choose idempotent designs to tolerate retries without duplicate side effects.
  • Identify how to log request context and error details for debugging (concept-level).
  • Given a scenario, choose the safest way to call OCI APIs from production code.

2.3 Regions/endpoints and configuration management

  • Explain why region selection matters (endpoints, data residency, latency) conceptually.
  • Recognize that OCI SDK clients are configured per region and per auth method (concept-level).
  • Given a scenario, choose environment-based configuration (dev/stage/prod) without hard-coding values.
  • Identify the risk of storing secrets/configs in source control and safer alternatives (Vault, CI secrets).
  • Recognize observability configuration as part of production readiness (logs/metrics).
  • Given a scenario, choose a configuration approach that supports safe deployment automation.

Topic 3: Serverless & API Integration (Functions, API Gateway)

Practice this topic →

3.1 Functions: triggers, execution, and operational safety

  • Explain Functions as a serverless compute option and identify when it fits (event-driven tasks).
  • Recognize that functions should be designed to be idempotent and safe on retries (concept-level).
  • Given a scenario, choose where to store configuration/secrets for a function (Vault, env/config management).
  • Identify basic operational needs: logs, metrics, and error handling for serverless workloads.
  • Given a scenario, choose a function-based approach vs a long-running service based on workload pattern.
  • Recognize common failure modes: timeouts, permission issues, and downstream dependency failures (concept-level).

3.2 API Gateway: exposing and protecting APIs (concept-level)

  • Explain API Gateway’s purpose at a high level: routing, policy enforcement, and API lifecycle.
  • Given a scenario, choose API Gateway to expose backends (functions/services) with a single public entry point.
  • Recognize authentication/authorization and rate limiting as common gateway concerns (concept-level).
  • Identify why TLS termination and certificate management matter for public APIs (concept-level).
  • Given a scenario, choose a design that isolates backends in private networks while exposing a public API.
  • Recognize why logging at the gateway helps troubleshooting and security monitoring.

3.3 Integration design: contracts, versioning, and rollout

  • Explain API versioning intent and why it prevents breaking clients (concept-level).
  • Given a scenario, choose a rollout strategy that supports rollback and gradual adoption.
  • Recognize that integration contracts include schemas and validation (concept-level).
  • Identify why observability and correlation IDs improve debugging across services (concept-level).
  • Given a scenario, choose a design that minimizes coupling between services.
  • Recognize the operational cost of frequent breaking changes and how to reduce it.

Topic 4: Events, Notifications, and Streaming

Practice this topic →

4.1 Events and event rules (concept-level)

  • Explain event-driven architecture intent and why it improves decoupling.
  • Recognize Events as a service that emits signals when resources change (concept-level).
  • Given a scenario, choose event rules to trigger automation reliably.
  • Identify idempotency as a key requirement for event handlers (concept-level).
  • Recognize common event failure considerations: retries, duplicates, and ordering (concept-level).
  • Given a scenario, choose events over polling to reduce cost and complexity.

4.2 Notifications and alerting flows

  • Explain Notifications as fan-out delivery to subscribers (concept-level).
  • Given a scenario, choose notifications for alerts and automation triggers.
  • Recognize that alert paths should include ownership and escalation (concept-level).
  • Identify why message content should include context for troubleshooting (resource IDs, correlation IDs).
  • Given a scenario, choose an approach that avoids alert fatigue (reasonable thresholds, deduping).
  • Recognize the need to secure webhook endpoints and validate incoming messages (concept-level).

4.3 Streaming concepts and selection

  • Explain streaming as an ordered event log conceptually and identify when it fits (event pipelines).
  • Given a scenario, choose streaming for high-throughput event ingestion and multiple consumers.
  • Recognize core streaming concepts: partitions, consumer groups, offsets (concept-level).
  • Identify durability and ordering trade-offs that influence design (concept-level).
  • Given a scenario, choose a safe processing approach that handles retries and reprocessing (concept-level).
  • Recognize that schema/versioning matters for event data over time (concept-level).

Topic 5: Storage and Data Service Integration

Practice this topic →

5.1 Object Storage integration patterns

  • Choose Object Storage for durable blob storage and explain why (concept-level).
  • Given a scenario, design object naming and metadata to support retrieval and governance.
  • Recognize lifecycle policies as a cost control tool (standard to archive).
  • Identify access control concerns: bucket policies/IAM scope and least privilege (concept-level).
  • Given a scenario, choose events triggered by object creation for automation workflows.
  • Recognize common pitfalls: large objects, multipart, and retries (concept-level).

5.2 Database integration basics (concept-level)

  • Given a scenario, choose autonomous vs managed DB options based on operational needs (concept-level).
  • Recognize that applications should access databases through private networking and controlled security rules.
  • Explain why connection handling, timeouts, and retries matter for DB-backed services (concept-level).
  • Identify backup/restore awareness as part of application reliability (concept-level).
  • Given a scenario, choose patterns that prevent data corruption and ensure consistency (concept-level).
  • Recognize that secrets (DB credentials) must be handled securely (Vault).

5.3 Data movement trade-offs (latency, cost, security)

  • Explain data locality as a major driver of latency and cost (especially egress) conceptually.
  • Given a scenario, minimize cross-region or cross-network data movement unless required.
  • Recognize encryption requirements for data in transit and at rest across integrations.
  • Identify governance concerns: retention, access, auditability, and ownership (concept-level).
  • Given a scenario, choose a data integration approach that is operationally simple and resilient.
  • Recognize that replication strategies must align with RPO/RTO requirements (concept-level).

Topic 6: Observability, Reliability, and Troubleshooting

Practice this topic →

6.1 Logging, metrics, and alarms for applications

  • Design logging that supports debugging and audits (structured logs, correlation IDs) conceptually.
  • Choose key metrics to monitor application health (latency, errors, saturation) conceptually.
  • Given a scenario, choose alarm thresholds and notification routes that support on-call workflows.
  • Recognize that serverless and managed services still need application-level observability.
  • Identify when to use logs vs metrics vs audit for troubleshooting (concept-level).
  • Given a scenario, choose an observability baseline that reduces mean time to recovery.

6.2 Reliability patterns: retries, idempotency, and backpressure

  • Explain idempotency and why it prevents duplicate side effects during retries.
  • Recognize exponential backoff/jitter as a safer retry approach than tight loops (concept-level).
  • Given a scenario, choose a design that handles partial failures gracefully.
  • Identify common reliability anti-patterns: unbounded retries, no timeouts, no dead-letter handling (concept-level).
  • Given a scenario, choose a queue/streaming-based approach to smooth bursts and avoid overload.
  • Recognize the need to persist state or checkpoints for reliable reprocessing (concept-level).

6.3 Secure operations: secrets, least privilege, and auditability

  • Given a scenario, choose Vault to manage secrets and avoid storing credentials in code.
  • Apply least privilege in IAM policies for application identities and explain why.
  • Recognize the role of audit logs in incident investigations and compliance.
  • Given a scenario, choose safe defaults for network placement (private tiers, minimal inbound exposure).
  • Identify how to rotate credentials/keys with minimal downtime (concept-level).
  • Recognize that operational security includes monitoring for unexpected access patterns (concept-level).
Study Plan
Cheat Sheet