CDMP common mistakes
CDMP · Understand the traps and how to avoid them.
Treating the DAMA-DMBOK 'wheel' as a list of eleven independent functions and answering questions as if each function operates in isolation, rather than recognizing that governance, metadata, and data quality are presented as cross-cutting enablers that touch every other function.
Candidates skim the framework diagram once, memorize the eleven function names, and then study each chapter separately. Exam items frequently describe a scenario where, for example, a metadata repository is the mechanism that makes data quality monitoring possible, and the candidate must identify the relationship rather than a single function.
What to do instead
Redraw the DMBOK wheel from memory, then for each function write one sentence on how it depends on governance, metadata, and data quality. Practice scenario questions by naming both the primary function and the enabling function before choosing an answer.
Confusing data modeling levels by naming a physical model when the scenario describes entities and relationships with no DBMS-specific detail, or selecting 'logical' for a diagram that already shows indexes, data types, and tablespaces.
The three-level convention (conceptual/logical/physical) is stated simply in study material, so candidates memorize the labels but never practice classifying real descriptions. Exam stems often include one detail (a primary key, a data type, a denormalization) that is the deciding clue.
What to do instead
Build a decision rule: conceptual = business terms and scope only; logical = attributes, keys, relationships, fully normalized, DBMS-independent; physical = tables, columns, data types, indexes, partitioning, denormalization for performance. Scan each stem for DBMS-specific nouns before answering.
Answering metadata questions as if metadata means only technical metadata, ignoring business metadata and operational metadata when the scenario is about glossary terms, data stewards, or job run statistics.
Candidates with engineering backgrounds default to 'metadata = column definitions and schemas'. The exam tests the three-type taxonomy and expects the candidate to classify a described artifact correctly.
What to do instead
Memorize the three categories with examples: business (glossary, definitions, ownership), technical (schema, lineage, models), operational (job logs, run times, error counts). For each practice item, label the artifact's category before reading the options.
Choosing 'data cleansing' as the fix for every data quality scenario, including ones where the stem describes a root-cause problem in source entry, a missing control, or an unclear definition.
Cleansing is the most familiar DQ activity, so it becomes a default answer. The exam rewards candidates who distinguish preventive controls (validation at entry, defined business rules) from corrective remediation (cleansing, standardization) and from measurement (profiling, scorecards).
What to do instead
Apply a three-way test to each DQ stem: is the problem definition, prevention, or correction? Map to the matching DQ activity. If the stem mentions recurring errors or unknown cause, prefer profiling and root-cause analysis over cleansing.
Treating Data Governance as a synonym for a data quality program or an IT project, and selecting answers where the CDO or data stewards 'fix the data' rather than define policy, decision rights, and accountability.
Governance is abstract and candidates substitute the concrete activity they know (cleansing, tooling) for the governance concept. Exam items test decision rights, stewardship roles, and policy-setting as distinct from execution.
What to do instead
Internalize the definition: governance is the exercise of authority and control over data management, covering what decisions are made, who makes them, and how they are monitored. Reject any option where the governance body performs hands-on data work; prefer options about policy, standards, roles, and escalation.
Mixing up Inmon and Kimball approaches by assigning the normalized enterprise warehouse to Kimball or the star-schema dimensional marts to Inmon, and then answering architecture questions from the wrong premise.
Both names appear together in study material and candidates memorize 'Inmon = warehouse, Kimball = marts' without attaching the modeling style and design order (top-down normalized vs. bottom-up dimensional).
What to do instead
Anchor each name to its signature: Inmon = top-down, normalized (3NF) enterprise data warehouse, subject-oriented and integrated; Kimball = bottom-up, dimensional (star schema, fact and dimension tables), bus matrix for conformed dimensions. State both pairs aloud before answering.
Using 'master data' and 'reference data' interchangeably, or failing to classify a described data set (for example, currency codes versus customer records) correctly.
The two terms are often taught in one chapter and sound similar. The exam distinguishes them by cardinality and change frequency, and by whether the set describes entities or classifies them.
What to do instead
Use the discriminator: reference data is a controlled set of permitted values used to classify or categorize (codes, hierarchies, lookups), relatively static and shared; master data describes key business entities (customer, product, employee, location) with attributes and lifecycles. Classify the example before reading options.
Assuming data integration means ETL only, and rejecting answers involving ELT, CDC, virtualization, or messaging when the stem describes real-time or high-volume requirements.
ETL is the historical default and candidates map 'integration' to it automatically. Exam items test selection of the appropriate pattern based on latency, volume, and transformation location.
What to do instead
Build a pattern-to-trigger table: batch ETL for scheduled transformation before load; ELT when target warehouse compute is strong; CDC for low-latency change capture; virtualization for on-demand access without persistence; messaging/streaming for event-driven near-real-time. Match the stem's latency and volume cues to the pattern.
Ignoring the exam's structure and weighting, spending equal study time on all domains instead of concentrating on the heavier and more conceptually tested areas such as governance, data quality, and modeling, and never doing timed practice.
Candidates study chapter by chapter in book order and run out of time on scenario items that require reading a long stem carefully. Without timed practice, pacing problems surface only on exam day.
What to do instead
Obtain the official domain weighting for your exam version, allocate study hours proportionally, and do at least two full-length timed practice sets. Track per-domain accuracy and re-study any domain below roughly 70 percent.
Memorizing definitions in isolation and then failing scenario items that require applying a concept to a described situation, such as choosing between a data steward and a data owner, or between a business glossary and a data dictionary.
Definition recall feels productive and is easy to self-test, but the exam is largely application-based. Candidates recognize a term and pick the option containing it, even when the scenario calls for a different role or artifact.
What to do instead
Convert every definition into a 'which would you use when' pair. Practice by writing two-sentence scenarios for each key term and choosing between confusable pairs (owner vs. steward, glossary vs. dictionary, profiling vs. cleansing, reference vs. master data).