OCI App Integration Pro (1Z0-1042-25) common mistakes
OCI App Integration Pro (1Z0-1042-25) · Understand the traps and how to avoid them.
Treating an integration's trigger connection as if it can be swapped freely between an App Driven (REST Adapter) trigger and a Scheduled orchestration after the integration is created, then expecting existing mappings and the activate flow to keep working unchanged.
Candidates memorize the three orchestration styles as a list but never learn that the trigger type is fixed at creation time and determines which adapter, request/response shape, and callback semantics are available. They hit activation or mapping errors and guess at the cause.
What to do instead
Before answering, identify the trigger first: App Driven (REST/event), Scheduled, or Basic Routing. Learn that changing trigger style means creating a new integration, and that App Driven integrations need the REST Adapter trigger plus explicit response and callback handling. Practice sketching which style fits a stated requirement (fire-and-forget event vs. request-reply vs. periodic batch) before reading the options.
Confusing connections with connection instances and with connectivity agents, e.g., assuming a REST Adapter connection can reach an on-premises endpoint without an agent, or that one agent can serve every connection regardless of configuration.
The product separates the adapter type (REST, SOAP, FTP, Database, etc.), the configured connection (URL, credentials, security policy), and the agent that provides network reachability. Candidates conflate these layers and pick answers that skip the agent or the connection-level security policy.
What to do instead
Build a mental model of three layers: adapter (protocol), connection (endpoint + security + credentials), agent (network path for private endpoints). For any on-premises or private-network target, require a connectivity agent installed and a connection configured to use it. Memorize that agent groups and agent versions matter, and that the agent connects outbound to Oracle Cloud rather than requiring inbound firewall holes.
Assuming data mapping is a simple field-to-field copy and ignoring the need for explicit structural transformations (repeating element loops, conditional mappings, lookups, and global vs. local variables) when source and target schemas differ in cardinality.
Candidates who have only done flat JSON-to-JSON mappings underestimate the mapper's loop and condition constructs. They pick answers that imply automatic array handling, then fail questions about mapping a repeating source node to a repeating target node or applying a lookup table.
What to do instead
Learn the mapper's core constructs by name and purpose: for-each/loop mapping for repeating nodes, conditional (if/then) mapping expressions, lookup tables (domain value maps or CSV-based), and the distinction between global variables, local variables, and tracking variables. Practice reading a schema and stating whether a mapping needs a loop, a condition, or a lookup before choosing an answer.
Treating XSLT as interchangeable with the graphical mapper, and answering that any XSLT file can be dropped in without regard to the supported XSLT version, extension functions, or how the mapper generates its own XSLT behind the scenes.
Questions about custom XSLT, xsl:import/include, and unsupported functions are common, and candidates assume full XSLT 2.0/3.0 support. They also forget that editing generated XSLT by hand can break round-tripping with the visual mapper.
What to do instead
Know that the visual mapper emits XSLT and that custom XSLT is supported within documented limits - check the supported XSLT version and available extension functions before assuming a construct works. Learn that hand-editing generated XSLT can make the mapper unable to re-render, so prefer mapper constructs or a dedicated XSLT step. For any 'will this XSLT work' question, look for unsupported functions, external document() calls, or version mismatches.
Ignoring fault handling paths and answering as if a failed callout simply stops the integration - missing that scope-level fault handlers, global fault handlers, and explicit error branches change what the caller receives and whether the instance shows as failed.
Candidates focus on the happy path when studying orchestration and skip the fault-handler canvas. They then miss questions about catching a SOAP fault, returning a custom error response, or why an integration instance completed successfully despite a downstream error.
What to do instead
For every integration you study, trace the fault path: which scope contains the risky activity, whether a scope fault handler or global fault handler catches it, and what response the trigger returns. Learn the difference between a fault that propagates (instance fails) and one that is caught and handled (instance may complete). Study how callout timeouts, retries, and the 'notification' vs. 'fault' outcomes of a callout behave.
Mixing up where routing decisions belong - putting conditional logic in the mapper instead of a switch/branch activity, or assuming a Basic Routing integration can perform complex multi-step orchestration with callouts.
Routing, branching, and orchestration are taught separately, so candidates don't see that switch activities belong in orchestration while Basic Routing is limited to simple pass-through and routing rules. They also confuse content-based routing with the mapper's conditional expressions.
What to do instead
Learn the boundary: Basic Routing integrations route on a simple expression without full orchestration; App Driven and Scheduled integrations use switch/branch activities for multi-path flows. Know that switch conditions are evaluated on mapped/assigned values, and that each branch can contain its own activities and fault handling. When a scenario needs multiple callouts plus branching, rule out Basic Routing immediately.
Assuming credentials are stored in the connection or integration itself, and not knowing how identity domains, OAuth client credentials, and the credential store interact for outbound authentication.
Security questions test whether you know that credentials are managed as a separate resource and referenced, and that OAuth flows (client credentials, authorization code, resource owner) apply differently to trigger vs. invoke connections. Candidates who skip this pick answers that embed secrets in mappings or connection URLs.
What to do instead
Learn the credential model: credentials are created and stored separately and referenced by connections and integrations, never hardcoded in mappings. Know which OAuth flow fits which scenario - client credentials for system-to-system, authorization code for user-delegated access - and that the REST Adapter's security policy on a connection determines the token handling. Also know that trigger-side authentication (who may call your integration) is configured separately from invoke-side authentication (how you call out).
Treating monitoring as a single 'look at the dashboard' step and not distinguishing activity stream, instance tracking, business identifiers, and the different log types when diagnosing a failure.
Candidates memorize that monitoring exists but not the layered tools: instance states, activity stream per instance, tracking variables, business identifiers for search, and integration/agent logs. They then can't answer where to look for a specific failure such as an agent connectivity issue versus a mapping error.
What to do instead
Map symptom to tool: agent down or unreachable → agent/connectivity diagnostics; payload or mapping error → activity stream and instance fault details with tracking variables; search by business key → business identifiers; platform-level issues → integration logs and audit. Learn to read an instance's activity stream to find the first failing activity, and know that tracking variables must be explicitly set to appear.
Assuming activation is the end of deployment, without accounting for versioning, export/import packaging, and environment-specific overrides when promoting an integration from test to production.
Lifecycle questions test whether you know that integrations are versioned on activation, that export produces a package (IAR) containing the integration and referenced artifacts, and that connections and credentials must exist in the target environment. Candidates answer as if the package carries everything.
What to do instead
Learn the promotion sequence: lock/version the integration, export the package, import into the target, then re-create or re-point connections and credentials (they are environment-specific), verify the agent, and activate. Know that activating creates a new version and that the active version is what runs. For any 'what must be done in the target environment' question, list connections, credentials, agents, and any lookup/reference artifacts before activation.
Overlooking the difference between design-time validation and runtime behavior - assuming a successfully validated integration will behave identically at runtime, ignoring schedule time zones, callback URLs, and adapter-specific runtime limits.
The designer validates structure and mappings but not environment runtime concerns. Candidates who only practice in the designer miss questions about scheduled integrations firing in a specific time zone, callback endpoints being reachable, or payload size and timeout limits at runtime.
What to do instead
Separate design-time checks (schema validity, mapping completeness, activation validation) from runtime concerns (schedule and time zone, trigger endpoint reachability, callback configuration, adapter payload/timeout limits, agent availability). When a question describes an integration that validates but fails or misbehaves at runtime, check schedule configuration, endpoint reachability, and agent status before suspecting the mapping.