Browse Exams — Mock Exams & Practice Tests

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

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

Use this syllabus as your source of truth for 1Z0‑1042‑25.

What’s covered

Topic 1: Integration Architecture and OCI Fundamentals

Practice this topic →

1.1 Integration landscape and reference architectures

  • Differentiate synchronous API integrations from asynchronous event-driven integrations and choose appropriately for a scenario.
  • Identify common OCI integration building blocks (API Gateway, Functions, Events, Streaming/Queue, Notifications) and where each fits.
  • Given a scenario, choose a reference architecture that reduces coupling and improves resilience.
  • Explain why bounded contexts and clear ownership reduce integration failures and change risk.
  • Recognize common failure modes in distributed integrations (timeouts, retries, duplicate delivery, partial failure).
  • Identify where to place validation, transformation, and enrichment steps in an integration pipeline.

1.2 Networking and exposure patterns for integrations

  • Differentiate public vs private exposure patterns and choose based on risk and consumer requirements.
  • Given a scenario, choose a network placement for API Gateway/backends (public entry, private services).
  • Explain how routing, subnets, and security boundaries affect integration availability and blast radius (concept-level).
  • Recognize when to use gateways (IGW/NAT/Service Gateway) for secure connectivity (concept-level).
  • Identify common connectivity pitfalls: missing routes, overly broad security rules, and DNS misconfiguration.
  • Design a least-exposure pattern for internal APIs (private access + controlled ingress).

1.3 Identity and access control for integration components

  • Apply least privilege IAM to API Gateway, Functions, and messaging components (concept-level).
  • Given a scenario, choose how a component should authenticate to another (resource principal vs user credential) at a conceptual level.
  • Recognize why separating environments (dev/test/prod) into compartments reduces risk and improves governance.
  • Identify secrets handling requirements for integrations and where to store them safely (Vault).
  • Explain how audit trails support incident response and compliance for integration changes.
  • Recognize common IAM pitfalls: overly broad policies, shared admin identities, and unmanaged keys.

Topic 2: API Gateway and API Design

Practice this topic →

2.1 API Gateway components and configuration

  • Explain the core parts of API Gateway at a conceptual level (gateway, deployment, routes, backends).
  • Given a scenario, design routing that cleanly maps paths and methods to backend services.
  • Recognize how headers, query parameters, and request/response mapping affect integration correctness.
  • Identify operational limits and quotas that can impact API availability (concept-level).
  • Choose safe defaults for public APIs (strict auth, least privilege, restricted egress).
  • Recognize common API gateway misconfigurations that lead to outages (routing mismatch, auth failures, timeouts).

2.2 Authentication, authorization, and API security

  • Differentiate authentication from authorization and apply both in API designs.
  • Given a scenario, choose an API authentication approach appropriate for consumers (human vs service) at a conceptual level.
  • Explain why input validation and strict schemas reduce security risk and downstream failures.
  • Recognize common API security threats: credential leakage, injection via payloads, and overbroad access.
  • Choose patterns that prevent sensitive data exposure in errors, logs, and responses.
  • Identify when to enforce rate limiting/throttling (concept-level) to reduce abuse and protect backends.

2.3 API lifecycle, versioning, and operations

  • Design API versioning strategies that preserve backward compatibility and support gradual migration.
  • Given a scenario, choose rollout strategies for breaking changes (parallel versions, deprecation windows).
  • Explain how to instrument APIs for latency, error rate, and saturation signals (concept-level).
  • Recognize why consistent error contracts improve client resilience and debuggability.
  • Identify how to log safely (no secrets/PII) while keeping enough context for diagnosis.
  • Define a change management workflow for APIs (review, deploy, verify, rollback).

Topic 3: Serverless Integration with Functions

Practice this topic →

3.1 Functions fundamentals (concept-level)

  • Explain why Functions are used for integration glue code and event handlers.
  • Given a scenario, choose Functions vs long-running services vs batch jobs based on runtime constraints.
  • Identify how functions access OCI services securely (IAM + resource principals) at a conceptual level.
  • Recognize common function failure modes: timeouts, dependency issues, and external service errors.
  • Choose safe timeout and retry behavior for function invocations (concept-level).
  • Explain how idempotency protects against retries and duplicate deliveries.

3.2 Triggers and event-driven invocation patterns

  • Given a scenario, choose the right trigger source (Events/Notifications/Queue/Streaming) at a conceptual level.
  • Design a function handler that validates inputs and fails safely when data is invalid.
  • Recognize when to use asynchronous processing to avoid blocking upstream systems (concept-level).
  • Explain why correlation IDs enable end-to-end tracing across event-driven workflows (concept-level).
  • Identify where to place retries: client, gateway, function, or downstream consumer, and trade-offs.
  • Choose a dead-letter handling approach at a conceptual level to isolate poison messages.

3.3 Packaging, configuration, and safe deployments

  • Describe how to manage function configuration (environment variables, secrets) without hardcoding sensitive values.
  • Given a scenario, choose deployment strategies that support rollback and minimize downtime (concept-level).
  • Recognize how cold starts and concurrency can impact latency and cost (concept-level).
  • Explain why dependency pinning and reproducible builds reduce deployment risk.
  • Identify limits (memory/runtime) that can break functions and how to design within constraints (concept-level).
  • Design a release checklist for functions (tests, observability, permissions review).

Topic 4: Events, Messaging, and Connectors

Practice this topic →

4.1 Events and event rules

  • Explain what OCI Events are used for and identify common event sources (resource changes) at a conceptual level.
  • Given a scenario, design event rules that reduce noise and trigger only meaningful actions.
  • Recognize the risk of event storms and how to reduce downstream overload (concept-level).
  • Explain why idempotent consumers are required when events may be delivered more than once (concept-level).
  • Identify how to route events to multiple targets safely (fan-out patterns).
  • Recognize common event-driven debugging needs: correlation, timestamps, and retry visibility.

4.2 Notifications, Queue, and Streaming (concept-level)

  • Differentiate pub/sub notifications from queues and streams at a conceptual level.
  • Given a scenario, choose the right service based on ordering, durability, throughput, and consumer patterns.
  • Recognize when consumer groups and partitions matter for scaling stream processing (concept-level).
  • Identify patterns for backpressure and rate limiting to protect consumers (concept-level).
  • Explain why exactly-once is hard and how to achieve effective exactly-once with idempotency (concept-level).
  • Design a replay strategy for recovery and backfills (concept-level).

4.3 Service Connector Hub patterns

  • Explain the role of Service Connector Hub (move data/events between services) at a conceptual level.
  • Given a scenario, choose connectors that minimize custom code (log/metric routing, streaming to storage).
  • Recognize filtering and transformation considerations when routing events/logs (concept-level).
  • Identify security requirements for connector sources and targets (IAM policies, compartment boundaries).
  • Design connector usage that supports auditing and reduces operational overhead.
  • Recognize common connector failure modes and the signals used to detect them (concept-level).

Topic 5: Observability, Reliability, and Performance

Practice this topic →

5.1 Logging and monitoring for integrations

  • Define key signals for integrations: latency, error rate, throughput, retries, and queue/stream lag (concept-level).
  • Given a scenario, design alarms that detect real incidents without constant noise.
  • Explain safe logging practices for integrations (redaction, no secrets/PII).
  • Identify how to correlate requests across API Gateway, functions, and downstream services (concept-level).
  • Recognize retention and cost trade-offs for logs and metrics (concept-level).
  • Design dashboards that separate health signals from deep-dive diagnostics.

5.2 Reliability patterns: retries, timeouts, and idempotency

  • Given a scenario, choose retry policies (backoff, jitter) that avoid overload and thundering herds (concept-level).
  • Explain why timeouts must be set at each hop in distributed systems and aligned across layers (concept-level).
  • Design idempotency keys and deduplication strategies to prevent double-processing.
  • Recognize when circuit breakers and load shedding are appropriate (concept-level).
  • Identify the role of dead-letter queues/topics (concept-level) and when to quarantine messages.
  • Choose strategies to handle partial failures and ensure eventual consistency where appropriate (concept-level).

5.3 Performance and cost controls

  • Explain how payload size, serialization, and chatty APIs increase latency and cost (concept-level).
  • Given a scenario, choose batching vs streaming vs synchronous calls to meet latency and cost constraints.
  • Recognize quota and rate-limit constraints and design backpressure behavior accordingly (concept-level).
  • Identify when caching is safe and when it risks correctness (stale data, authorization boundaries).
  • Design SLAs/SLOs for integrations and tie alerts to user impact (concept-level).
  • Choose patterns to isolate noisy consumers and protect critical workflows (concept-level).

Topic 6: Security, Governance, and Operations

Practice this topic →

6.1 Secrets, keys, and secure configuration

  • Store secrets and keys in Vault and avoid embedding them in code or configuration files.
  • Given a scenario, design key/secret rotation that minimizes downtime and prevents credential drift (concept-level).
  • Recognize common secret leak paths (logs, CI output, config repos) and mitigations.
  • Explain why separate identities for humans and workloads improves traceability and reduces risk.
  • Identify least-privilege IAM policies for secrets access and enforcement points.
  • Choose a secure-by-default approach for integration endpoints (private access, explicit allowlists).

6.2 Governance and environment separation

  • Design compartment and tagging standards that support ownership, auditability, and cost tracking.
  • Given a scenario, separate dev/test/prod and enforce guardrails with policies and approvals (concept-level).
  • Recognize why shared mutable integration environments cause outages and how to reduce blast radius.
  • Identify audit and logging requirements for integration changes in regulated contexts (concept-level).
  • Explain why consistent naming and versioning reduces operational confusion and rollback risk.
  • Choose governance controls that balance speed with safety (pre-prod gates, review workflows).

6.3 Deployment, change control, and incident readiness

  • Version APIs, functions, and integration configs and design rollback paths for each.
  • Given a scenario, choose staged rollout strategies (canary/blue-green/shadow) at a conceptual level.
  • Define runbooks for common incidents (auth failures, downstream outages, message backlog) and tie them to alerts.
  • Recognize why post-incident reviews should feed back into tests, alerts, and design changes.
  • Identify the operational signals that indicate a degraded integration before it becomes an outage (lag, retries, error rates).
  • Design a release checklist that includes security review, observability verification, and cost considerations.
Study Plan
Cheat Sheet