DABCC common mistakes
DABCC · Understand the traps and how to avoid them.
Treating data governance as a documentation exercise: producing a policy binder and RACI chart but never linking them to an enforced decision right, so on scenario questions the candidate picks the option that 'creates a policy' rather than the option that assigns accountability for a specific data domain and defines escalation.
Governance study material is heavy on frameworks and org charts, and candidates memorize artifact names (council, steward, policy) without learning what each artifact actually decides. Scenario stems then feel like vocabulary matching rather than operating-model reasoning.
What to do instead
For every governance artifact, write one sentence answering 'what decision does this body make, and who is accountable if it is not made?' Practice converting stems into the question 'who owns this data and who resolves the conflict?' and eliminate any answer that only produces documentation with no owner or escalation path.
Confusing data stewardship with data ownership: assigning operational data-quality remediation to the owner, or strategic policy authority to the steward, and choosing answers that blur the two roles.
The two roles are often presented together in study guides, and candidates learn them as a single 'accountable for data' concept. Exam stems deliberately place the decision at one level (policy vs. day-to-day correction) to test the distinction.
What to do instead
Fix the split in memory: the owner is accountable for a domain and approves policy, standards, and access decisions; the steward executes standards, monitors quality, and resolves day-to-day issues within that domain. Read each stem for whether the action is a decision or an execution, then match the role.
Choosing normalization by reflex: answering 'normalize to third normal form' on modeling questions where the stated requirement is query performance, historical tracking, or reporting simplicity, instead of recognizing when denormalization, a star schema, or a slowly changing dimension is the right answer.
Normalization is taught first and tested most, so it becomes the default 'correct' modeling answer. Candidates under-weight the requirement sentence in the stem that signals read performance or change history.
What to do instead
Before answering any modeling item, underline the stated purpose (transactional integrity vs. analytical query vs. history retention). Map purpose to pattern: 3NF for operational integrity, star schema with conformed dimensions for analytics, SCD Type 2 for history. Reject any option that optimizes a goal the stem did not ask for.
Misclassifying slowly changing dimension types: using Type 1 when the requirement is to preserve prior values for audit, or Type 3 when the requirement is unlimited history, and picking an answer without checking whether history must be retained.
The type numbers are easy to memorize as labels but hard to apply. Candidates remember 'Type 2 keeps history' yet fail to scan the stem for the words that demand it, such as audit trail, point-in-time reporting, or as-of analysis.
What to do instead
Anchor each type to its physical effect: Type 1 overwrites (no history), Type 2 adds a new row with effective dates and a current flag (full history), Type 3 adds a prior-value column (one step back). For each stem, first decide whether history is required and how far back, then select the type whose physical effect matches.
Treating ETL and ELT as interchangeable: selecting a load-then-transform answer for a source system that cannot tolerate extraction load, or choosing extract-transform-load when the target platform is meant to absorb raw data and transform in place.
Both patterns are described with the same verbs, and candidates focus on the letters rather than on constraints like source impact, data volume, latency, and where transformation compute lives.
What to do instead
For every integration item, extract the constraints first: source system load tolerance, data volume, latency requirement, target platform capability, and whether raw data must be retained. ELT fits scalable target-side compute with raw retention; ETL fits constrained sources and pre-load cleansing. Choose the pattern the constraints permit, not the one that sounds modern.
Answering idempotency and restart questions with 'rerun the job' rather than specifying how duplicates are prevented, such as merge/upsert on a business key, watermarks, or transactional loads.
Candidates think of failure recovery as an operational scheduling concern rather than a design property. Stems that describe a failed batch and ask what to do next tempt the generic 'restart' answer.
What to do instead
Memorize that a safe rerun requires a deterministic key plus an idempotent write (upsert/merge) or a transactional boundary with checkpointing. When a stem mentions partial loads, late-arriving data, or reprocessing, eliminate any answer that appends rows without a deduplication key or restart watermark.
Reducing data quality to profiling and cleansing: proposing a one-time cleanup or a dashboard of defect counts when the stem asks for a durable control, and skipping the step of defining the quality dimension and the acceptable threshold before choosing a remedy.
Tools make profiling and cleansing the most visible part of data quality, so candidates equate the discipline with remediation. They then miss that the exam tests measurement against defined rules and root-cause prevention.
What to do instead
Answer in the order the discipline requires: define the dimension (completeness, accuracy, timeliness, consistency, uniqueness, validity), set a measurable rule and threshold, measure continuously, then fix the source process. Reject any option that is a one-time cleanup or a count with no rule, owner, or threshold attached.
Conflating masking, tokenization, and encryption: choosing encryption when the requirement is to keep the format usable for testing, or choosing masking when the requirement is reversible lookup for a downstream system.
All three are described as 'protecting sensitive data', and study material often lists them side by side. Candidates match on the word 'protect' instead of on reversibility, format preservation, and who holds the key.
What to do instead
Classify by property: masking is irreversible alteration (good for non-production and analytics), tokenization replaces a value with a surrogate mapped in a secured vault (reversible, format-flexible), encryption is reversible with a key and preserves format only if format-preserving encryption is specified. Read the stem for reversibility and format needs before selecting.
Ignoring role and purpose in access decisions: granting broad access based on job title alone, or answering data-privacy items with 'restrict access' when the stem calls for purpose limitation, minimization, or a lawful-basis check.
Candidates reduce security to authentication and authorization mechanics, so least-privilege and purpose-based access questions get answered with the bluntest control rather than the control the scenario requires.
What to do instead
For each stem, identify the subject, the purpose, the minimum data needed, and the retention limit. Then select the control that enforces that specific limit (role-based or attribute-based access, purpose binding, minimization, retention schedule). An answer that restricts more than the purpose requires is often as wrong as one that restricts too little.
Treating metadata and master data as the same discipline: answering a metadata question with a golden-record or deduplication remedy, or answering a master data question with a data catalog or lineage fix.
Both domains appear under one heading and share tooling vocabulary, so candidates memorize catalogs and golden records without separating 'data about data' from 'the shared reference entities of the business'.
What to do instead
Separate the two by question: metadata asks what data exists, where it came from, and how it moved (catalog, lineage, glossary, definitions); master data asks which version of a customer, product, or supplier is the trusted one (matching, survivorship, golden record, stewardship). Match the remedy to the noun in the stem.