CDGP common mistakes
CDGP · Understand the traps and how to avoid them.
On questions asking for the FIRST or BEST step in standing up governance, the candidate selects a concrete deliverable - buy a data catalog, write a data quality dashboard, charter a steering committee with named executives - instead of the enabling activity the framework places upstream.
Candidates mentally substitute 'what would my employer do' for 'what does the DMBOK governance context describe.' Tooling and org charts feel decisive and tangible, so they win the gut check even when the question is testing the sequencing of policy before enforcement.
What to do instead
Drill the governance context diagram until you can state the sequence from the top: mission and strategy, then goals and principles, then policy, then the operating model and accountabilities, then the enabling processes. When a stem says 'first', scan the options and reject any that is an execution artifact before a decision artifact exists.
The candidate uses data owner, data steward, and data custodian interchangeably, or assigns technical enforcement duties to the data owner because the owner 'is accountable for the data'.
In most real organizations these titles are applied loosely or collapsed into one person, so the candidate's lived vocabulary contradicts the exam's separation of accountability from execution and from technical custody.
What to do instead
Fix the three-way split in memory: the owner is the accountable business decision-maker for a data domain (approves definitions, access, quality thresholds); the steward executes and coordinates on the owner's behalf within a domain; the custodian (often IT/DBA) applies the technical controls the owner authorizes. Any option that has the owner personally running backups, tuning databases, or writing ETL is a distractor.
Given a scenario describing business units with strong local autonomy, distinct regulatory regimes, or acquired subsidiaries, the candidate reflexively picks a centralized governance model because it sounds more rigorous and easier to control.
Centralization is the intuitive default for 'good governance', and candidates optimize for the answer that sounds most disciplined rather than the one that matches the organizational constraints stated in the stem.
What to do instead
Read the stem for signals and map them explicitly: highly regulated single business with strong executive sponsorship points to centralized; autonomous units with local expertise point to decentralized; shared enterprise standards with local execution points to federated. Write the signal words on scratch paper before looking at the options.
The candidate treats governance as one of the sequential phases in the data lifecycle and places it, for example, between data creation and data maintenance, or answers that the lifecycle ends at 'use' with no disposition phase.
Governance is a horizontal band in the DAMA wheel, so it appears next to the lifecycle activities in every diagram; static diagrams read left-to-right and candidates flatten the vertical/horizontal relationship into a sequence.
What to do instead
Rehearse the lifecycle as a named ordered list - plan, design and enable, create and acquire, maintain and use, enhance, dispose/archive - and separately memorize that governance is cross-cutting oversight that applies at every phase rather than a phase itself. Any option that sequences governance inside the lifecycle is wrong by construction.
The candidate can list the knowledge areas by name but cannot say which knowledge area produces or consumes a given artifact, so questions phrased as 'which activity supplies the input to X' are answered by the most familiar-sounding knowledge area.
Flashcard-style study builds vocabulary but not the dependency graph. Under time pressure the candidate matches on topic keywords in the stem rather than on the direction of the artifact flow.
What to do instead
For each knowledge area, write one line in the form 'produces → consumes'. Practice the common pairs explicitly: data architecture and modeling produces the models and definitions that metadata management stores; metadata management supplies the lineage and definitions that data quality management uses to test; data governance approves the policies that both enforce.
The candidate collapses data quality dimensions - scoring a field that is populated but formatted wrongly as an accuracy problem, calling a duplicate-record issue a consistency problem, or treating 'validity' and 'accuracy' as synonyms.
In ordinary speech these words overlap heavily, and many real data quality tools label their rule types differently from the framework, so the candidate's intuition and the exam's definitions conflict at the moment of choosing.
What to do instead
Anchor each dimension to a single test question and answer the question before reading options: completeness - is it there; accuracy - does it match the real-world truth; validity/conformance - does it match the agreed format, type, or domain; uniqueness - is it duplicated; consistency - does it agree across systems or across fields; timeliness - is it current and available when needed. Then pick the option matching your answer, not the option with the most authoritative wording.
When a stem describes recurring quality failures or asks how to prevent recurrence, the candidate selects the remediation option - cleanse the records, re-run the load, add a manual review step - instead of the root-cause or control option.
Cleansing is the visible, satisfiable action that operations teams actually perform, so it feels like the responsible answer. Preventing failures requires accepting an indirect, slower payoff, which candidates systematically underweight on multiple-choice items.
What to do instead
Treat 'prevent', 'reduce recurrence', 'sustain', and 'root cause' in the stem as hard filters: eliminate every option that only fixes existing records. The correct answer will usually involve profiling to find the cause, changing the process or system that introduced the defect, or establishing a control with an owner and threshold.
The candidate misclassifies metadata into business, technical, and operational buckets, and treats data dictionary, business glossary, data catalog, and lineage repository as interchangeable names for one artifact.
Vendors bundle all four capabilities into a single product marketed as a 'catalog', and in practice one tool displays all of them, so the distinctions that the exam draws between the underlying artifacts disappear from the candidate's mental model.
What to do instead
Classify by who the consumer is and what question the artifact answers: glossary - business terms and agreed definitions for business users; dictionary - data element structure, type, and format; catalog - inventory of what data exists and where; lineage - how data moves and transforms. For the metadata types, sort by owner and purpose: business metadata documents meaning and rules, technical metadata documents structure and systems, operational metadata documents runs, volumes, and errors.
The candidate assigns physical implementation constructs - surrogate keys, indexes, partitioning, platform-specific data types, denormalization for performance - to a logical or conceptual model, or describes a conceptual model as containing attributes and primary keys.
Most candidates have only ever built one kind of model and call it 'the model', so every element of their practical experience gets attributed to whichever level the question names.
What to do instead
Memorize the levels by what each is allowed to contain and what it excludes: conceptual - business entities and relationships only, no attributes, no keys, technology-neutral; logical - attributes, relationships, business keys, fully attributed and normalized, still technology-independent; physical - tables, columns, data types, indexes, surrogate keys, and platform specifics. Before answering, name the level in the stem and strike any option containing a construct from a lower level.
The candidate confuses normalization and dimensional design - recommending third normal form for an analytical warehouse requirement, mixing up fact and dimension tables, or choosing snowflake when the stem asks for the simplest structure that minimizes joins for business users.
Both are 'data modeling' and both appear in architecture questions, so topic-level matching lets the candidate select a technically respectable answer that solves the wrong problem. Fact/dimension confusion comes from never having had to state the grain explicitly.
What to do instead
Decide by workload first: operational, integrity-critical, write-heavy processing points to normalized relational design; analytical, query-heavy, business-facing reporting points to dimensional design. For dimensional items, always state the grain out loud - 'one row per what' - then classify: measurable events and their numeric metrics are facts, descriptive context you filter and group by is a dimension. For star versus snowflake, remember that the star denormalizes dimensions for simpler queries and fewer joins, and snowflake normalizes them for storage efficiency and change control at the cost of join complexity.