Informatica Cloud DI Foundation common mistakes
Informatica Cloud DI Foundation · Understand the traps and how to avoid them.
Treating an IICS Mapping task as if it were a PowerCenter session and expecting session-level partitioning, session logs, and recovery settings to carry over unchanged; candidates answer questions about pushdown and partitioning as though the Secure Agent ran the whole transformation graph.
Most candidates come from PowerCenter and assume the mapping always executes row-by-row on the agent. In fact the mapping logic is compiled and the optimizer decides which transformations run in the database (pushdown) and which run on the agent, so answers about where a filter or join executes are frequently wrong.
What to do instead
Before answering any execution question, ask: is the source/target a relational database reachable by the agent, and does the transformation support pushdown? Learn the split - expression, filter, lookup, joiner, aggregation, sorter, and update-strategy can push down; sequence generators, some rank/union cases, and non-relational sources force agent-side processing. Verify with the execution plan/log rather than assuming.
Confusing Mapping tasks, Taskflows, and Synchronization tasks - for example, choosing a Mapping task when the requirement is to run several mappings in sequence with dependencies, or choosing a Taskflow when the requirement is simply one mapping with a schedule.
All three appear in the Data Integration service and all can be scheduled, so the distinctions blur under exam pressure. Candidates also forget that a Taskflow can contain mapping tasks, other taskflows (nested), command tasks, and decision/notification steps, whereas a Mapping task runs exactly one mapping.
What to do instead
Memorize the one-line contract for each object: Mapping task = one mapping + runtime options; Taskflow = orchestration of multiple steps with tokens and dependencies; Synchronization task = source-to-target data replication with its own load-type options (insert, update, upsert, delete, full load). Map each exam scenario to the object whose contract fits, and reject options that add orchestration the scenario never asked for.
Assuming a Lookup transformation or Joiner always queries the database at runtime, and mispredicting the result of a lookup with multiple matches or a lookup on a non-key column.
Lookup caching behavior (uncached, static cache, dynamic cache, persistent cache) changes both performance and semantics. Candidates also forget that an unconnected/connected lookup returning multiple rows fails unless the 'lookup multiple matches' option is set, and that a dynamic lookup can insert/update the lookup cache and target.
What to do instead
For every lookup question, identify three things: cache type, match policy (first match vs. multiple matches vs. error), and whether the lookup is connected or unconnected. Learn that a relational lookup with multiple matches errors by default, that dynamic lookup requires the lookup source to be a relational target too, and that persistent cache survives across runs while static cache is built per run.
Mixing up Source transformation, Source Qualifier, and Update Strategy behavior - e.g., expecting an Update Strategy to delete rows in the target without the target connection being configured for delete, or expecting a filter placed before the Source Qualifier to be pushed down.
The transformation order in the mapping canvas determines pushdown eligibility, but candidates reason about it as a pure dataflow diagram. Update Strategy flags (DD_INSERT, DD_UPDATE, DD_DELETE, DD_REJECT) also only take effect when the target supports the operation and the session/task is configured to honor them.
What to do instead
Learn the rule: transformations upstream of the Source Qualifier are not pushed down; filters and expressions downstream of the Source Qualifier may be. For Update Strategy, always check the target's update/delete capability and the task's 'treat source rows as' setting. If the question asks 'which rows reach the target', trace the flag values explicitly.
Answering parameterization questions by hard-coding values in the mapping, or confusing mapping parameters with mapping variables and with task-level in-out parameters.
IICS has several layers of parameterization - mapping parameters (constant per run), mapping variables (can change during the run, e.g., set by an Expression or Assignment), task input parameters, and parameter files - and candidates collapse them into one concept. They also forget that parameters must be declared in the mapping before a task can override them.
What to do instead
Build a mental table: parameter = fixed at run start, referenced with $; variable = mutable during run, referenced with $$ or via SetVariable; task parameter = value supplied at task runtime and must correspond to a declared mapping parameter. For any question, ask 'does this value need to change mid-run or only between runs?' to pick the right construct.
Misjudging error handling and row-level rejection: assuming a bad row stops the whole task, or assuming it is silently skipped, instead of knowing where rejected rows go and what determines task failure.
IICS separates row errors (which can be written to a reject file or error table) from fatal errors (which fail the task). Candidates also overlook that 'stop on errors' thresholds and the error handling setting in the task determine whether the task continues.
What to do instead
For each error scenario, identify: (1) is the error a row-level conversion/lookup error or a connectivity/fatal error; (2) what is the task's error threshold setting; (3) is a reject file or error table configured. Learn that row errors go to the reject destination when configured and the task can continue until the threshold is exceeded, while connection failures fail the task regardless.
Confusing Secure Agent registration and agent group behavior - e.g., assuming the agent runs in the Informatica cloud, or that any agent in the org can run any task regardless of agent group assignment.
The Secure Agent is customer-hosted software that executes mappings and connects to on-premises sources; the cloud hosts the metadata repository and UI. Agent groups let you pin tasks to specific agents for network or load reasons, and candidates frequently answer as if the runtime were fully managed.
What to do instead
Anchor on the architecture: cloud = metadata, scheduling, monitoring; Secure Agent = execution and connectivity. Learn that a task runs on an agent in its assigned agent group, that an agent can belong to multiple groups, and that on-premises sources require an agent with network access. Any question about 'where does the job run' should be answered with the agent, not the cloud.
Getting connection and runtime environment questions wrong by ignoring the difference between the connection's configured type (e.g., relational vs. flat file vs. application) and the runtime environment (native vs. hosted), or by assuming pushdown works for every connection.
Pushdown depends on the connection being a relational database the agent can reach, and on the transformation being pushdown-capable. Candidates answer 'pushdown' for flat file, Salesforce, or other non-relational sources where the work must happen on the agent.
What to do instead
Before choosing pushdown, check two gates: connection type supports SQL, and the transformation is on the pushdown-capable list. For flat files, application sources, and non-SQL targets, assume agent-side processing unless the documentation says otherwise. Also remember that a mapping can be partly pushed down and partly agent-side.
Treating task monitoring and logs as cosmetic: answering that a failed task shows the exact failing row in the summary, or that the mapping log is the same as the task log, instead of knowing where to find row-level errors and execution statistics.
IICS separates the job/task instance view (status, timings, error message) from the detailed session log and reject files. Candidates who have only used the UI casually assume the summary contains everything, so they pick the wrong place to diagnose a failure.
What to do instead
Learn the diagnostic path: task instance → status and error message → detailed log for the agent-side execution → reject file/error table for row-level failures. Know that pushdown queries may appear in the database's own logs rather than the agent log. For exam questions, pick the artifact that contains row-level detail, not the summary.
Assuming a full load and an incremental load are interchangeable in a Synchronization task, or forgetting that delta detection requires a defined logic (e.g., a timestamp or key-based comparison) and that load type determines whether deletes and updates propagate.
Synchronization tasks expose load types (full, incremental) and options for insert/update/upsert/delete, and candidates conflate 'incremental' with 'just run it again'. Without a delta column or key comparison, incremental load cannot detect changes, so the answer that assumes it will is wrong.
What to do instead
For each replication scenario, name the delta mechanism first (timestamp column, sequence, or key comparison), then choose the load type. Remember that full load replaces or truncates per configuration, incremental requires a detectable change, and delete propagation must be explicitly enabled. If the scenario gives no delta column, incremental load is not the correct answer.