Informatica IICS Taskflow Interview Questions: Fault Handling, Recovery, and Data Validation

A taskflow finishes, but yesterday's orders are incomplete. Someone suggests skipping the failed step so downstream reporting can continue. Before choosing a recovery action, separate three questions: what state is the parent flow in, what happened inside its child tasks, and what data actually reached the target?

This is a documentation-supported preparation guide for Informatica Cloud Data Integration, or CDI, taskflows. The title retains the familiar IICS search term. We did not execute a taskflow in an Informatica environment. Official documentation supports the product discussion; the recovery examples are explicitly constructed practice cases, not platform screenshots, measured incidents, or candidate interview reports.

For related data reasoning, start with Design idempotent daily loads with deduping. Its replay questions complement this guide's focus on deciding what a CDI run actually accomplished.

Keep the scope on CDI taskflows

Informatica's official error-handling guidance covers sequential CDI loading dependencies, taskflow and subtaskflow failures, and recovery choices involving resuming or skipping faulted work. It is advisory guidance, not proof that a particular pipeline's data is safe after a recovery action. CDI error handling

This article does not substitute PowerCenter workflow recovery or Cloud Application Integration process semantics for CDI taskflows. Similar words across products do not establish identical restart behavior. In an interview, name the product and the kind of step before describing the control flow.

There is also a version boundary. The status discussion below uses Informatica's current-version documentation available in indexed form when checked. Direct access to some documentation pages was restricted during research. We have not verified your tenant's current configuration screens, connector behavior, or recovery controls. Where only historical material supports a setting name, it is labeled as historical rather than presented as a current click-by-click procedure.

The useful answer can still be concrete. Specify what evidence you would collect, what dependency must remain protected, and what target condition must be true before downstream work proceeds. That demonstrates preparation without pretending to have operated an environment you have not used.

Read parent status and child results separately

Official documentation: the status resource accepts a taskflow run ID. Request subtaskDetails=Yes to include child information; its default does not include those details. Parent states include SUCCESS, FAILED, SUSPENDED, and RUNNING. Child results additionally distinguish states such as COMPLETED and WARNING. Taskflow status resource

A request has this documented shape; it is not a request we executed:

GET <IICS base URL>/active-bpel/services/tf/status/<run ID>?subtaskDetails=Yes

The child details expose fields including rowsProcessed, successRows, errorRows, and errorMessage. These are operational evidence to inspect, not substitutes for a business reconciliation. An empty child collection from a parent-only request does not demonstrate that every dependency succeeded.

Official log documentation: taskflow logs contain run identity, timestamps, status, error information, and subtask details. Preserve the relevant log alongside the specific run you are discussing. Taskflow log contents

For your own investigation notes, keep three separate statements: “the parent reports this state,” “this child reports this outcome,” and “the target query returns this result.” Do not compress them into “the job worked.” Their disagreement is often the most useful part of the incident.

A processed-row number also needs context. Ask which task produced it, which input batch it covers, and what transformation the mapping performs. Aggregation, filtering, updates, and rejected records make a universal equation between processed rows and target row count unreliable. Define the expected relationship for this mapping instead of assuming one.

Work through a three-step dependency

The following is an original practice scenario, with invented data and a proposed dependency order:

Stage batch B17 → Load target orders → Validate and release B17

The intended batch has 100 distinct order keys, numbered 1 through 100. Each order's amount is ten times its key, so the expected amount total is 50,500. The final step is a proposed business release gate: reporting should consume the batch only after its target contents pass validation.

Now suppose an investigation finds that the staging input is complete, but only keys 1 through 40 are present in the target after a load interruption. That partial-write assumption is part of the exercise. It is not a claim that a CDI connector always commits forty rows or that a taskflow failure guarantees partial commits.

The first unresolved product question is the run's actual fault-handling state. Do not invent a parent status from the data alone. Collect the taskflow run ID, the load task's result, its error details, and the deployed configuration. Then compare that evidence with the target snapshot.

The scenario's important distinction is that target evidence can be known while recovery eligibility remains unresolved. You can conclude that sixty expected keys are missing without claiming which platform button is available. A strong answer states both the known defect and the remaining configuration question.

Explain fault handling before choosing recovery

Historical documentation, not a current tenant guarantee: the November 2024 Taskflows guide describes Suspend on Fault and its precedence over certain Data Task completion-failure settings. Use that history to recognize terminology, then inspect the deployed configuration before relying on the interaction. November 2024 Taskflows

For the B17 exercise, the editorial recommendation is to preserve the dependency: do not release a batch whose required load is incomplete. Whether that policy is implemented through suspension, a custom error path, or a separate validation gate must be established from the actual design and supported controls.

A notification is useful because it exposes the problem; it does not repair missing orders. Likewise, reaching an error-handling branch can be intentional control flow while the business work remains unfinished. Explain what the branch records and what it prevents, not just that it “handles errors.”

If an interviewer introduces a warning instead of a hard failure, ask what the warning means for this batch. A permitted exclusion with an explicit reconciliation rule differs from losing required orders. Define the acceptance rule before deciding whether continuing is appropriate.

Keep the failure cause separate from the recovery action. A temporary connection problem might be gone, but the target could still contain a partial write. Conversely, a deterministic mapping error may recur on every attempt. Fixing the cause and ensuring safe replay are two checks, even when they lead to one operational decision.

Decide whether repeating or skipping work is safe

In the constructed target, skipping the required load leaves forty rows and sixty missing keys. Appending all hundred source rows again produces 140 rows containing 100 distinct keys, with forty keys duplicated. Replacing records by the correct key can produce the intended hundred rows, but only under the assumed replacement semantics.

These counts were calculated from a small local data fixture. They are not observed CDI recovery results. They show why the target's write behavior matters before using an available recovery action.

This table is a reasoning aid, not a list of guaranteed controls in every CDI environment. Use the actual taskflow state and supported version-specific behavior to determine what can be executed. In particular, do not describe “resume” as a promise to continue at the first uncommitted row without evidence for the task and connector involved.

A skip decision needs a positive reason. “The dashboard must be green” is not evidence that the dependency is satisfied. If the load is genuinely optional, explain how downstream consumers represent its absence. If it is required, skipping without replacement moves the defect forward rather than resolving it.

Replaying safely also requires stable identity. Keep the batch boundary and the business key distinct from a new attempt's run ID. Otherwise, a second attempt can be mistaken for new business data, or a recovery query can accidentally include a later batch.

Validate keys and values after recovery

For the B17 fixture, completion means all expected keys exist exactly once with their expected values. Row count alone cannot establish that. Replace key 100 with key 101 and the target still has one hundred rows and one hundred distinct keys, while one required order is missing and one unexpected order is present.

The following are proposed validation queries for simple staging and target tables. They were not run through CDI or against a production database. Adapt table names, key definitions, and SQL syntax to the actual target.

-- Missing expected keys for this batch
SELECT s.order_id
FROM stage_orders s
LEFT JOIN target_orders t
  ON t.batch_id = s.batch_id AND t.order_id = s.order_id
WHERE s.batch_id = 'B17' AND t.order_id IS NULL;

-- Repeated keys inside the target batch
SELECT order_id, COUNT(*) AS copies
FROM target_orders
WHERE batch_id = 'B17'
GROUP BY order_id
HAVING COUNT(*) > 1;

Run the reverse comparison to find unexpected target keys, then compare amounts for matching keys. In this exercise, a clean result requires zero missing keys, zero unexpected keys, zero duplicate keys, and the expected per-order values. The total of 50,500 is a useful cross-check, not a replacement for those comparisons: different errors can cancel in a sum.

Record the before-and-after results beside the recovery attempt. The partial fixture totals 8,200; blind append replay totals 58,700. Those numbers explain the business consequence of the proposed actions more clearly than a changed status badge. They also give a reviewer something independent to verify.

Finally, check the release gate. A repaired target is not enough if reporting already consumed an incomplete batch or if a stale release marker still points to an earlier attempt. Explain which downstream effect needs correction and what evidence establishes that consumers now see the intended data.

Give an interview answer with explicit evidence boundaries

A concise answer for the practice case could be: “I would first identify the parent and child runs, inspect the fault path, and reconcile B17 in the target. The fixture shows sixty missing keys, so I would not release it. Before repeating the load, I would confirm its write semantics and resolve the failure cause. After recovery, I would compare keys and values, then verify the release marker.”

That answer describes a decision process, not a claim that a specific recovery action was tested. If you have genuine project experience, substitute your own observed run details and outcomes. If you do not, keep the scenario labeled as practice rather than borrowing the voice of a production incident report.

Use these PracHub questions for transferable pipeline and data-validation reasoning. They are not advertised as an Informatica sandbox or guaranteed IICS interview questions.

Continue with Design idempotent daily loads with deduping. Explain what a second attempt can safely repeat and which target checks would prove that it did so.

Sources and Further Reading

• Informatica: Error handling in Cloud Data Integration
• Informatica: Monitoring taskflow status with the status resource
• Informatica: Taskflow log file contents
• Informatica: November 2024 Taskflows, historical reference