ICCP CDP common mistakes
ICCP CDP · Understand the traps and how to avoid them.
Answering data-management questions by recalling a specific vendor tool's feature list (for example describing how one ETL suite handles slowly changing dimensions) instead of naming the general technique and its trade-offs.
Candidates with hands-on tool experience default to the product they use daily, and vendor terminology feels more precise than abstract concepts. ICCP-style items test vendor-neutral principles, so a tool-specific answer often names the wrong mechanism or misses the concept being probed.
What to do instead
Before answering, restate the question in generic terms: what is the data problem (history tracking, deduplication, referential integrity) and which standard technique solves it. Practise writing one-sentence definitions of core techniques (Type 1/2/3 slowly changing dimensions, star versus snowflake schema, conformed dimension, surrogate key) with no product names, and check that each definition states when the technique is and is not appropriate.
Treating metadata, data quality, and master data as synonyms, so a question asking which component enforces uniqueness of a customer identifier gets answered with 'metadata repository' or 'data quality dashboard'.
These areas overlap in practice and are often discussed together in tooling, so candidates blur the boundaries. Exam items deliberately test the distinction between definitional metadata, measured quality, and governed shared entities.
What to do instead
Build a three-column comparison table: metadata (defines and describes data), data quality (measures conformance to defined rules), master data (the governed golden record shared across systems). For each, list two artefacts (data dictionary, business glossary; quality scorecard, rule catalogue; customer master, product master) and one owner role. Rehearse the table until you can place any scenario in the correct column within seconds.
Choosing an operational or normalized model when an item asks for the structure best suited to analytical querying, or choosing a star schema when the requirement is high-volume transactional integrity.
Candidates memorise 'warehouse equals star schema' without linking the model to the workload. Items frequently present a scenario (frequent single-row updates versus large aggregate scans) and expect the model to follow from the access pattern.
What to do instead
For every practice scenario, first classify the workload as transactional or analytical, then justify the model choice in one sentence: normalized third normal form for write integrity and low redundancy; dimensional star for predictable aggregation and ease of use; snowflake only when dimension hierarchies must be normalized. Write out the cost of the wrong choice (join complexity, update anomalies, query performance) so the reasoning, not the label, drives the answer.
Confusing grain with primary key when asked to define the level of detail in a fact table, and then selecting an answer that describes a surrogate key or a degenerate dimension.
Grain is described in plain language ('one row per order line per day') while keys are technical objects, and candidates under time pressure grab the more familiar technical term. Items test whether you can state grain declaratively before designing keys.
What to do instead
Practise the discipline of writing the grain sentence first for any fact-table scenario, using the pattern 'one row per per '. Then list which dimensions are foreign keys at that grain and which attributes are degenerate. If an answer option describes a key rather than a level of detail, eliminate it immediately.
Assuming a data warehouse refresh is a single load, and answering questions about late-arriving facts or changed dimension attributes with 'reload the whole table nightly'.
Batch-oriented mental models dominate candidate experience, and full reload appears simple and safe. Items probe incremental loading, change data capture, and history preservation, where full reload either loses history or is infeasible at volume.
What to do instead
Map each load pattern to its purpose: full extract-reload for small reference tables, incremental delta with high-water mark for large fact tables, change data capture for source systems that cannot be queried wholesale, and Type 2 dimension processing for attribute history. For each, state one risk it introduces (missed deletes, duplicate deltas, unbounded dimension growth) so you can recognise the scenario the item describes.
Describing data governance as a documentation exercise (writing policies, publishing a glossary) and omitting decision rights, accountability, and enforcement mechanisms when an item asks what makes governance effective.
Governance programmes often start with artefacts because they are visible and easy to produce, and candidates absorb that framing. Items test whether you know that without assigned owners, escalation paths, and consequences, artefacts do not change behaviour.
What to do instead
Frame every governance answer around three elements: a decision right (who decides), an accountability (who is answerable for the outcome), and an enforcement mechanism (policy, control, or gate in the development lifecycle). Rehearse examples: data owner versus data steward versus data custodian, and how a stewardship council escalates a disputed definition. If an answer option contains only documentation with no decision or enforcement, treat it as incomplete.
Treating a data steward and a data owner as interchangeable, so items about approving access or resolving conflicting definitions are answered with the wrong role.
Organisations use these titles inconsistently, and job descriptions often blend the duties. Exam items rely on a stable distinction between accountability for the data domain and day-to-day stewardship activity.
What to do instead
Anchor the distinction in accountability: the owner is accountable for a data domain, approves policy and access decisions, and accepts risk; the steward executes on behalf of the owner, maintains definitions and quality rules, and resolves issues within delegated authority; the custodian implements technical controls. Write a short scenario for each role and check that your chosen role could plausibly make the decision described without needing approval from someone else.
Answering data quality questions with 'clean the data' rather than identifying the specific dimension (completeness, accuracy, consistency, timeliness, uniqueness, validity) that the scenario violates.
'Clean the data' is the habitual response from project work, and candidates do not practise mapping symptoms to named dimensions. Items describe a symptom and expect the dimension, so a generic answer cannot be matched to an option.
What to do instead
Create a symptom-to-dimension drill: missing mandatory values means completeness; value disagrees with the real-world source means accuracy; two systems disagree means consistency; record arrives after the decision window means timeliness; duplicate customer records means uniqueness; value outside an allowed domain means validity. For each dimension, also note a plausible measurement method (null rate, reconciliation sample, cross-system match rate) so you can handle items that ask how to detect the problem.
Confusing correlation with causation, or treating a statistically significant result as a practically important one, when interpreting an analytics scenario.
Candidates read the headline finding and skip the study design and effect size. Items deliberately include confounders, selection effects, or trivial effect sizes to test whether the interpretation matches the evidence.
What to do instead
Apply a fixed checklist to every analytics scenario: what was the comparison group, was assignment random, what confounders were measured, what is the effect size in business units, and what is the confidence interval. State the conclusion in a form that matches the design ('associated with' for observational, 'caused' only for controlled designs). Rehearse two or three examples where a significant but tiny effect should not drive a decision.
Selecting a predictive modelling approach by reputation (for example 'use a neural network because it is most accurate') without matching it to data volume, interpretability requirements, or the target variable type.
Candidates associate advanced methods with better results and overlook constraints that items explicitly supply, such as a small labelled dataset, a regulatory need to explain decisions, or a binary outcome.
What to do instead
Before choosing a method, extract three facts from the scenario: target type (classification or regression), data volume and label availability, and interpretability constraint. Then apply simple rules: small tabular data favours regularised regression or tree ensembles; strict explainability favours linear or rule-based models; large unstructured data justifies deep learning. Practise stating the trade-off in one sentence so you can defend the choice and reject an over-engineered option.