DAMA CDMP Data Quality Specialist Exam Blueprint
Practical exam blueprint for DAMA CDMP Data Quality Specialist candidates preparing for the CDMP Quality exam.
How to Use This Exam Blueprint
Use this independent Exam Blueprint to organize final review for the DAMA International DAMA CDMP Data Quality Specialist exam, code CDMP Quality. It translates common data quality study areas into practical readiness tasks.
For each topic, mark your status:
- Ready: You can explain the concept, apply it in a scenario, and distinguish it from related concepts.
- Review: You recognize the idea but hesitate on application, terminology, or tradeoffs.
- Weak: You would struggle if the exam asked a scenario-based question.
The goal is not only to memorize definitions. For the CDMP Quality exam, be prepared to reason about data quality planning, assessment, measurement, rules, governance, remediation, monitoring, and organizational accountability.
Topic-Area Readiness Table
| Topic area | What to review | You are ready when you can… | Status |
|---|---|---|---|
| Data quality fundamentals | Purpose, business value, risk, fitness for use, quality expectations | Explain why quality is contextual and tied to business use, not just technical correctness | ☐ Ready ☐ Review ☐ Weak |
| Data quality dimensions | Accuracy, completeness, consistency, validity, timeliness, uniqueness, integrity, conformity, reasonableness | Match a defect or rule to the correct dimension and explain overlapping dimensions | ☐ Ready ☐ Review ☐ Weak |
| Data quality requirements | Business rules, critical data elements, thresholds, service expectations | Convert business expectations into measurable quality rules | ☐ Ready ☐ Review ☐ Weak |
| Data profiling | Column, cross-column, cross-table, pattern, frequency, outlier, duplication, relationship checks | Choose profiling techniques for unknown data, migration, integration, or monitoring scenarios | ☐ Ready ☐ Review ☐ Weak |
| Data quality rules | Rule definition, rule ownership, rule types, tolerances, exceptions | Write clear quality rules and distinguish hard validation rules from monitoring indicators | ☐ Ready ☐ Review ☐ Weak |
| Measurement and scoring | Metrics, defect rates, exception counts, quality scorecards, dashboards | Interpret quality metrics and avoid misleading aggregate scores | ☐ Ready ☐ Review ☐ Weak |
| Root cause analysis | Source defects, process failures, system constraints, unclear ownership, training gaps | Trace a defect from symptom to probable root cause and recommend durable correction | ☐ Ready ☐ Review ☐ Weak |
| Remediation and improvement | Cleansing, standardization, enrichment, deduplication, process change, prevention | Select corrective action based on defect type, business impact, and recurrence risk | ☐ Ready ☐ Review ☐ Weak |
| Data governance connection | Stewardship, accountability, policies, standards, issue escalation | Explain how governance sustains data quality beyond one-time cleanup | ☐ Ready ☐ Review ☐ Weak |
| Metadata and data lineage | Definitions, permissible values, lineage, transformations, business glossary | Use metadata and lineage to explain, test, and resolve quality problems | ☐ Ready ☐ Review ☐ Weak |
| Master and reference data quality | Identity resolution, survivorship, golden records, code sets, hierarchies | Identify quality risks in customer, product, location, account, and reference data | ☐ Ready ☐ Review ☐ Weak |
| Data integration quality | ETL/ELT controls, mappings, reconciliations, transformation checks | Recognize where integration pipelines introduce quality defects | ☐ Ready ☐ Review ☐ Weak |
| Data lifecycle controls | Creation, capture, update, storage, movement, usage, archival, deletion | Place quality controls at the right point in the data lifecycle | ☐ Ready ☐ Review ☐ Weak |
| Operational monitoring | Alerts, thresholds, service-level expectations, anomaly detection, issue logs | Design ongoing monitoring that detects deterioration early | ☐ Ready ☐ Review ☐ Weak |
| Data quality tools and automation | Profiling tools, rule engines, workflow, dashboards, observability, matching tools | Explain what tools can support, and what still requires governance and judgment | ☐ Ready ☐ Review ☐ Weak |
| Privacy, compliance, and risk | Sensitive data, regulatory exposure, access controls, auditability, ethical use | Connect quality defects to compliance, reporting, privacy, and decision risk | ☐ Ready ☐ Review ☐ Weak |
| Organizational roles | Data owner, steward, custodian, producer, consumer, governance council | Assign responsibility correctly in quality issue scenarios | ☐ Ready ☐ Review ☐ Weak |
| Communication and change | Stakeholder engagement, impact framing, quality reporting, adoption | Communicate quality findings in business terms, not only technical terms | ☐ Ready ☐ Review ☐ Weak |
Core Data Quality Concepts to Know Cold
Fitness for Use
Be able to explain that data quality depends on the purpose for which data is used.
| Scenario | Quality question to ask |
|---|---|
| Marketing campaign | Is the contact data current, consented, deduplicated, and usable for segmentation? |
| Financial reporting | Are values accurate, reconciled, complete, controlled, and traceable? |
| Operational fulfillment | Are addresses valid, complete, standardized, and available in time? |
| Analytics model | Is the data representative, consistent, timely, and free from harmful bias or leakage? |
| Regulatory submission | Is the data auditable, accurate, complete, and governed according to required controls? |
Checklist:
- I can explain why the same dataset may be acceptable for one use and unacceptable for another.
- I can distinguish business impact from technical defect count.
- I can connect data quality to trust, risk, efficiency, customer experience, and compliance.
- I can explain why quality must be measured against defined expectations.
Data Quality Dimensions
Know common dimensions well enough to classify examples.
| Dimension | What it asks | Example defect |
|---|---|---|
| Accuracy | Does the data correctly represent the real-world object or event? | Customer date of birth is wrong |
| Completeness | Is required data present? | Mandatory tax identifier is blank |
| Validity | Does the value conform to rules, format, type, or domain? | Country code is not in the approved list |
| Consistency | Do values agree across systems or fields? | Customer status differs between CRM and billing |
| Timeliness | Is data available and current enough for the use case? | Inventory updates arrive after orders are accepted |
| Uniqueness | Is the entity represented only once where expected? | Duplicate customer records exist |
| Integrity | Are relationships preserved and meaningful? | Order record references a missing customer |
| Conformity | Does data follow required standards? | Phone numbers use inconsistent formats |
| Reasonableness | Is the value plausible in context? | Employee age appears as 240 |
Readiness prompts:
- Can I classify one defect under multiple dimensions when appropriate?
- Can I explain why “valid” does not always mean “accurate”?
- Can I explain why “complete” does not always mean “useful”?
- Can I identify which dimension is most important for a stated business objective?
Data Quality Requirements and Rules
A common weak area is treating data quality as a vague aspiration instead of a requirement-driven discipline.
| Requirement component | Exam-ready understanding |
|---|---|
| Business need | The reason the data must meet a quality expectation |
| Data element | The field, record, entity, or relationship being assessed |
| Rule | The testable statement that defines expected quality |
| Threshold | The acceptable tolerance or target level |
| Owner | The accountable person or role for defining and resolving issues |
| Measurement method | How the rule is tested and reported |
| Exception handling | How failures are reviewed, prioritized, waived, corrected, or escalated |
Can You Turn Expectations Into Rules?
| Business expectation | Possible measurable rule |
|---|---|
| “Customer records should be usable for shipping.” | Shipping address must include required address components and pass address validation. |
| “Product reporting must be reliable.” | Product category must be populated from an approved reference list for active products. |
| “Invoices must reconcile.” | Invoice total must equal the sum of line amounts plus applicable charges and adjustments. |
| “Duplicate customers should be minimized.” | New customer records must be matched against existing records using approved identity criteria. |
| “Reports must use current data.” | Reporting dataset must be refreshed within the agreed business time window. |
Checklist:
- I can identify the difference between a business rule and a technical implementation rule.
- I can explain why every rule needs an owner and a rationale.
- I can describe how thresholds support prioritization.
- I can distinguish rule failure, acceptable exception, and rule design problem.
- I can explain why rules must be maintained as business processes change.
Data Profiling Readiness
Data profiling is a key skill area because it reveals the actual condition of data before rules, migration, cleansing, or integration decisions are made.
| Profiling activity | What it reveals | Scenario cue |
|---|---|---|
| Null or blank analysis | Missing required or expected values | Completeness concerns |
| Frequency distribution | Dominant, rare, invalid, or unexpected values | Domain and reference checks |
| Pattern analysis | Format variations and nonstandard values | Phone, email, postal code, identifier fields |
| Min/max and range checks | Outliers and impossible values | Numeric, date, and amount fields |
| Cross-field analysis | Conditional dependencies | End date before start date; status conflicts |
| Cross-table analysis | Referential integrity issues | Orphan records and missing relationships |
| Duplicate detection | Possible multiple records for the same entity | Customer, vendor, employee, product data |
| Trend analysis | Deterioration or process change | Ongoing monitoring and operational controls |
Can you do this?
- Given a new dataset, I can list first-pass profiling checks.
- I can distinguish profiling from formal rule monitoring.
- I can explain why profiling results require business interpretation.
- I can identify when a surprising value is an error versus a valid exception.
- I can connect profiling findings to remediation planning.
Measurement, Metrics, and Scorecards
Be ready to interpret data quality metrics without assuming that one score explains everything.
Common measurement concepts:
- Defect count: number of failed records, fields, or relationships.
- Defect rate: defects relative to the tested population.
- Rule pass rate: proportion of records that meet a rule.
- Exception rate: proportion of records requiring review or handling.
- Trend: improvement, deterioration, or stability over time.
- Business impact: cost, risk, delay, lost revenue, rework, or customer impact.
Useful formulas to recognize conceptually:
\[ \text{Completeness Rate} = \frac{\text{Number of populated required values}}{\text{Number of expected required values}} \times 100 \]\[ \text{Defect Rate} = \frac{\text{Number of failed checks}}{\text{Number of checks performed}} \times 100 \]\[ \text{Rule Pass Rate} = \frac{\text{Number of records passing the rule}}{\text{Number of records tested}} \times 100 \]Readiness checks:
- I can interpret a rate and explain the numerator and denominator.
- I can explain why counting defects alone can be misleading.
- I can identify when a metric should be segmented by source system, product, region, channel, or business process.
- I can distinguish leading indicators from lagging indicators.
- I can explain why scorecards should support decisions, not just reporting.
Root Cause and Remediation Checklist
The exam may test whether you can move from detecting defects to improving the process that creates or changes the data.
| Defect pattern | Likely root cause areas | Better long-term response |
|---|---|---|
| Many missing values at capture | Form design, unclear requirement, poor training, optional field misuse | Improve capture process, clarify requirement, validate at entry |
| Invalid reference codes | Poor reference data management, stale lookup tables, weak integration controls | Standardize reference data ownership and synchronization |
| Duplicate customer records | Weak matching, inconsistent identifiers, siloed onboarding | Introduce matching rules, stewardship review, identity resolution |
| Conflicting values across systems | No system of record, unclear ownership, integration timing | Define authoritative source and reconciliation rules |
| Sudden spike in defects | System change, upstream process change, failed interface | Investigate change history and monitor controls |
| Persistent manual corrections | Process design flaw, missing validation, unclear accountability | Fix upstream process, not only downstream cleansing |
| Inconsistent reporting values | Differing definitions, transformation logic, undocumented lineage | Align definitions, metadata, and report logic |
Remediation Options
| Option | Best used when… | Watch out for… |
|---|---|---|
| Data cleansing | Existing data must be corrected | Cleansing without prevention leads to recurring defects |
| Standardization | Values use inconsistent formats or representations | Standardization may not fix inaccurate source data |
| Enrichment | Missing or insufficient data can be improved from trusted sources | External sources need quality and usage evaluation |
| Deduplication | Multiple records represent the same entity | Matching rules can create false positives or false negatives |
| Validation at entry | Defects originate during capture | Overly strict validation can block legitimate exceptions |
| Process redesign | Defects are systemic and recurring | Requires stakeholder ownership and change management |
| Stewardship workflow | Human judgment is needed | Workflow must have clear authority and escalation |
| Source system correction | Root cause is upstream | Requires coordination with system owners and release processes |
Can you do this?
- I can recommend prevention when cleanup alone is insufficient.
- I can identify when a data defect is caused by a process defect.
- I can separate tactical correction from strategic improvement.
- I can explain when stewardship review is preferable to automatic correction.
- I can prioritize remediation based on business impact and recurrence.
Data Governance and Stewardship Connections
Data quality does not stand alone. It relies on governance, accountability, standards, and repeatable decisions.
| Role or function | Data quality responsibility to understand |
|---|---|
| Data owner | Accountable for data definition, usage expectations, and quality priorities |
| Data steward | Helps define rules, review issues, coordinate correction, and maintain meaning |
| Data custodian | Manages technical storage, movement, security, and operational controls |
| Data producer | Creates, captures, or supplies data |
| Data consumer | Uses data and may identify defects or fitness-for-use gaps |
| Governance body | Resolves conflicts, approves standards, prioritizes enterprise issues |
| Data quality analyst | Profiles, measures, reports, investigates, and supports improvement |
Checklist:
- I can assign accountability in a scenario without defaulting everything to IT.
- I can explain the difference between ownership and custodianship.
- I can describe how stewardship supports rule definition and issue resolution.
- I can explain why data quality decisions often require business authority.
- I can connect quality management to policies, standards, and governance forums.
Metadata, Lineage, and Definitions
Metadata is essential for understanding what data means, where it came from, how it changed, and whether it is fit for use.
| Metadata type | Why it matters for data quality |
|---|---|
| Business definition | Prevents inconsistent interpretation |
| Technical metadata | Identifies field type, length, source, and structure |
| Operational metadata | Shows load times, process status, job failures, and usage |
| Lineage | Traces data from source through transformations to consumption |
| Reference metadata | Defines allowed values and code meanings |
| Rule metadata | Documents quality checks, thresholds, ownership, and history |
Readiness prompts:
- Can I explain how poor definitions cause quality problems?
- Can I use lineage to locate where a defect may have been introduced?
- Can I distinguish a source data issue from a transformation issue?
- Can I explain why business glossaries and data catalogs support quality?
- Can I identify metadata needed to audit or reproduce a quality finding?
Master Data, Reference Data, and Identity Resolution
Expect data quality scenarios involving high-value shared data such as customer, product, employee, vendor, location, account, and reference code data.
| Area | Quality concerns |
|---|---|
| Master data | Duplicate entities, conflicting attributes, unclear golden record rules |
| Reference data | Invalid codes, inconsistent mappings, outdated value lists |
| Hierarchies | Incorrect parent-child relationships, missing levels, inconsistent rollups |
| Matching | False matches, missed matches, weak identifiers, inconsistent standardization |
| Survivorship | Conflicting source values and unclear preference rules |
| Synchronization | Systems using different versions of master or reference data |
Can you do this?
- I can explain why master data quality affects many downstream processes.
- I can distinguish reference data quality from master data quality.
- I can describe identity resolution at a conceptual level.
- I can explain survivorship rules and why they require business agreement.
- I can recognize risks in automated matching and merging.
Integration, Migration, and Data Pipeline Quality
Quality defects often appear during movement and transformation, not only at original capture.
| Scenario | Quality checks to consider |
|---|---|
| Data migration | Source profiling, mapping validation, reconciliation, completeness checks |
| ETL/ELT pipeline | Transformation rules, rejects, duplicate loads, referential integrity |
| API integration | Required fields, format validation, response handling, error logging |
| Data warehouse load | Source-to-target reconciliation, slowly changing data handling, business rules |
| Reporting layer | Definition alignment, aggregation logic, filter consistency, refresh status |
| Data lake or lakehouse | Metadata, schema evolution, data provenance, quality zones or controls |
| Streaming data | Late-arriving data, duplicates, ordering, timeliness, exception handling |
Checklist:
- I can identify quality controls before, during, and after data movement.
- I can explain why source-to-target mapping is a quality artifact.
- I can describe reconciliation checks in plain business terms.
- I can recognize when transformation logic creates quality risk.
- I can explain why pipeline monitoring should include data content checks, not only job success.
Operational Monitoring and Data Quality Controls
One-time assessment is not enough. Be ready to reason about continuous monitoring and operational controls.
| Control type | Purpose |
|---|---|
| Preventive control | Stops defects before they enter or move through the system |
| Detective control | Finds defects after they occur |
| Corrective control | Fixes defects or reduces their impact |
| Compensating control | Reduces risk when the ideal control is not feasible |
| Manual review | Applies human judgment for complex or ambiguous cases |
| Automated alert | Notifies teams when thresholds or patterns indicate quality problems |
Scenario cues:
- If defects are frequent and predictable, think preventive control.
- If defects are rare but high-impact, think detection plus escalation.
- If business rules require judgment, think stewardship workflow.
- If source correction is delayed, think compensating controls.
- If a metric changes suddenly, think trend monitoring and root cause analysis.
Checklist:
- I can choose the right control type for a defect pattern.
- I can explain why job success does not guarantee data quality.
- I can define alert thresholds without assuming every exception is critical.
- I can describe issue logging, assignment, escalation, and closure.
- I can explain how monitoring supports continuous improvement.
Data Quality Issue Management
Be prepared to handle an issue from discovery to closure.
flowchart TD
A[Detect quality issue] --> B[Confirm and classify defect]
B --> C[Assess business impact]
C --> D[Identify owner and root cause]
D --> E{Recurring or one-time?}
E -->|One-time| F[Correct affected data]
E -->|Recurring| G[Fix process, rule, source, or control]
F --> H[Validate correction]
G --> H
H --> I[Update metrics and documentation]
I --> J[Monitor for recurrence]
Issue management checklist:
- Is the issue clearly described?
- Are affected data elements, records, systems, and business processes identified?
- Is the business impact understood?
- Is the root cause known or actively being investigated?
- Is there an accountable owner?
- Are corrective and preventive actions separated?
- Are exceptions documented?
- Is closure based on verification, not assumption?
- Are rules, metadata, or procedures updated if needed?
Scenario and Decision-Point Checks
Use these prompts to test whether you can apply concepts under exam conditions.
| If the scenario says… | Think about… | Likely best answer direction |
|---|---|---|
| “The dashboard numbers are different from the operational system.” | Definitions, timing, transformation, aggregation, lineage | Investigate lineage and business definitions before assuming one system is wrong |
| “A field is populated but users still cannot rely on it.” | Accuracy, validity, timeliness, fitness for use | Completeness alone is not sufficient |
| “The team cleansed records last quarter and defects returned.” | Root cause, prevention, upstream process | Fix the process or control that creates defects |
| “Different business units use different customer definitions.” | Governance, glossary, master data, stewardship | Align definitions and ownership before measuring quality |
| “An automated matching process merged unrelated customers.” | False positives, matching thresholds, stewardship | Review matching logic and introduce human review for ambiguous matches |
| “A source system sends valid codes that reports do not recognize.” | Reference data synchronization, mappings, metadata | Align reference data and transformation mappings |
| “A quality score improved, but a critical regulatory field worsened.” | Aggregation risk, critical data elements | Do not let aggregate scores hide high-risk defects |
| “Users complain about stale data although loads complete successfully.” | Timeliness, refresh expectations, operational metadata | Monitor business freshness, not only technical job completion |
| “A new system migration shows many unexpected values.” | Profiling, mapping, data standards | Profile before migration and validate mappings |
| “No one agrees who should fix a recurring defect.” | Ownership, stewardship, governance escalation | Clarify accountability and escalation path |
Practical “Can You Do This?” Checklist
Before final review, you should be able to do the following without notes.
Explain and Classify
- Define data quality in terms of fitness for use.
- Explain the business value of data quality.
- Classify defects by quality dimension.
- Distinguish accuracy, validity, completeness, consistency, and timeliness.
- Explain why quality requirements must be tied to business processes.
- Describe how data quality supports trust, compliance, analytics, and operations.
Assess and Measure
- Choose profiling techniques for a new dataset.
- Interpret null, pattern, frequency, outlier, and duplicate analysis.
- Define a measurable data quality rule.
- Identify appropriate thresholds and exception handling.
- Interpret defect rates, pass rates, and trend reports.
- Explain limitations of aggregate quality scores.
Investigate and Improve
- Move from defect detection to root cause analysis.
- Recommend cleansing, standardization, enrichment, deduplication, or process change.
- Identify when upstream process correction is required.
- Explain corrective versus preventive action.
- Prioritize issues by business impact and risk.
- Verify that remediation actually resolved the problem.
Govern and Sustain
- Assign likely responsibilities to owners, stewards, custodians, producers, and consumers.
- Explain how governance supports data quality standards and issue escalation.
- Use metadata, definitions, and lineage in quality analysis.
- Connect data quality to master data and reference data management.
- Describe monitoring and controls for ongoing quality management.
- Communicate quality findings in business terms.
Common Weak Areas and Traps
| Trap | Why it is risky | How to avoid it |
|---|---|---|
| Treating data quality as only IT’s job | Business meaning and acceptance require business ownership | Look for owners, stewards, producers, and consumers |
| Equating validity with accuracy | A value can pass format checks and still be wrong | Ask whether data reflects reality |
| Focusing only on missing data | Populated data may still be invalid, stale, duplicated, or inconsistent | Review multiple dimensions |
| Cleansing without prevention | Defects will recur | Look for root cause and upstream controls |
| Measuring everything equally | Some data elements carry higher business risk | Identify critical data elements and impact |
| Using aggregate scores blindly | A high score can hide severe defects in important fields | Segment metrics and examine critical rules |
| Ignoring metadata | Quality issues often come from unclear definitions or transformations | Use glossary, lineage, and rule metadata |
| Over-automating matching | Automated matching can create damaging false merges | Use thresholds, review queues, and stewardship |
| Assuming source data is always right | Source systems can contain defects too | Validate against business rules and trusted references |
| Confusing monitoring with improvement | Dashboards do not fix defects by themselves | Connect metrics to action and accountability |
Artifact Checklist
Know the purpose of common data quality artifacts.
| Artifact | What it should contain |
|---|---|
| Data quality rule catalog | Rule name, data element, logic, owner, threshold, frequency, status |
| Data profile report | Findings on values, patterns, nulls, distributions, duplicates, relationships |
| Issue log | Defect description, impact, owner, priority, root cause, action, status |
| Scorecard or dashboard | Metrics, trends, thresholds, segments, rule results, business interpretation |
| Business glossary | Standard terms, definitions, synonyms, ownership, usage notes |
| Data lineage documentation | Source, transformations, movement, dependencies, consumption points |
| Remediation plan | Scope, actions, owners, timelines, verification, prevention steps |
| Reference data standard | Approved values, meanings, mappings, ownership, change process |
| Stewardship workflow | Intake, triage, assignment, escalation, decision, closure |
| Data quality policy or standard | Expectations, roles, measurement approach, escalation, compliance expectations |
Readiness prompt:
- If given an artifact name, I can explain why it exists, who uses it, and how it supports data quality management.
Final-Week Review Checklist
Use this as a practical closeout list before sitting for the DAMA International DAMA CDMP Data Quality Specialist exam, code CDMP Quality.
Content Review
- Review all major data quality dimensions and examples.
- Rehearse the difference between validity, accuracy, completeness, consistency, and timeliness.
- Review profiling methods and what each method reveals.
- Practice converting business expectations into measurable rules.
- Review metric interpretation, especially denominators and trends.
- Review root cause and remediation scenarios.
- Review governance roles and stewardship responsibilities.
- Review metadata, lineage, glossary, and rule catalog concepts.
- Review master data and reference data quality risks.
- Review monitoring, controls, scorecards, and issue workflows.
Scenario Practice
- For every practice question, identify the data quality dimension being tested.
- Ask whether the best response is detection, correction, prevention, or governance.
- Look for ownership and accountability clues.
- Watch for questions where a technical fix is not enough.
- Practice explaining why an answer is better than the distractors.
- Revisit missed questions by topic, not only by score.
Exam-Readiness Check
You are likely ready when you can:
- Explain concepts clearly without relying on memorized wording.
- Apply dimensions to realistic business and data scenarios.
- Choose appropriate profiling and measurement approaches.
- Identify root causes and durable remediation options.
- Connect data quality work to governance, metadata, and stewardship.
- Avoid common traps such as “clean it downstream” or “IT owns all data quality.”
- Complete timed practice with consistent accuracy and calm reasoning.
Practical Next Step
After reviewing this Exam Blueprint, take a focused practice set for the CDMP Quality exam and tag every missed question by topic area. Revisit the weakest two or three areas first, especially scenario judgment around dimensions, rules, governance roles, root cause analysis, and sustainable remediation.