DEA Level 3 common mistakes
DEA Level 3 · Understand the traps and how to avoid them.
Treating data governance as a documentation exercise and answering questions by naming a policy, standard, or council as the solution, rather than identifying the decision rights, accountability, and enforcement mechanism the scenario actually requires.
Candidates memorise governance artifacts (policies, charters, stewardship roles) as vocabulary and default to the artifact name whenever a governance term appears in a stem, without checking what the scenario's problem actually is.
What to do instead
For every governance question, first identify who decides, who is accountable, and what happens when the rule is broken. If the stem describes conflicting definitions, ownership disputes, or unenforced rules, the answer must address decision rights or enforcement, not just the existence of a document.
Conflating data quality dimensions and choosing 'accuracy' or 'completeness' as the answer for any quality scenario, instead of matching the specific dimension to the symptom described.
Accuracy and completeness are the most familiar dimensions, so candidates anchor on them and skim past the specific symptom (duplicate records, inconsistent formats, stale values, broken referential links) that points to uniqueness, consistency, timeliness, or integrity.
What to do instead
Before answering, write down the exact symptom in the stem and map it to a dimension: duplicates to uniqueness, format or unit mismatch to consistency, missing values to completeness, wrong values to accuracy, aged values to timeliness, orphaned keys to integrity. Choose the dimension the symptom names, not the most familiar one.
Selecting a normal form or denormalisation answer based on the word 'normalise' appearing in the stem, without checking whether the scenario's driver is write integrity or read performance.
Candidates learn normalisation as the 'correct' modelling practice and treat denormalisation as an error, so they pick the most normalised option even when the stem describes reporting latency, join cost, or analytical query performance.
What to do instead
Classify the workload first: transactional write-heavy with update anomalies points to higher normal form; analytical read-heavy with expensive joins points to deliberate denormalisation such as star schemas or wide tables. State the workload type before evaluating options.
Confusing dimensional modelling roles, labelling a dimension as a fact table or vice versa because it contains a numeric column or a key, rather than classifying by grain and business event.
Candidates use the presence of numbers or IDs as the classifier instead of asking what one row represents, so degenerate dimensions, factless fact tables, and numeric measures in dimensions get misclassified.
What to do instead
For each table in the scenario, state in one sentence what a single row represents. If a row is a business event or transaction at a declared grain, it is a fact; if a row is a descriptive entity, it is a dimension. Numeric attributes do not make a table a fact.
Choosing full refresh over incremental load, or batch over CDC, by default, without weighing the stem's stated constraints on volume, latency, and source system impact.
Full refresh and batch are the simplest patterns to reason about, so candidates default to them and ignore explicit cues such as high volume, near-real-time requirements, or a source system that cannot tolerate repeated full extracts.
What to do instead
Extract the three constraints from the stem (data volume, required latency, source system load tolerance) and test each option against all three. High volume plus low latency plus source sensitivity points to CDC-based incremental loading; small volume plus relaxed latency permits full refresh.
Designing pipelines without addressing idempotency, late-arriving data, or failure recovery, and picking an option that describes a happy-path flow only.
Candidates focus on the transformation logic in the stem and treat operational concerns like reruns, duplicates, and out-of-order events as out of scope, so they select the option that reads most like the described business flow.
What to do instead
For every pipeline question, check whether the chosen option survives a rerun (no duplicate rows), handles records arriving after the cutoff, and specifies what happens on partial failure. If an option is silent on these, prefer the option that explicitly addresses them.
Treating correlation as causation or selecting an answer that overstates predictive confidence, when the stem presents an observational finding without a controlled comparison.
Stems are written to sound conclusive, and candidates read the described pattern as established fact rather than interrogating the study design, sample, or confounders behind it.
What to do instead
Before choosing, ask what the comparison group is and whether confounders were controlled. If the stem describes an observed association with no experiment or control, the correct answer will hedge, name confounders, or recommend a test rather than assert a causal or predictive claim.
Answering model evaluation questions with accuracy as the metric regardless of class balance, and ignoring the cost asymmetry the scenario describes.
Accuracy is the default metric candidates reach for, and stems rarely say 'the classes are imbalanced' explicitly, so candidates miss that a rare-event or high-cost-of-error scenario requires precision, recall, or a cost-weighted measure.
What to do instead
Check the stem for base rates and error costs. If the event is rare or one error type is far more expensive (missed fraud, missed defect), select precision, recall, F1, or a cost-based metric and justify it against the stated business cost, not overall correctness.
Treating compliance as satisfied by obtaining consent or by masking a field, rather than matching the control to the specific obligation the scenario invokes, such as purpose limitation, retention limits, or cross-border transfer restrictions.
Consent and masking are the most salient privacy controls, so candidates apply them to every privacy scenario even when the stem concerns data retention, secondary use, or transfer to another jurisdiction.
What to do instead
Name the obligation first (lawful basis, purpose limitation, minimisation, retention, transfer, subject rights), then select the control that discharges that obligation. Consent answers lawful basis questions; it does not answer retention or transfer questions.
Choosing the most restrictive access control option for every security scenario, rather than selecting the control proportionate to the stated risk, data sensitivity, and operational need.
Candidates equate 'most secure' with 'correct', so they pick deny-all, full encryption everywhere, or the strictest role model even when the stem describes a low-sensitivity dataset with a legitimate broad-access requirement.
What to do instead
Grade the data sensitivity and the business need stated in the stem, then choose the least restrictive control that still meets the risk. If the stem describes low-sensitivity data with a documented need, over-restriction is the wrong answer and will be the distractor.
Answering programme delivery questions by naming a methodology (Agile, Waterfall, hybrid) instead of identifying the governance mechanism, decision gate, or stakeholder alignment step the scenario requires.
Candidates reduce delivery questions to methodology selection and overlook that most stems describe organisational friction: unclear ownership, competing priorities, or missing sponsorship, which methodology choice does not resolve.
What to do instead
Read the stem for the actual dysfunction. If the problem is unclear ownership, competing priorities, or absent sponsorship, the answer must establish accountability, prioritisation, or sponsorship, regardless of which delivery method is named.
Building a data strategy answer around tooling or technology acquisition when the stem describes a capability, operating model, or value-realisation gap.
Technology is concrete and easy to name, so candidates default to platform or tool answers even when the stem's symptoms are organisational, such as no shared definition of value, no roadmap, or no linkage between data work and business outcomes.
What to do instead
Identify whether the gap is capability, operating model, or value measurement before considering technology. If the stem shows no connection between data initiatives and business outcomes, the answer must establish outcomes, ownership, and a roadmap, with technology as an enabler rather than the solution.