Informatica Data Engineering Foundation common mistakes
Informatica Data Engineering Foundation · Understand the traps and how to avoid them.
Treating a mapping's Source Qualifier SQL override as the place to put business join logic, then expecting the Data Integration Service to push the join to the database automatically.
Candidates learn that the optimizer pushes work down and assume any join written in the override is executed in the source database; in practice the override is passed as-is only when the database supports it, and joins added after the Source Qualifier run in the service process, so performance and semantics differ from what they expect.
What to do instead
Decide deliberately where each join executes: keep pure source-to-source joins inside the Source Qualifier override so the database does the work, and for anything requiring transformation logic place an explicit Joiner or Lookup and reason about caching. When reviewing a mapping, ask 'which engine executes this step' for every transformation rather than assuming pushdown.
Confusing connected and unconnected lookup behaviour, especially default values, multiple return ports, and conditional lookup calls, when tracing a mapping's output.
Both lookup types look similar in the designer, but an unconnected lookup is called only through an expression with :LKP, returns one port at a time, and its default value applies when no match is found, whereas a connected lookup passes rows through and can return several ports. Candidates apply connected rules to unconnected lookups and mispredict which rows survive.
What to do instead
For every lookup, state three things before predicting output: is it connected or unconnected, which ports are lookup ports versus return ports, and what the default value is. Practise tracing a mapping where an unconnected lookup is called twice with different conditions and confirm the unmatched-row path against the default value.
Assuming a session succeeds or fails only on row errors, ignoring the difference between session-level error handling and the mapping's update strategy or reject file behaviour.
Candidates memorise 'set error threshold to 0 to fail on any error' but then cannot explain why a session reports success while rows landed in the reject file, or why a target row was rejected rather than updated. The interaction between the session error limit, the reject file, and the update strategy expression is not intuitive.
What to do instead
Learn the three separate controls: the session error threshold governs when the session stops, the reject file captures rows the writer could not apply, and the Update Strategy expression decides insert/update/delete/reject per row. Trace one row that violates a constraint and state exactly which control catches it and what the session status becomes.
Treating a data quality scorecard as a single pass/fail number instead of mapping each score back to the specific rule, column, and threshold that produced it.
Dashboards present aggregated scores, so candidates read '92% quality' as a verdict and cannot diagnose which dimension (completeness, conformity, uniqueness) drove the drop, nor which records are affected.
What to do instead
For any score, decompose it: identify the rule, the target column, the threshold, and the count of failing records, then confirm the score reconciles with those counts. Practise writing the drill-down query that lists failing records behind one rule so the score is always explainable.
Confusing data observability signals (freshness, volume, schema drift, distribution) with rule-based data quality validation and choosing the wrong mechanism for a monitoring requirement.
Both detect problems, but a quality rule encodes an expected condition the author already knows, while observability baselines historical behaviour and flags anomalies nobody wrote a rule for. Candidates reach for a rule when the requirement is 'tell me when this feed stops arriving' or 'tell me when a new column appears'.
What to do instead
Classify the requirement first: if you can state the exact expected value or pattern, use a rule; if the expectation is 'behave like it usually does', use an observability metric such as row-count deviation, freshness against SLA, or schema-change detection. For each monitoring scenario, name the signal and the alert threshold before naming the tool feature.
Mixing up match and merge in MDM, describing merge as the step that decides two records are the same, and ignoring survivorship rules when predicting the golden record.
The terminology is close and the workflow is often described end to end, so candidates collapse identification, matching, and consolidation into one step. They then cannot say which attribute value wins when two matched records disagree.
What to do instead
Keep the pipeline explicit: standardise, then match (score and classify pairs as duplicate or not), then merge/consolidate (apply trust and survivorship rules to choose each attribute value), then persist the golden record with lineage to its sources. When given two records, walk attribute by attribute and state which survivorship rule selects the winner and why.
Assuming a match rule with a lower threshold always improves the golden record, without weighing false positives against false negatives.
Candidates equate 'more matches' with 'better deduplication' and ignore that loosening a threshold merges records that are genuinely different parties, which is far costlier to unwind than a missed match.
What to do instead
Evaluate match rules with both error types: sample pairs just above and just below the threshold and inspect them, and choose the threshold where the cost of a wrong merge exceeds the cost of a missed one. Be ready to describe a review queue for borderline scores rather than silently auto-merging them.
Describing AI governance only in terms of model accuracy, omitting data lineage, provenance, consent, and the human accountability for automated decisions.
Candidates come from an engineering background and default to model metrics, while the governance questions probe who is accountable, what data trained the model, and whether its use is permitted.
What to do instead
Frame every AI governance answer around four artifacts: the data lineage from source to training set, the documented purpose and permitted use, the human owner accountable for outcomes, and the monitoring for drift and bias after deployment. If asked about a model, state where its training data came from and who approved its use before discussing accuracy.
Treating data governance as a documentation exercise and failing to connect policies to enforceable controls, owners, and measurable outcomes.
Governance material is often presented as frameworks and role charts, so candidates recite council structures without saying what technically changes, who is accountable for a domain, or how compliance is measured.
What to do instead
For any policy, name the control that enforces it (masking, access policy, retention job, certification requirement), the accountable owner, and the metric that shows it works. Answer governance scenarios with that three-part structure instead of describing org charts.
Confusing a business glossary term with a technical catalog asset, and expecting glossary edits to change physical metadata or lineage automatically.
The catalog presents glossary terms, assets, and lineage in one search experience, so candidates assume a single object type and expect renaming a term to propagate to columns or that lineage is authored by hand.
What to do instead
Separate the layers: glossary terms carry business definitions and stewards, technical assets carry schema and profiling statistics, and lineage is discovered from executed jobs rather than typed in. When asked how a report column is defined, trace it through lineage to the physical asset and then link that asset to the glossary term that supplies the business meaning.