DACO common mistakes
DACO · Understand the traps and how to avoid them.
Treating governance as a documentation exercise: candidates describe producing policies, charters and a RACI but never state who has decision rights, how exceptions are escalated, or how compliance is measured, so answers read as artefacts rather than an operating model.
Study material on governance is full of templates, and candidates memorise the template headings instead of the decision mechanics. Exam items on this domain usually describe a scenario (conflicting definitions, a business unit refusing to adopt a standard) and ask what the data steward or council should do, which cannot be answered from a template.
What to do instead
For every governance artefact you revise, write one sentence naming the accountable role, one naming the escalation path, and one naming the metric that proves it works. Practise scenario questions by first identifying the decision right (who decides) before choosing an action.
Confusing data governance with data management and answering with execution activities (building pipelines, cleansing records, tuning storage) when the question is about oversight, policy and accountability.
The two terms overlap in everyday speech and many candidates come from engineering backgrounds where 'governance' informally means 'keeping things under control'. Distractor options are deliberately written as plausible technical actions.
What to do instead
Adopt a working test: if the action changes a system or a record, it is management; if it changes who decides, what is permitted, or how conformance is evidenced, it is governance. Run every option through that test before selecting.
Designing a model at a single level of abstraction, mixing conceptual entities with physical details such as indexes, surrogate keys or column data types in the same answer, or failing to normalise when the scenario calls for it.
Candidates learn modelling from tool screenshots where everything appears together, and they answer with whatever detail feels impressive rather than what the question's stated purpose requires. Questions often specify the audience (executives, developers) precisely to test this.
What to do instead
Before answering, state the purpose and audience in your own words, then commit to one level: conceptual for scope and vocabulary, logical for structure and relationships, physical for implementation. Remove any element that belongs to a different level, and check each non-key attribute depends on the whole key.
Choosing a storage or database technology by trend or by vendor familiarity rather than by matching access patterns, consistency needs, volume and latency to the engine's characteristics.
Candidates have hands-on experience with one or two platforms and unconsciously treat them as the default. Exam scenarios deliberately describe workloads (append-only time series, highly connected graphs, mixed read/write transactional work) whose properties rule out the familiar choice.
What to do instead
Build a small decision table: workload shape, consistency requirement, query pattern, growth rate, operational cost. For each practice scenario, extract those five facts first and only then evaluate options against them, justifying rejection as well as selection.
Ignoring operational responsibilities beyond the initial load: candidates omit backup and recovery testing, retention enforcement, capacity and growth planning, or job monitoring and alerting when asked how to run a data environment.
Design and build tasks feel more examinable than run tasks, so revision time skews towards modelling and integration. Questions about restore objectives, failed batch recovery or storage growth therefore catch candidates unprepared.
What to do instead
For each environment you study, write a one-page runbook covering backup frequency and restore testing, retention and purge jobs, capacity thresholds, and failure alerting. Learn to distinguish recovery point objective (acceptable data loss) from recovery time objective (acceptable downtime) and apply them to scenario numbers.
Treating security as a perimeter question and overlooking least privilege, segregation of duties, encryption in transit versus at rest, and the difference between authentication and authorisation in scenario answers.
Candidates reduce security to 'use strong passwords and a firewall', which is the vocabulary of general awareness training rather than data management. Distractor options often sound secure but grant excessive standing access or conflate the two encryption states.
What to do instead
For every scenario, ask four questions in order: who is the subject, what are they authenticated by, what exactly are they authorised to see or do, and how is that access logged and reviewed. Learn the standard controls by name (role-based access, least privilege, key management, masking, tokenisation) and what each does and does not protect.
Applying privacy rules without distinguishing personal data categories, lawful basis, purpose limitation and cross-border transfer constraints, or assuming that anonymisation and pseudonymisation are interchangeable.
Privacy regulation is jurisdiction-specific and candidates generalise from a headline they remember. Examination scenarios frequently hinge on whether data is still personal after processing, or whether a secondary use is compatible with the original purpose.
What to do instead
Learn the distinctions as definitions you can state in one line each: personal versus sensitive data, controller versus processor, pseudonymisation (re-identifiable with additional information) versus anonymisation (not reasonably re-identifiable). For scenario items, identify the purpose and lawful basis before evaluating the proposed use.
Confusing integration patterns: recommending batch extraction when near-real-time change propagation is required, or proposing direct database-to-database coupling where the scenario demands decoupling and replayability.
Pattern names are learned as vocabulary without their trade-offs, so candidates pick the pattern they have used rather than the one the latency, volume and coupling requirements imply. Questions embed latency and ordering clues that are easy to skim past.
What to do instead
Memorise a comparison of batch, change data capture, message queuing and event streaming across latency, ordering guarantees, replay, coupling and operational complexity. In each question, underline the latency and ordering requirements before reading the options.
Treating data quality as a one-off cleansing project, so answers propose fixing records rather than defining dimensions, measurement, root-cause remediation and ongoing monitoring with owners and thresholds.
Cleansing is the visible, satisfying part of quality work and the part candidates have usually done. Exam items ask how to prevent recurrence and how to report fitness for purpose, which requires the measurement and stewardship vocabulary candidates skip.
What to do instead
Learn the standard quality dimensions (completeness, accuracy, consistency, timeliness, uniqueness, validity) and be able to assign a concrete measurement to each. Frame every answer as define, measure, remediate at source, then monitor with a threshold and a named owner.
Answering analytics questions with tooling choices while ignoring the analytical question itself: candidates skip problem framing, data suitability checks, and interpretation of results such as confounding, sampling bias or correlation versus causation.
Analytics revision often becomes a tour of platforms and algorithms. Scenario questions reward candidates who interrogate whether the data can answer the question and whether the conclusion is warranted, and penalise those who jump to a technique.
What to do instead
Practise a fixed sequence on every analytics scenario: restate the decision the analysis must support, check data fitness (coverage, granularity, known quality issues), choose the method, then state the limitation on interpretation. Be ready to name bias and confounding explicitly and to distinguish description, prediction and causal inference.