DMLI common mistakes
DMLI · Understand the traps and how to avoid them.
Treating data governance as purely a documentation exercise-memorizing framework names (DAMA, COBIT) without being able to apply roles, decision rights, and accountability to a scenario.
Candidates study governance frameworks as lists to be recalled, so they can name a council but cannot say who owns a data quality decision or how a steward differs from an owner in a given situation.
What to do instead
For each governance concept, write a one-paragraph scenario and practice assigning the role, the decision right, and the escalation path. Focus on distinguishing owner, steward, custodian, and council by what each decides rather than by title.
Confusing data quality dimensions (completeness, accuracy, consistency, timeliness, uniqueness, validity) and applying the wrong one to a described defect.
The dimensions overlap in everyday language; candidates match on surface words like 'missing' or 'wrong' instead of the formal definition, and they do not test themselves with ambiguous examples.
What to do instead
Build a table of each dimension with its formal definition and two contrasting examples. Practice classifying defects where multiple dimensions could plausibly apply and justify why one is primary.
Mixing up conceptual, logical, and physical data models-especially attributing physical constructs (indexes, partitions, data types) to logical models or treating a conceptual model as containing attributes.
Candidates learn the three levels as a memorized sequence and never practice identifying which artifact a described feature belongs to.
What to do instead
For each model level, list what it must contain and what it must not contain. Then take a set of features (entity names, primary keys, indexes, relationships, business definitions) and sort them into the correct level.
Choosing normalization or denormalization reflexively-always normalizing for OLTP or always denormalizing for analytics-without reading the stated workload, performance, or integrity constraints in the question.
Candidates memorize 'normalize for transactions, denormalize for reporting' as a slogan and stop analyzing the specific trade-offs the scenario presents.
What to do instead
Practice questions that state conflicting goals (e.g., write integrity versus read performance) and justify the choice using the stated constraints. Explicitly name the trade-off being accepted.
Confusing data integration patterns-ETL versus ELT, batch versus streaming, and when to use each-and selecting a pattern based on trend rather than on volume, latency, and transformation-location requirements.
The patterns are learned as definitions without decision criteria, so candidates cannot map a described requirement (near-real-time, large volume, transformation in target) to the right pattern.
What to do instead
Create a decision matrix with columns for latency, volume, transformation location, and source/target capability. Practice mapping scenario requirements to a pattern and stating the deciding factor.
Treating compliance and privacy requirements as a single checklist-conflating purpose limitation, consent, retention, and data subject rights-and applying the wrong control to a described situation.
Candidates memorize regulation names and broad principles but do not practice distinguishing which specific obligation a scenario triggers.
What to do instead
For each principle (lawful basis, purpose limitation, minimization, retention, subject access, erasure), write a short scenario and identify the obligation and the evidence needed to demonstrate compliance.
Selecting analytics or BI techniques (descriptive, diagnostic, predictive, prescriptive; star schema versus flat table) by label rather than by the business question being asked.
Candidates match on familiar terms in the question stem instead of identifying the decision the stakeholder needs to make.
What to do instead
Practice restating each scenario as a business question first, then choosing the technique that answers it. Justify the choice by the question type, not by the technique's popularity.
Ignoring the ethical and professional-practice dimension-answering a scenario purely on technical or legal grounds when the question tests stewardship, bias, transparency, or conflict of interest.
Candidates treat ethics as common sense and do not practice identifying the ethical dimension embedded in technical scenarios.
What to do instead
For each technical scenario, add a column asking 'who is affected, what is the bias risk, and what must be disclosed?' Practice spotting the ethical layer before choosing an answer.
Confusing data architecture components-data warehouse, data lake, data lakehouse, operational data store, master data management-and assigning the wrong component to a described need.
The terms overlap and marketing usage blurs them; candidates learn definitions in isolation without comparing purpose, structure, and governance implications.
What to do instead
Build a comparison table of purpose, data structure, latency, and governance for each component. Practice mapping a stated need (single source of truth for customers, raw storage for exploration) to the right component.
Answering leadership and professional-practice questions with generic management platitudes instead of the specific data-management behavior the scenario calls for (e.g., establishing ownership, measuring value, managing change).
Candidates underprepare for non-technical domains, assuming experience substitutes for the exam's specific framing of data leadership and value delivery.
What to do instead
Study the leadership domain as explicitly as the technical ones: for each concept (data ownership, data value, change management, communication with executives), write a scenario and the concrete action a data leader should take.