Informatica MDM SaaS Foundation common mistakes
Informatica MDM SaaS Foundation · Understand the traps and how to avoid them.
Treating Business 360 and Customer 360 as interchangeable labels and answering questions about data model ownership or matching as if the two applications shared one configuration surface.
The names sound like product tiers, so candidates assume one is a subset of the other and reuse the same mental model for both. The exam asks which application owns a given capability, and this conflation produces confidently wrong answers.
What to do instead
Build a two-column comparison table before the exam: for each capability (data model extension, match rules, survivorship, hierarchy, user interface) write which application exposes it and where the configuration lives. Re-derive the table from the product documentation rather than memory, and test yourself by covering one column.
Memorizing that MDM SaaS 'matches records' without being able to say which stage of the pipeline a candidate question is describing (standardization, matching, consolidation, or best-record selection).
Most study material describes the end result ('duplicates are merged') rather than the ordered stages. When a question asks where a specific behaviour occurs, candidates pick the stage whose name sounds closest rather than the one that actually performs the work.
What to do instead
Draw the pipeline as an ordered diagram with one concrete example at each stage: a raw value, its standardized form, the match key produced, the match pair scored, the consolidated record, and the surviving golden record. Answer practice questions by locating the described behaviour on that diagram before choosing.
Assuming trust scores and survivorship rules are the same mechanism, or that the highest trust score always wins every attribute.
Both are described as 'deciding which value to keep', so candidates collapse them. In practice trust contributes to source ranking while survivorship rules define the per-attribute logic, and the interaction is where exam distractors live.
What to do instead
Write out one worked example: two sources with different trust scores contributing conflicting values for the same attribute, and trace which value survives under a source-priority rule versus a most-recent rule. State explicitly in your notes which configuration object controls each decision.
Answering data-model questions as if MDM SaaS required the same custom-object build effort as an on-premises MDM hub, choosing options that describe creating physical tables for every new entity.
Candidates with on-premises Informatica MDM experience transfer that model wholesale. The SaaS business entity model is configured declaratively, and questions probe whether you know which changes are configuration versus which require a different mechanism.
What to do instead
For each common change (add an attribute, add a related entity, add a reference/lookup, change a label, add a validation) record whether it is done through configuration in the application, and note any that require deployment or are restricted. Learn the boundary rather than the menu path.
Confusing hierarchy management with relationship or entity association, and picking hierarchy answers for questions about linking two records of different entity types.
Both involve connecting records, so the vocabulary overlaps. Hierarchy questions usually hinge on parent-child structure, levels, and validation of the tree, while relationship questions hinge on the association type between entities.
What to do instead
Define each term in one sentence with a distinguishing test: does it impose a level or rank structure, or is it a peer association? Then classify five example scenarios from the documentation under each heading and check your classification against the product behaviour described there.
Treating the 360 application's search and match configuration as a single setting, so questions about why a duplicate was not detected get answered with 'the match rule is wrong' when the cause is a missing or misconfigured standardization or match key.
Troubleshooting questions reward knowing the order in which a candidate record passes through cleansing and key generation. Candidates jump to the match rule because it is the most familiar component.
What to do instead
Practice a diagnostic sequence: inspect the incoming value, its standardized output, the generated match key, then the match rule and threshold. For each step write the observable symptom that would implicate that step, so you can map a described symptom to the correct stage.
Ignoring the operational side of the 360 applications - data ingestion, batch versus real-time loading, and monitoring - and answering only design questions correctly.
Study plans focus on modelling and matching because those feel like the 'real' content, and operational topics are skimmed. Exam items that ask how data arrives or how a load failure is surfaced then become guesswork.
What to do instead
Create a short section on data flow: sources, ingestion method, load frequency, and where errors or rejected records are visible. Learn the distinction between scheduled batch and near-real-time ingestion and one consequence of each for matching behaviour.
Assuming every user sees every record, and answering access questions with a single global permission model instead of distinguishing role-based access from record-level or segment-level visibility.
Security questions read as generic RBAC questions, so candidates apply a flat role model. The exam probes whether you know that visibility can be scoped to a subset of data for a given user or team.
What to do instead
Write two separate notes: what a role grants (capabilities and screens) and what scopes visibility (data segments or equivalent). For a scenario where a user can edit records but must not see a region, decide which of the two mechanisms is being tested before answering.
Choosing answers that describe the on-premises MDM hub architecture (hub server, cleanse server, operational store) when the question is about MDM SaaS, because the option sounds technically precise.
Distractors are written using real Informatica terminology from the on-premises product line. Recognising the words creates false confidence even though the architecture does not apply to the SaaS offering.
What to do instead
Maintain an explicit 'not in SaaS' list of on-premises components and their SaaS equivalents or absence. Before selecting an option containing a component name, confirm it appears in the SaaS documentation for the capability being asked about.
Skipping the 360 application's data quality and validation features, then treating validation failures as matching failures when a question describes a record being rejected or flagged.
Validation and matching both produce 'bad record' outcomes, and candidates who did not study validation rules have only one explanation available. The question's wording usually distinguishes rejection at entry from failure to consolidate.
What to do instead
Learn where validation rules are applied in the record lifecycle and what happens to a record that fails (rejected, flagged, or blocked from promotion). Contrast that with the outcome of a failed match, and write one sentence describing each outcome as a user would observe it.