Informatica CDGC Foundation common mistakes
Informatica CDGC Foundation · Understand the traps and how to avoid them.
Treating the Data Governance & Catalog domain as a pure navigation walkthrough - memorizing menu paths (Discover, Catalog, Governance) but never learning what each object type (asset, domain, glossary term, policy, rule) actually represents or how the objects relate.
The product UI is demo-friendly and candidates rehearse clicks, so surface familiarity masks the conceptual model. Exam items then ask relational questions (which object a rule attaches to, how a term links to an asset) that navigation knowledge cannot answer.
What to do instead
Build a one-page object model before drilling UI: asset types, business glossary terms, governance domains, policies, rules, and the association types between them. For each exam concept, write one sentence on 'what it is' and one on 'what it links to', then self-test by redrawing the model from memory twice a week.
Confusing business glossary terms with technical metadata assets - answering as if a glossary term is a column or a table is a business definition, and misassigning which layer owns naming, definitions, and stewardship.
Both appear in search results and can be linked, so the boundary blurs in casual use. The exam deliberately probes the business-versus-technical distinction because it drives governance workflows.
What to do instead
Adopt a fixed two-column mental table: business layer (glossary terms, definitions, owners, policies) versus technical layer (cataloged assets, columns, data types, lineage). Practice classifying 20 sample items into the correct layer and note the linking mechanism between them.
Mixing up governance roles - assigning stewardship, ownership, or approval duties to the wrong persona (for example, expecting a data steward to approve a policy or an owner to curate glossary definitions) in scenario questions.
Role names sound interchangeable in plain English, and candidates map them from job titles they know rather than from the product's responsibility model. Scenario items reward the product's precise division of duties.
What to do instead
Create a role matrix with rows for administrator, owner, steward, and consumer, and columns for create, edit, approve, and view. Fill it from documentation, then answer role-based practice scenarios strictly from that matrix rather than intuition.
Assuming data lineage is always complete and automatically accurate - selecting answers that treat lineage as authoritative without accounting for stitching, manual links, or gaps when transformations are not captured.
Lineage demos look clean on prepared data, so candidates over-trust it. Exam items test whether you know lineage can be partial and how manual or inferred links supplement automated capture.
What to do instead
Study how lineage is populated (automated parsing versus manual association) and where gaps arise. For each lineage question, ask 'is this link captured, inferred, or manual?' and choose the answer that reflects the actual mechanism rather than the ideal end state.
Treating data quality rules as standalone checks - ignoring how a rule binds to a governed object, how results surface as scores or exceptions, and how rule outcomes feed governance decisions.
Rules are often learned as SQL-like logic only, so the governance context (attachment point, scoring, remediation loop) is skipped. Items then ask where a rule attaches or what a score means.
What to do instead
Map the rule lifecycle end to end: define rule, attach to object, schedule or run, produce score or exception, route for remediation. Memorize the attachment targets and what each output type represents, then trace one rule through the full lifecycle on paper.
Skipping the search-and-discovery mechanics - not knowing how filters, facets, saved searches, and asset-type scoping change results, and answering as if search returns everything unfiltered.
Discovery feels intuitive, so candidates never learn the scoping model. Exam items about finding assets or narrowing results depend on knowing which controls constrain the result set.
What to do instead
List every discovery control (asset type, domain, facet, keyword, saved view) and what it constrains. Practice describing, in words, how you would locate a specific asset type within a domain, then verify each described step against documentation.
Memorizing configuration screens without understanding governance workflows - for example, knowing where a policy is created but not how it moves from draft to approved to enforced, or who acts at each stage.
Hands-on labs emphasize form fields, and candidates photograph screens instead of tracing process. Scenario questions test state transitions and approvals, not field locations.
What to do instead
Draw each workflow as a state diagram (draft, review, approved, active, retired) with the acting role on every arrow. Rehearse by describing a policy's journey aloud from creation to enforcement, and check each transition against documentation.
Overlooking stewardship and curation tasks - certification, endorsement, ratings, annotations, and issue or task assignment - and answering as if cataloging ends once an asset is ingested.
Ingestion is the visible first step, so post-ingestion curation is understudied. The exam treats curation as core governance value and tests those actions directly.
What to do instead
Build a 'post-ingestion checklist' of curation actions (certify, endorse, rate, annotate, assign steward, open issue) and learn what each signals to consumers. For each action, note who performs it and what changes in the catalog afterward.
Answering integration and metadata-ingestion questions from general data-catalog intuition rather than the product's model - guessing how external sources, scanners, or imported metadata behave instead of what the platform actually does.
Candidates transfer assumptions from other tools, and plausible-sounding options match those assumptions. The exam rewards product-specific behavior over generic best practice.
What to do instead
For every ingestion or integration topic, write the product-specific answer and flag any point you cannot verify. Mark uncertain items for review, confirm them in documentation, and never let a 'sounds reasonable' option override a verified product behavior.
Managing time and question style poorly - lingering on long scenario stems, misreading 'which is NOT' or 'best describes' wording, and leaving governance-scenario items unanswered at the end.
Scenario items are verbose and tempting to over-analyze, while negatively worded stems punish fast reading. The domain's conceptual overlap makes every option feel defensible, stretching time.
What to do instead
Practice with timed sets: read the final line of the stem first to identify the ask, underline negation words, eliminate two options, then choose. Cap time per item, flag and return later, and review every miss by labeling whether it was knowledge, misreading, or time pressure.