CDDP common mistakes
CDDP · Understand the traps and how to avoid them.
Treating 'data governance' as a synonym for 'data security' and answering access-control questions with governance frameworks or vice versa, so the chosen option addresses the wrong discipline entirely.
The two domains overlap in vocabulary (stewards, policies, controls), and candidates who studied security first pattern-match on words like 'policy' and 'restriction' without checking whether the stem is about decision rights and accountability or about protecting data from unauthorized use.
What to do instead
Before answering, write one word in the margin: 'who decides' (governance) or 'who can access' (security). If the stem names roles such as owner, steward, or council, it is governance; if it names authentication, encryption, masking, or classification levels, it is security. Drill with mixed sets of 20 stems and label each before looking at options.
Choosing the most comprehensive-sounding governance answer (a central council approving every data decision) instead of the option that assigns accountability closest to the data, and missing questions about operating models and decision rights.
Candidates equate maturity with centralization, but governance design questions usually reward federated or hub-and-spoke models where domain owners hold accountability and the central function sets standards. The distractor is written to sound thorough.
What to do instead
Memorize the trade-off explicitly: centralization buys consistency at the cost of speed; federation buys speed and context at the cost of consistency; the hub model exists to balance them. For any operating-model question, ask which failure the scenario is complaining about (slow decisions vs inconsistent definitions) and pick the model that fixes that failure.
Confusing conceptual, logical, and physical models, and picking a model that includes indexes, partitions, or vendor data types when the stem asks for a technology-independent design.
The three levels share entities and relationships, so the options look nearly identical. Candidates latch on to whichever option mentions the most detail, assuming more detail means more correct.
What to do instead
Use a three-question filter on every modeling stem: does it mention business terms only (conceptual), business terms plus attributes, keys and cardinality but no product names (logical), or product-specific types, indexing and storage (physical)? Eliminate any option that jumps a level in either direction before comparing what remains.
Applying third normal form reflexively to every design scenario, including analytical or event-history cases where denormalization or a dimensional structure is the intended answer.
Normalization is taught first and drilled hardest, so it becomes the default. Candidates miss the cue in the stem that the workload is read-heavy reporting, or that the requirement is to preserve point-in-time history.
What to do instead
Classify the workload before choosing a structure: transactional writes with frequent updates favor normalized form; analytical reads with large scans favor star schemas with conformed dimensions; append-only history favors immutable or bitemporal designs. If the stem mentions reporting latency, aggregation, or 'as of' questions, normalization is almost never the answer.
Answering integration questions by naming a tool or pattern (ETL, ELT, CDC, streaming) without matching it to the latency, volume, and transformation-location constraints stated in the stem.
Pattern names are memorable and candidates associate them with modernity, so streaming or ELT gets selected even when the stem describes nightly batch reconciliation with heavy transformation on a constrained source system.
What to do instead
Extract three facts from every integration stem before reading options: required latency, where transformation must occur, and whether the source can tolerate extraction load. Then apply rules: transformation on a constrained source pushes work downstream (ELT); near-real-time needs require log-based CDC or streaming rather than batch extracts; full reloads are disqualified when volume or window is limited.
Treating data quality dimensions as interchangeable, so a stem about duplicate customer records is answered with a completeness or timeliness remedy rather than a uniqueness remedy.
The dimensions are defined in overlapping prose, and remediation actions (profiling, cleansing, validation) appear in options for every dimension, so the option that sounds most thorough wins over the option that targets the actual defect.
What to do instead
Build a one-line diagnostic per dimension: completeness = missing values; uniqueness = duplicates; validity = format or domain violation; consistency = conflicting values across systems; accuracy = value disagrees with reality; timeliness = value arrives too late. Read the symptom in the stem, name the dimension silently, then reject any option that remediates a different one.
Confusing master data management with data quality tooling, choosing 'run a cleansing job' when the stem describes conflicting customer identifiers across systems that need a survivorship and stewardship process.
Both domains use the same vocabulary (matching, deduplication, golden record), so candidates pick the tactical fix. MDM questions usually hinge on governance of identity and cross-system agreement, not on a single cleanup run.
What to do instead
Ask whether the problem recurs after cleansing. If the same conflict will reappear because multiple systems of entry persist, the answer is an MDM capability (match/merge rules, survivorship rules, stewardship workflow, hierarchy management). If it is a one-time defect in a single dataset, it is data quality. Also expect questions on which system is the system of record, and answer with the system that owns creation, not the one with the most copies.
Misreading statistical significance as practical importance, or interpreting a p-value as the probability that the null hypothesis is true, and selecting options that make causal claims from observational data.
These are the classic misinterpretations, and distractors are written to match them exactly. Candidates under time pressure pick the option that sounds like the textbook phrase they half-remember.
What to do instead
Apply three checks: a p-value is the probability of data this extreme if the null were true, not the probability the null is true; significance says nothing about effect size, so check whether the stem gives a confidence interval or magnitude; and only randomized or well-controlled designs support causal wording. Eliminate any option containing 'proves', 'causes', or 'probability that the hypothesis is true'.
Choosing a chart type by habit (pie for composition, bar for everything, 3D or dual-axis for impact) instead of by the comparison the audience must make, and ignoring perceptual accuracy questions.
Candidates answer with the chart they would personally build rather than the one the stated task requires, and they underestimate how often the exam tests ranked perceptual accuracy (position and length beat area and angle).
What to do instead
Map task to chart before reading options: ranking or comparison across categories uses bars; trend over time uses lines; part-to-whole with few categories uses stacked bars or a single pie only when categories are two or three; distribution uses histograms or box plots; correlation uses scatter. Reject any option using area, angle, or volume to encode a precise value, and reject dual axes when the stem does not require two units.
Selecting the strongest control (encryption everywhere, full masking) rather than the control that fits the data state, the use case, and the least-privilege requirement, and missing questions on anonymization versus pseudonymization.
Candidates equate maximum protection with the correct answer, but privacy questions often test proportionality and utility: encryption at rest does not stop an authorized analyst from seeing sensitive fields, and pseudonymized data remains personal data.
What to do instead
For each privacy stem, identify the data state (at rest, in transit, in use) and the actor (external attacker, privileged insider, analyst, third party). Match the control to that pair: encryption at rest for storage theft, masking or tokenization for analyst visibility, aggregation or differential privacy for released statistics. Remember pseudonymization is reversible with a key and stays in scope of personal-data obligations, while anonymization must be irreversible.
Answering platform and emerging-technology questions by picking the newest-sounding option (lakehouse, vector database, real-time everything) without checking whether the workload, consistency, and cost constraints in the stem support it.
Buzzword familiarity substitutes for trade-off reasoning, and vendors promote each architecture as universally superior. The exam instead tests whether the candidate can match architecture to requirement.
What to do instead
For every platform stem, write the four constraints first: data variety (structured vs unstructured), access pattern (point lookups vs scans vs similarity search), consistency requirement, and cost or operational maturity limit. Then eliminate architectures that fail a stated constraint, for example a vector store proposed for transactional ledger queries, or a streaming platform proposed for a monthly reconciliation with no latency requirement. Choose the simplest architecture that satisfies all four.