DAMA CDMP Data Quality Specialist Cheat Sheet

Last revised: September 16, 2026

Cheat sheet: independent reference for DAMA International CDMP Quality exam prep: data quality dimensions, rules, profiling, remediation, governance, and metrics.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

Item	Reference
Vendor/provider	DAMA International
Official exam title	DAMA CDMP Data Quality Specialist
Official exam code	CDMP Quality
Page purpose	Independent Cheat Sheet for candidates reviewing data quality concepts, processes, roles, controls, and practical decision points

Data quality management is not just defect cleanup. For exam purposes, treat it as a governed management discipline that defines quality expectations, measures conformance, analyzes causes, remediates issues, and prevents recurrence.

High-yield framing:

Data quality = fitness for use by a defined business purpose, not abstract perfection.
Quality rules must trace to business rules, critical data, regulatory/reporting needs, operational risks, or customer outcomes.
Prevention is usually better than detection, but mature programs use both.
Root-cause remediation is stronger than downstream cleansing when the source or process can be changed.
Quality is contextual: the same data can be acceptable for trend analysis but unacceptable for billing, identity proofing, or regulatory reporting.

The exam is likely to reward candidates who can do more than define terms. You should be able to distinguish similar concepts, choose appropriate quality controls, connect data quality to governance and business value, and reason through realistic data issue scenarios.

Core Data Quality Management Lifecycle

Stage	What Happens	Exam-Relevant Outputs	Common Trap
Define expectations	Identify business needs, data consumers, critical data elements, quality dimensions, tolerances	Data quality requirements, business rules, acceptance criteria	Starting with tool scans before defining what “good” means
Profile and assess	Examine actual data values, patterns, relationships, duplicates, anomalies	Baseline quality report, defect categories, issue inventory	Treating profiling results as business rules without validation
Define rules and metrics	Convert requirements into measurable checks and thresholds	Data quality rules, scorecards, KPIs/KRIs, exception criteria	Measuring what is easy instead of what matters
Analyze root causes	Determine why defects occur	Root-cause findings, impact analysis, remediation options	Fixing symptoms in reports while source processes remain broken
Remediate	Correct data, process, application, integration, or governance gaps	Cleansed records, process changes, transformation fixes, steward actions	Assuming all remediation means overwriting data
Monitor and control	Continuously measure and escalate exceptions	Dashboards, alerts, SLA/OLA measures, issue workflow	One-time cleanup with no ongoing control
Improve	Refine standards, rules, ownership, training, and architecture	Prevention controls, updated policies, lessons learned	No feedback loop into governance or systems development

Notes and examples

Data quality lifecycle

Data quality management is continuous. It is not a single clean-up project.

    flowchart LR
	    A[Define business need] --> B[Identify critical data]
	    B --> C[Define quality requirements]
	    C --> D[Create rules and metrics]
	    D --> E[Profile and assess data]
	    E --> F[Prioritize issues]
	    F --> G[Remediate data and root causes]
	    G --> H[Implement controls]
	    H --> I[Monitor scorecards]
	    I --> C

Lifecycle exam logic

Step	Main purpose	Best evidence
Define business need	Clarify why quality matters	Business process, decision, risk, or outcome
Identify critical data	Focus effort where value or risk is highest	Critical data elements, key reports, regulatory or operational dependencies
Define requirements	Translate need into expectations	Business definitions, thresholds, rules
Profile data	Discover actual condition	Patterns, null rates, outliers, duplicates
Measure quality	Quantify performance against rules	Metrics, scorecards, trend lines
Analyze root cause	Find why defects occur	Process gaps, system constraints, unclear definitions
Remediate	Correct existing data and causes	Cleansing, process change, control improvement
Monitor	Sustain quality over time	Dashboards, alerts, ownership, escalation

Data quality and the data lifecycle

Quality can be affected at every stage.

Lifecycle stage	Quality concerns
Creation or capture	Input validation, user training, source controls
Acquisition	Supplier quality, external feed checks, contract expectations
Integration	Mapping, transformation, reconciliation, timing
Storage	Constraints, referential integrity, metadata
Usage	Fit for purpose, interpretation, access, reporting logic
Sharing	Standard definitions, formats, security, lineage
Archiving	Retention, historical integrity, accessibility
Disposal	Controlled deletion and auditability where relevant

High-yield idea

The earlier a defect is prevented, the less costly it usually is to fix. However, the best exam answer should still consider feasibility, business impact, and process design.

Data Quality Dimensions

Use dimensions as lenses for requirements and measurement. A good exam answer usually ties the dimension to a business outcome, testable rule, and acceptable threshold.

Dimension	Meaning	Example Check	Watch For
Accuracy	Data correctly represents the real-world object or event	Customer date of birth matches authoritative source	Accuracy often requires comparison to a trusted source, not just internal format validation
Completeness	Required data is present to the needed level	Mandatory tax identifier is populated for reportable customers	“Complete enough” depends on purpose; optional fields are not automatically defects
Validity	Data conforms to allowed format, type, range, or domain	Order status is one of approved status codes	Valid data can still be inaccurate
Consistency	Data values agree across systems, records, or business rules	Customer status in CRM matches billing eligibility	Consistency does not prove correctness if all systems copied the same wrong value
Timeliness	Data is available within the required time window	Inventory position refreshed before order promising	Timeliness includes latency, currency, and availability at point of use
Currency	Data reflects the most recent accepted state	Address updated after verified change of residence	Current data is not always the same as historically correct data
Uniqueness	Real-world entity or event is represented once where required	No duplicate active customer master records	Duplicates may be legitimate in transaction data but not in master data
Integrity	Relationships and dependencies are preserved	Invoice has a valid customer ID and valid order reference	Includes referential integrity and cross-field logic
Conformity	Data follows required standards and representations	Phone numbers stored in standard international format	Standardization supports matching, integration, and reporting
Precision	Level of detail is appropriate	Coordinates captured to required decimal precision	Excess precision can imply false confidence; insufficient precision may break use cases
Reasonableness	Value is plausible in business context	Employee age is within realistic employment range	Reasonableness checks detect anomalies but may require human review
Accessibility	Data can be obtained by authorized users/processes when needed	Analysts can access approved data product	Do not confuse accessibility with lack of security controls

Notes and examples

Data quality dimensions

Different frameworks use slightly different dimension names. Focus on the concept and the business question each dimension answers.

Dimension	Core question	Example	Trap
Accuracy	Does the data correctly represent the real-world object or event?	Customer date of birth matches verified source	Accuracy often requires comparison to an authoritative reference
Completeness	Is required data present?	Mandatory tax ID is populated	A field can be complete but wrong
Validity	Does the value conform to format, domain, or rule?	Country code is in approved ISO list	Valid does not always mean accurate
Consistency	Is the data the same across systems, records, or time?	Customer status is consistent in CRM and billing	Inconsistency may reveal timing, definition, or integration issues
Uniqueness	Is each real-world entity represented once?	No duplicate customer profiles	Duplicate detection often needs matching logic, not exact equality
Timeliness	Is the data available when needed?	Daily sales feed arrives before reporting cutoff	Timely data can still be inaccurate
Currency	Is the data up to date for its intended use?	Address reflects latest known residence	Currency depends on update expectations
Conformity	Does the data follow required standards or patterns?	Phone numbers use standard format	Conforming values may still be semantically wrong
Integrity	Are relationships and dependencies preserved?	Every order has a valid customer ID	Referential integrity is narrower than overall data integrity
Reasonableness	Does the value make sense in context?	Employee age is plausible	Requires business context and thresholds
Precision	Is the level of detail appropriate?	Coordinates recorded to required decimal places	More precision is not always better
Accessibility	Can authorized users obtain data when needed?	Analysts can access approved data set	Accessibility must be balanced with security and privacy controls

Data quality dimensions by example

Use this table for rapid classification practice.

Example defect	Most likely dimension
Required customer email is blank	Completeness
Email is `abc.example.com`	Validity or conformity
Email belongs to someone else	Accuracy
Customer has three active profiles	Uniqueness
Customer ID on order does not exist	Integrity
System A shows Gold tier, System B shows Silver tier	Consistency
Daily feed arrives after reporting deadline	Timeliness
Address has not been updated after verified move	Currency
Date of birth is 01/01/1800	Reasonableness or validity, depending on rule
Amount is rounded to whole dollars when cents are required	Precision
Report users cannot access approved data in time	Accessibility

Business Rules vs Data Quality Rules

Concept	Definition	Example	Exam Distinction
Business rule	Policy or constraint about how the business operates	A policy must have one active policyholder	Expressed in business language; may exist without implementation
Data rule	Implemented rule about acceptable data representation	`policyholder_id` must not be null for active policies	Converts business expectation into measurable data condition
Data quality rule	Test used to assess data against a dimension and threshold	Active policies with null policyholder ID must be below approved tolerance	Includes metric, scope, owner, severity, and action
Validation rule	Control that prevents or flags bad input	UI rejects invalid product code	Usually preventive and embedded in system or workflow
Transformation rule	Logic used to derive or move data	Map legacy customer type `R` to retail	Can create quality issues if undocumented or inconsistent
Reconciliation rule	Check that data agrees across processes or systems	Sum of source transactions equals ledger load total	Often used in ETL, finance, and regulatory reporting

Anatomy of a Strong Data Quality Rule

Component	What to Specify	Example
Business purpose	Why the rule matters	Required for regulatory customer identification
Data scope	Systems, tables, entities, records, period	Active customers in onboarding platform
Data element or relationship	Field, composite field, reference, hierarchy	`customer_id`, `country_code`, parent account
Dimension	Quality aspect being tested	Completeness, validity, uniqueness
Rule logic	Exact condition to evaluate	`country_code` must exist in approved reference list
Threshold/tolerance	Acceptable level or boundary	Zero tolerance for blocked onboarding; limited tolerance for legacy archive
Severity	Business risk level	Critical, high, medium, low
Owner/steward	Accountable party	Customer data owner, data steward, system owner
Exception handling	Review, correction, waiver, escalation	Send exceptions to steward queue within agreed workflow
Measurement frequency	Batch, real time, daily, monthly, event-driven	Daily load check; real-time transaction validation
Evidence	Report, log, control result, audit trail	Scorecard and issue record

Profiling and Assessment Techniques

Technique	Purpose	Typical Findings	Best Used When
Column profiling	Examine nulls, min/max, patterns, lengths, data types	Unexpected null rates, invalid lengths, outliers	First-pass understanding of unfamiliar data
Domain/value frequency	Count distinct values and distributions	Invalid codes, rare values, skewed values	Validity and reference data checks
Pattern analysis	Identify structural patterns	Mixed date formats, inconsistent identifiers	Standardization and parsing work
Cross-field analysis	Compare related fields in same record	End date before start date	Integrity and reasonableness checks
Cross-system comparison	Compare values between systems	CRM and billing customer address mismatch	Consistency assessment
Referential integrity check	Verify valid parent/child relationships	Orphan invoice without valid customer	Relational and integration quality
Duplicate detection	Find likely duplicate entities or events	Same person under multiple customer IDs	Master data and identity resolution
Time-series monitoring	Track metrics over time	Sudden spike in missing values after release	Operational monitoring and regression detection
Reconciliation	Compare totals/counts across processing steps	Source count differs from warehouse load count	ETL, financial, regulatory, and audit-sensitive flows
Sampling and review	Human review of selected records	False positives, ambiguous cases	Accuracy checks where no fully automated source exists

Key Metrics and Formulas

Use metrics to make quality visible, comparable, and actionable. Avoid presenting a single score without showing what it measures.

\[ \text{Completeness \%} = \frac{\text{Required values populated}}{\text{Required values expected}} \times 100 \]\[ \text{Defect rate} = \frac{\text{Records failing rule}}{\text{Records evaluated}} \times 100 \]\[ \text{Validity \%} = \frac{\text{Values conforming to rule}}{\text{Values tested}} \times 100 \]\[ \text{Weighted data quality score} = \sum_{i=1}^{n}(\text{Dimension score}_i \times \text{Weight}_i) \]

Metric	What It Shows	Good Use	Caution
Rule pass rate	Share of records passing a specific check	Operational control monitoring	High pass rate can hide severe defects in critical records
Defect count	Number of failing records	Work queue sizing	Counts alone ignore population size
Defect rate	Defects relative to tested population	Comparing systems or periods	Requires stable denominator and rule definition
Completeness rate	Presence of required values	Mandatory attribute checks	Null is not the only form of missing data
Duplicate rate	Likely duplicate records per population	Master data improvement	Match logic affects results significantly
Timeliness lag	Delay between event and data availability	Data pipeline and reporting SLAs	Some latency may be acceptable by use case
Reconciliation variance	Difference between source and target totals	ETL and financial controls	Must account for legitimate filters and transformations
Issue aging	Time unresolved quality issues remain open	Stewardship and remediation performance	Aging without severity can mislead
Recurrence rate	Reappearance of previously fixed issue	Root-cause effectiveness	Requires issue classification discipline

Critical Data Elements and Prioritization

Not all data deserves the same level of control. Prioritize quality work by business impact.

Priority Factor	Questions to Ask	Higher Priority When
Business criticality	Does the data drive revenue, operations, customer service, reporting, risk, or compliance?	It affects key decisions, obligations, or customer outcomes
Usage frequency	How often and by whom is it used?	Many processes or high-value consumers depend on it
Risk exposure	What happens if it is wrong, late, missing, or duplicated?	Financial loss, regulatory exposure, safety risk, fraud, reputational impact
Propagation	How many downstream systems consume it?	Defects spread broadly through integration and analytics
Correction cost	How hard is it to fix after capture?	Late correction is expensive or impossible
Authoritativeness	Is there a trusted source of truth?	Multiple conflicting sources exist
Change volatility	How often does it change?	High volatility requires stronger monitoring
Data lifecycle stage	Is it created, transformed, archived, or reported?	Quality needs differ across lifecycle stages

Notes and examples

Critical data elements

A critical data element is important enough that poor quality can materially affect business outcomes, risk, reporting, or operations.

How to identify critical data

Look for data used in:

Key business decisions.
Executive or regulatory reporting.
Customer-facing processes.
Financial calculations.
Risk models or controls.
Operational workflows.
Master data relationships.
Integration keys.
Contractual or service obligations.
High-volume automation.

Trap

A field is not critical merely because it exists in a database. Criticality comes from business use and impact.

Remediation Decision Table

Situation	Prefer This Response	Why
Bad data originates at manual entry	Add input validation, training, workflow controls, or required fields	Prevents recurrence at capture
Source system allows invalid combinations	Update application rules or reference controls	Stronger than downstream correction
Integration mapping is wrong	Fix transformation logic and reload if appropriate	Corrects systemic propagation
Data is valid but inconsistent across systems	Define authoritative source, synchronization rules, and stewardship workflow	Resolves ownership and lineage conflict
Duplicate master records exist	Standardize, match, merge/link, apply survivorship, prevent future duplicates	Treats entity resolution as process and governance issue
Legacy data has known defects but low operational value	Document limitations, isolate, apply risk-based cleanup	Avoids wasteful perfectionism
Data must be corrected but source cannot change immediately	Apply controlled remediation with audit trail and exception process	Balances business need with traceability
Defect is caused by unclear business definition	Clarify glossary, policy, ownership, and rule semantics	Prevents teams from measuring different things
External data is poor	Validate provider quality, contract expectations, monitoring, alternative sources	Quality responsibility must be managed even if data is acquired
False positives overwhelm stewards	Tune rules, thresholds, matching weights, and severity logic	Improves trust and operational usability

Prevention, Detection, and Correction Controls

Control Type	Examples	Strength	Limitation
Preventive	Required fields, domain validation, referential constraints, workflow approvals, controlled reference data	Stops defects before creation	Can slow processes or reject unusual valid cases
Detective	Profiling, monitoring dashboards, reconciliation, anomaly detection, audit reports	Finds defects after creation	Requires remediation workflow
Corrective	Cleansing, standardization, deduplication, enrichment, manual correction	Improves existing data	Can mask source problems if used alone
Compensating	Downstream reasonableness checks, exception reporting, disclosure of limitations	Reduces risk when primary control is unavailable	Should not become permanent substitute for root-cause fix
Governance control	Ownership, standards, issue escalation, policy, stewardship	Creates accountability	Ineffective without measurement and enforcement
Technical control	Constraints, validation services, metadata-driven checks, pipeline tests	Automates repeatability	Needs business-approved rules

Notes and examples

Prevention, detection, and correction controls

Data quality controls can be placed at different points in the lifecycle. Prevention is usually preferable when feasible, but detection and correction remain necessary.

Control type	Purpose	Example	Best used when
Preventive	Stop defect creation	Required field, dropdown list, referential constraint	Data can be validated at entry or integration
Detective	Identify defects after creation	Profiling rule, reconciliation, exception report	Defects may occur despite controls
Corrective	Repair defects	Cleansing, standardization, deduplication	Existing data must be fixed
Compensating	Reduce risk when ideal control is not available	Manual review of high-risk records	System change is not immediate
Monitoring	Track quality over time	Dashboard, scorecard, trend alert	Ongoing assurance is needed

Control selection rule

Prefer the control closest to the source of defect creation if it is practical, business-aligned, and does not create unacceptable process friction.

Root-Cause Analysis Reference

Root-Cause Category	Symptoms	Example Corrective Action
Process design	Missing steps, unclear handoffs, rekeying	Redesign workflow, remove duplicate capture, assign approval point
People/training	Inconsistent entry, misunderstanding definitions	Training, job aids, clearer business glossary
Application design	No validation, poorly designed screens, optional critical fields	UI/API validation, required fields, controlled values
Integration/transformation	Mapping errors, truncation, code conversion defects	Correct mappings, lineage review, pipeline tests
Metadata/definition	Teams use different meanings for same field	Business glossary, semantic standards, data contracts
Reference data	Outdated or inconsistent code sets	Reference data governance, controlled updates
Master data	Duplicate entities, conflicting golden records	MDM process, matching rules, survivorship policy
Policy/governance	No owner, no escalation, unclear accountability	Data ownership model, stewardship process
External provider	Late, incomplete, or inconsistent third-party feeds	Provider quality monitoring, acceptance criteria
Architecture	Multiple uncontrolled copies, batch latency, no lineage	Authoritative sources, integration standards, metadata management

Notes and examples

High-yield distinction: root cause is why the defect is produced; impact is what the defect causes; symptom is what the measurement detected.

Root cause analysis

Root cause analysis separates symptoms from causes.

Common root causes

Root cause category	Examples
Process design	Data captured too late, no verification step, unclear handoff
System design	Missing validation, weak constraints, poor interface design
Integration	Transformation error, mapping mismatch, timing conflict
Metadata	Ambiguous definition, inconsistent code meanings
Governance	No owner, no standard, unresolved policy conflict
Training	Users misunderstand required values or procedures
Incentives	Speed rewarded over accuracy, no accountability for defects
Source quality	External feed or upstream system sends poor data
Change management	New field, product, or process not reflected in rules
Manual workarounds	Spreadsheet edits, rekeying, informal corrections

Root cause vs. remediation

Situation	Symptom fix	Root cause fix
Null values in required field	Populate missing values	Make field mandatory at capture and train users
Invalid product codes	Replace invalid codes	Align source system dropdown with approved reference data
Duplicate customer records	Merge duplicates	Improve matching at onboarding and stewardship review
Late data feed	Reload file manually	Define SLA, monitoring, alerts, and escalation
Conflicting definitions	Reconcile report values	Approve business glossary definition and align transformations

Matching, Deduplication, and Survivorship

Term	Meaning	Exam Tip
Parsing	Breaking a value into components	Needed before standardizing names, addresses, identifiers
Standardization	Converting values to common formats	Improves matching and conformity
Normalization	Reducing representational variation	Example: casing, punctuation, abbreviations
Exact match	Records match only when values are identical	High precision, low tolerance for variation
Deterministic match	Rule-based matching using defined conditions	Transparent and explainable
Probabilistic match	Uses likelihood/weights across attributes	Handles variation but requires tuning and review
Fuzzy match	Finds similar but not identical values	Useful for names/addresses; can create false positives
Blocking	Reduces match comparisons by grouping candidates	Improves performance but can miss cross-block matches
Survivorship	Rules for choosing retained values after merge	Must align with trust, recency, source priority, or business policy
Golden record	Consolidated trusted representation of an entity	Requires governance, not only tooling
Link vs merge	Link keeps records separate but associated; merge consolidates	Use merge carefully when identity confidence is high

Notes and examples

Matching, deduplication, and survivorship

Duplicate management is a common scenario area because it requires judgment.

Concept	Meaning
Exact matching	Records match on identical values
Fuzzy matching	Records are similar enough to be potential matches
Deterministic matching	Rules-based matching using defined fields
Probabilistic matching	Statistical likelihood that records refer to same entity
Match threshold	Score above which records are considered matches
Clerical review	Human review of uncertain matches
Survivorship rule	Rule for choosing which value remains after merge
Golden record	Consolidated representation assembled from trusted sources

Survivorship examples

Rule	Example
Most recent	Use latest address update
Most trusted source	Use verified government ID source
Most complete	Keep record with most populated fields
Source priority	CRM overrides web form for customer name
Manual stewardship	Steward decides for ambiguous high-impact records

Trap

A “golden record” is not automatically true or permanent. It depends on matching logic, source trust, governance decisions, and ongoing updates.

Data Cleansing and Enrichment

Technique	Purpose	Good Candidate	Risk
Standardization	Make formats consistent	Addresses, phone numbers, product codes	May alter meaning if standards are wrong
Correction	Replace wrong values with known correct values	Verified spelling, code correction	Requires trusted basis and auditability
Imputation	Fill missing values using inference	Analytical datasets with known assumptions	Can introduce bias; should be flagged
Enrichment	Add data from internal/external source	Geocoding, industry codes, demographics	External source quality and rights must be managed
Deduplication	Remove or consolidate redundant records	Customer, supplier, product masters	Incorrect merges are costly
Reference validation	Compare to controlled list	Country, currency, product category	Reference list must be governed
Exception handling	Route unresolved defects for review	Ambiguous duplicates, unusual transactions	Backlogs reduce effectiveness

Exam trap: cleansing is not automatically improvement if it changes data without lineage, approval, audit trail, or business justification.

Notes and examples

Data cleansing and standardization

Cleansing improves existing data, but it should not be confused with sustainable quality management.

Cleansing techniques

Technique	Use
Parsing	Split values into components, such as full name into first and last name
Standardization	Convert values to consistent format
Normalization	Reduce variation in representation
Validation	Confirm values meet rules
Enrichment	Add missing or improved values from trusted sources
Matching	Identify records referring to same entity
Deduplication	Remove or merge duplicate records
Survivorship	Choose best value among duplicates
Correction	Replace wrong values with verified values

Cleansing traps

Cleansing without business rules can corrupt data.
Deduplication can incorrectly merge different real-world entities.
Enrichment may introduce licensing, trust, lineage, or currency issues.
Automated correction should be monitored, especially for high-risk data.
Cleansing projects should feed lessons back into process and control improvement.

Metadata, Lineage, and Data Quality

Metadata Type	Data Quality Use
Business metadata	Defines meaning, ownership, criticality, approved business terms
Technical metadata	Identifies schemas, fields, data types, constraints, transformations
Operational metadata	Captures job runs, load times, failures, volumes, latency
Lineage metadata	Shows where data came from, how it changed, and where it goes
Quality metadata	Stores rules, scores, defects, thresholds, exceptions, issue status
Reference metadata	Describes allowed code sets and valid value domains

Why it matters:

Lineage supports impact analysis and root-cause tracing.
Business definitions reduce inconsistent interpretation.
Technical metadata helps automate profiling and controls.
Operational metadata helps detect pipeline and timeliness issues.
Quality metadata provides evidence of monitoring and improvement.

Data Quality and Governance Roles

Role	Primary Responsibilities	Not the Same As
Data owner	Accountable for data within a business domain; approves rules, priorities, and risk decisions	Usually not the person doing every correction
Data steward	Manages definitions, rules, issues, quality monitoring, and coordination	Not merely an IT support role
Data custodian	Operates technical environment, storage, access, backups, platforms	Does not define business meaning alone
Data consumer	Uses data and identifies fitness-for-use needs	Not passive; should report quality issues
Data producer	Creates or captures data	Must understand downstream quality impacts
Data quality analyst	Profiles data, defines measurements, analyzes defects, supports remediation	Does not own all business decisions
Data governance council	Resolves cross-domain standards, priorities, and escalations	Should not become a bottleneck for every minor issue
System owner/product owner	Ensures application/process changes support data quality requirements	Needs alignment with data ownership
Data architect	Designs structures, integration, lineage, and standards support	Architecture alone cannot create quality without process controls

Data Quality Issue Management

Step	Key Questions	Output
Log issue	What rule failed? Where? How many records? Who detected it?	Issue record with evidence
Classify	Which domain, dimension, severity, source, and impact?	Prioritized category
Assign owner	Who can decide and who can fix?	Accountable owner and responsible resolver
Analyze	What is root cause? Is it isolated or systemic?	Root-cause assessment
Decide treatment	Correct, accept, defer, monitor, redesign, or escalate?	Remediation plan
Implement	What data/process/system change is required?	Controlled fix
Validate	Did the fix resolve the defect without side effects?	Test and quality result
Close or monitor	Has recurrence risk been addressed?	Closure evidence and monitoring rule

Common severity criteria:

Critical reporting or legal exposure
Financial statement or billing impact
Customer harm or operational stoppage
Security, privacy, or access-control implications
Number and importance of affected records
Time sensitivity and downstream propagation

Notes and examples

Issue management

Data quality issues should be logged, triaged, assigned, investigated, resolved, and monitored for recurrence.

Issue management workflow

Detect issue through profiling, control failure, user report, audit, or monitoring.
Log the issue with evidence, affected data, and business impact.
Classify by dimension, severity, domain, and affected process.
Assign ownership to appropriate business and technical roles.
Analyze root cause rather than only correcting visible records.
Remediate data where appropriate.
Fix process or control to prevent recurrence.
Validate resolution with retesting.
Monitor recurrence through ongoing metrics.

Severity decision factors

Factor	Higher severity when…
Business impact	Decisions, revenue, operations, or customers are affected
Compliance or risk exposure	Required reporting or risk controls depend on the data
Scope	Many records, systems, or processes are affected
Criticality	Critical data elements are involved
Recurrence	Issue repeats after prior fixes
Detectability	Issue is hard to detect before impact
Timeliness	Issue affects urgent reporting or operations

Data Quality in Data Warehousing, BI, and Analytics

Area	Quality Concern	Practical Control
Source extraction	Missing records, late files, changed schemas	Source counts, schema checks, arrival monitoring
Staging	Type conversion, truncation, invalid encodings	Profiling and reject/error tables
Transformation	Incorrect mapping, business logic drift	Mapping review, test cases, lineage documentation
Loading	Duplicate loads, partial loads, referential failures	Reconciliation and restart controls
Reporting	Misleading metrics, inconsistent definitions	Certified metrics and semantic layer governance
Analytics/AI	Biased, stale, incomplete, mislabeled training data	Data suitability checks, drift monitoring, documentation
Historical data	Slowly changing meaning, late arriving facts	Effective dating, versioned reference data
Self-service BI	Uncontrolled copies and inconsistent calculations	Governed data products, catalogs, quality indicators

High-yield distinction: analytics data can be technically valid but analytically unsuitable because of bias, missing populations, stale features, or unclear definitions.

Data Quality in Master and Reference Data

Data Type	Quality Focus	Typical Controls
Master data	Core entities such as customer, product, supplier, employee	Identity resolution, uniqueness, survivorship, stewardship
Reference data	Controlled values such as codes, statuses, country lists	Change governance, valid value lists, versioning, synchronization
Transaction data	Business events such as orders, payments, claims	Completeness, timeliness, reconciliation, auditability
Metadata	Definitions and descriptions of data	Glossary governance, lineage, ownership
Analytical data	Aggregated, derived, modeled, or feature-engineered data	Definition consistency, reproducibility, lineage, suitability

Exam trap: master data quality often requires organizational agreement on identity and ownership, not only duplicate detection.

Notes and examples

Reference data, master data, and data quality

Data quality issues often arise from poor control of reference or master data.

Data type	Quality relevance
Reference data	Provides valid code sets and classifications
Master data	Represents key business entities such as customer, product, supplier, or employee
Transaction data	Records business events and depends on accurate master/reference data
Metadata	Defines meaning, rules, lineage, and context

Examples

Issue	Likely related area
Invalid country code	Reference data management
Same customer appears three times	Master data management
Revenue report uses unclear “active customer” definition	Metadata and governance
Orders reference missing product IDs	Referential integrity and master data
System A and System B use different status codes	Reference data alignment and integration

Practical SQL Patterns for Data Quality Checks

Use SQL-like checks to understand measurement logic. Syntax varies by platform.

Null or Missing Required Values

SELECT
  COUNT(*) AS total_rows,
  SUM(CASE WHEN customer_id IS NULL THEN 1 ELSE 0 END) AS missing_customer_id
FROM orders;

Invalid Domain Values

SELECT order_status, COUNT(*) AS row_count
FROM orders
WHERE order_status NOT IN ('NEW', 'APPROVED', 'SHIPPED', 'CANCELLED')
GROUP BY order_status;

Duplicate Candidate Keys

SELECT email_address, COUNT(*) AS record_count
FROM customer
WHERE email_address IS NOT NULL
GROUP BY email_address
HAVING COUNT(*) > 1;

Referential Integrity Exceptions

SELECT o.order_id, o.customer_id
FROM orders o
LEFT JOIN customer c
  ON o.customer_id = c.customer_id
WHERE c.customer_id IS NULL;

Cross-Field Logic

SELECT contract_id, start_date, end_date
FROM contract
WHERE end_date < start_date;

Source-to-Target Reconciliation

SELECT 'source' AS system_name, COUNT(*) AS row_count FROM source_orders
UNION ALL
SELECT 'target' AS system_name, COUNT(*) AS row_count FROM warehouse_orders;

Decision Matrix: Where Should a Quality Rule Run?

Rule Location	Use When	Advantages	Risks
User interface	Human entry can be corrected immediately	Prevents defects early	May not cover APIs or batch loads
API/service layer	Multiple channels create/update data	Centralized validation	Requires service adoption
Database constraint	Rule is stable and structural	Strong enforcement	Less flexible for contextual rules
ETL/ELT pipeline	Data moves between systems	Detects integration and transformation defects	Can become downstream patching
Data quality platform	Cross-system monitoring and scorecards needed	Reusable profiling, dashboards, stewardship workflow	Tool outputs still require governance
Reporting/semantic layer	Rule is presentation-specific	Protects metric interpretation	Too late for operational correction
Steward workflow	Judgment or business approval is needed	Handles ambiguous cases	Manual backlog risk

Data Quality Scorecards and Dashboards

Element	Include	Avoid
Business context	Domain, data product, consumer, purpose	Generic technical score with no owner
Dimensions	Completeness, validity, timeliness, etc. selected by use case	Assuming every dimension has equal value
Rule-level results	Pass/fail counts, defect rate, trend	Only aggregate score with no drill-down
Thresholds	Target, tolerance, breach level	Hidden or arbitrary thresholds
Severity	Business impact classification	Treating all defects equally
Trends	Change over time, release-related spikes	One-time snapshots only
Issue workflow	Open defects, aging, owner, status	Dashboard with no action path
Lineage	Source and downstream impact	No way to trace affected reports/processes
Notes/limitations	Known exclusions, sampling assumptions	False precision

Notes and examples

Data quality scorecards and dashboards

Scorecards communicate quality status. They should support decisions, not just display numbers.

Scorecard element	Why it matters
Data domain or data set	Shows scope
Critical data element	Focuses attention on important data
Dimension	Clarifies type of quality issue
Rule tested	Makes measurement repeatable
Threshold	Defines acceptable performance
Current score	Shows present condition
Trend	Shows improvement or deterioration
Severity	Helps prioritize response
Owner	Enables accountability
Action plan	Connects measurement to remediation

Scorecard trap

A dashboard with many metrics but no ownership, thresholds, or action process is weak data quality management. For exam scenarios, the stronger answer usually links metrics to accountability and continuous improvement.

High-Yield Distinctions

Distinction	Know This
Accuracy vs validity	Valid means conforms to rules; accurate means correctly represents reality
Completeness vs optionality	Missing required data is a defect; missing optional data may be acceptable
Timeliness vs currency	Timeliness is availability within needed time; currency is whether value reflects current state
Consistency vs correctness	Consistent values can all be wrong; inconsistency requires authoritative resolution
Detection vs prevention	Detection finds defects; prevention reduces creation of defects
Cleansing vs remediation	Cleansing fixes data values; remediation may fix process, system, governance, or architecture
Data owner vs data steward	Owner is accountable for decisions; steward manages and coordinates quality activities
Business rule vs technical constraint	Business rule expresses policy; technical constraint implements or tests it
Profiling vs monitoring	Profiling explores and baselines; monitoring checks defined rules over time
DQ metric vs KPI	DQ metric measures data conformance; KPI measures business performance
Root cause vs symptom	Failed rule is symptom; underlying process/system/design issue is root cause
Golden record vs source of record	Golden record is consolidated trusted view; source of record is authoritative for specified data creation/maintenance

Common Exam Traps

Assuming data quality is owned only by IT.
Treating profiling tools as a substitute for business definitions.
Equating format validity with accuracy.
Choosing cleanup when source prevention is feasible.
Ignoring downstream consumers when defining quality requirements.
Applying one universal quality threshold to all data.
Measuring too many low-value rules while ignoring critical data elements.
Forgetting that data quality requirements can conflict across use cases.
Assuming duplicates are always defects without considering business context.
Confusing data governance, data management, and data quality management.
Ignoring metadata and lineage in impact analysis.
Failing to distinguish accepted risk/waiver from unresolved defect.
Closing issues after data correction without monitoring recurrence.
Overlooking reference data as a major cause of validity and consistency problems.
Assuming a dashboard improves quality without ownership, workflow, and remediation.

Notes and examples

Trap 1: choosing cleansing when governance is needed

If the issue is recurring, cross-system, or definition-based, cleansing alone is insufficient.

Trap 2: confusing technical validity with business correctness

A value can pass a system edit and still be wrong for the business.

Trap 3: ignoring root cause

Sustainable data quality requires preventing recurrence, not only fixing defective records.

Trap 4: treating all data equally

Focus on critical data elements and business impact.

Trap 5: assuming IT owns data quality

IT implements many controls, but business ownership and stewardship are central.

Trap 6: measuring without acting

Metrics are useful only when connected to thresholds, accountability, and remediation.

Trap 7: over-validating at the wrong point

Too many entry controls can slow business processes or create workarounds. Place controls thoughtfully.

Trap 8: using dimensions mechanically

Some issues can involve multiple dimensions. Choose the dimension most directly tested by the scenario.

Trap 9: trusting external data blindly

Third-party or external data requires assessment, contracts or expectations, monitoring, and lineage.

Trap 10: overlooking metadata

Definitions, lineage, and rules are often the missing link in data quality scenarios.

Cheat Sheet Checklist

Before exam day, be able to answer these quickly:

Can you define data quality as fitness for use and explain why context matters?
Can you distinguish accuracy, validity, completeness, consistency, timeliness, uniqueness, and integrity?
Can you convert a business rule into a measurable data quality rule?
Can you identify critical data elements and prioritize quality work by business impact?
Can you choose between profiling, monitoring, reconciliation, cleansing, and root-cause remediation?
Can you explain why prevention controls are preferred when defects can be stopped at source?
Can you map issues to owners, stewards, custodians, and governance escalation paths?
Can you explain how metadata and lineage support quality assessment and remediation?
Can you identify appropriate metrics, thresholds, and scorecard content?
Can you recognize when data is valid but inaccurate, consistent but wrong, or complete but not fit for use?

High-yield Data Quality mindset

Data quality is not simply “clean data.” It is the degree to which data is fit for its intended business purpose. The same data may be acceptable for one use case and unacceptable for another.

Core decision rule

Ask three questions first:

What business process or decision uses the data?
What quality requirement makes that use possible?
Where in the data lifecycle should the issue be prevented, detected, corrected, or monitored?

If a question asks for the “best” answer, prefer the option that connects data quality to business use, measurable rules, ownership, and sustainable controls rather than one-time cleansing.

Notes and examples

Fast decision rules

Use these when answering scenario questions quickly.

If the question emphasizes…	Think first about…
Incorrect real-world value	Accuracy
Missing required value	Completeness
Wrong format or invalid code	Validity or conformity
Same entity appears multiple times	Uniqueness and matching
Broken parent-child relationship	Integrity
Different values across systems	Consistency
Late arrival	Timeliness
Outdated value	Currency
Conflicting report meanings	Metadata and governance
Repeated issue after fixes	Root cause and preventive controls
Unclear responsibility	Data ownership and stewardship
Too many defects in source data	Upstream controls
Data migration failure	Profiling, mapping, reconciliation, cleansing
Poor dashboard trust	Definitions, lineage, controls, and metrics
Question asks “best long-term solution”	Governance, root cause, prevention, monitoring

Essential vocabulary

Term	What it means	Common exam trap
Data quality	Fitness of data for intended use	Treating quality as absolute instead of contextual
Data quality dimension	A category used to evaluate data quality	Assuming every dimension applies equally to every data set
Data quality rule	A testable statement of expected data condition	Confusing a business rule with its technical implementation
Data profiling	Analysis of data content, structure, patterns, and anomalies	Treating profiling as remediation rather than discovery
Data cleansing	Correcting, standardizing, or improving data values	Assuming cleansing solves root causes
Data validation	Checking whether data conforms to defined rules	Assuming valid data is always accurate
Data stewardship	Accountability for data meaning, quality, and use	Confusing steward responsibility with IT ownership of systems
Data owner	Business role accountable for data decisions and priorities	Treating ownership as purely technical custody
Data custodian	Role responsible for technical operation, storage, or protection	Confusing custody with business accountability
Data quality scorecard	Periodic reporting of metrics and thresholds	Reporting metrics without decisions or action plans
Root cause analysis	Investigation of why defects occur	Stopping at symptom correction

Dimension distinctions candidates often miss

Validity vs. accuracy

A value can be valid but not accurate.

Valid: 99999 is a five-digit postal code format.
Not accurate: it is not the customer’s actual postal code.

Notes and examples

Choose validity when the issue is about format, allowed values, or rule conformance. Choose accuracy when the issue is about truthfulness against reality or a trusted source.

Completeness vs. coverage

Completeness usually asks whether required values are present in records that exist. Coverage asks whether the population itself is sufficiently represented.

Example:

Customer records have email populated: completeness.
All active customers are included in the data set: coverage.

Timeliness vs. currency

Timeliness is about availability by the required time. Currency is about whether the value is up to date.

Yesterday’s file arrived before 8:00 a.m.: timely.
The address in the file is three years old: not current.

Consistency vs. integrity

Consistency compares values across places or contexts. Integrity often concerns structural relationships and constraints.

CRM says customer is active; billing says inactive: consistency issue.
Order record references a nonexistent customer ID: integrity issue.

Data quality requirements and rules

A strong data quality rule is specific, testable, tied to business meaning, and owned.

Weak vs. strong rules

Weak statement	Better data quality rule
Customer data should be good	Active customer records must have a non-null customer type
Order dates should make sense	Order date must not be later than shipment date
Product codes should be valid	Product code must exist in the approved product reference table
Duplicate customers should be avoided	No two active customer records may share the same verified national ID
Data should be updated quickly	Trade records must be available in the reporting warehouse within the defined business cutoff

Notes and examples

Rule types

Rule type	What it checks	Example
Domain rule	Value belongs to allowed set	Status is Active, Inactive, Pending, or Closed
Format rule	Value follows pattern	Email contains required structure
Range rule	Value falls within limits	Discount is between 0 and 100 percent
Mandatory rule	Required value is present	Policy number is not null
Cross-field rule	Values are logically compatible	End date is not before start date
Referential rule	Related record exists	Invoice references a valid customer
Uniqueness rule	Entity is not duplicated	One active employee ID per employee
Derivation rule	Calculated value matches formula	Total equals sum of line amounts plus tax
Temporal rule	Timing relationship is valid	Effective date precedes expiration date
Conditional rule	Requirement applies under conditions	Cancellation reason required when status is Cancelled

Data profiling review

Data profiling helps reveal what is actually in the data before defining or refining controls.

Common profiling outputs

Profiling output	What it reveals
Null count or null percentage	Completeness issues
Distinct value count	Cardinality, possible code values, uniqueness clues
Frequency distribution	Unexpected values, dominant values, outliers
Minimum and maximum	Range issues
Pattern analysis	Format inconsistency
Cross-column analysis	Logical conflicts
Duplicate analysis	Uniqueness and entity resolution issues
Referential analysis	Broken relationships
Outlier detection	Potential anomalies requiring investigation

Profiling traps

Profiling finds symptoms; it does not automatically determine root cause.
A surprising value is not always an error. It may be a legitimate business exception.
Profiling without business context can produce misleading conclusions.
Technical profiling should be paired with metadata, definitions, lineage, and process knowledge.
Do not remediate solely because a value is rare. Confirm business rules first.

Measurement and metrics

Data quality metrics should be understandable, repeatable, actionable, and tied to thresholds.

Common metric structures

Metric	Plain-language calculation
Completeness rate	Number of records with required value / number of applicable records
Validity rate	Number of records passing rule / number of records tested
Defect rate	Number of failed records / number of records tested
Duplicate rate	Number of duplicate records / number of records assessed
Timeliness rate	Number of deliveries meeting cutoff / number of expected deliveries
Accuracy rate	Number of verified accurate records / number of verified records
Issue aging	Time since issue was opened or detected
Remediation rate	Number of resolved issues / number of opened issues in period

Notes and examples

Metric quality checklist

A useful data quality metric should have:

A clear business definition.
A defined population.
A clear numerator and denominator.
An owner.
A measurement frequency.
A threshold or target.
An escalation path.
A link to business impact.
A way to distinguish severity, trend, and recurrence.

Metadata and business glossary

Metadata is essential for data quality because it clarifies meaning, lineage, rules, and responsibility.

Metadata that supports data quality

Metadata type	Example
Business definition	What “active customer” means
Data owner	Business accountable role
Data steward	Role responsible for quality coordination
Valid values	Approved code set
Data lineage	Source-to-target flow
Transformation rule	How source field is converted
Quality rule	Expected condition
Threshold	Acceptable quality level
Security classification	Access and handling requirement
Retention information	How long data is kept according to policy

Exam trap

If a scenario shows inconsistent reporting because teams define the same term differently, the best answer is usually not “clean the database.” It is to resolve definitions, governance, metadata, and lineage.

Governance and accountability

Data quality requires business accountability and cross-functional coordination. IT can implement controls, but business stakeholders define quality requirements and acceptable thresholds.

Typical responsibilities

Role	Typical responsibility
Data owner	Accountable for data domain decisions, priorities, and acceptable quality
Data steward	Coordinates definitions, rules, issue resolution, and quality monitoring
Data custodian	Operates technical environment and implements technical controls
Data governance council	Resolves cross-domain priorities, standards, and escalations
Data quality analyst	Profiles data, develops metrics, investigates issues
Business process owner	Ensures processes capture and use data correctly
Data architect	Designs structures and integration patterns that support quality
Application owner	Supports system-level validation and workflow changes

Accountability trap

Do not assign all data quality responsibility to IT. Technical teams often implement solutions, but data quality requirements, definitions, priorities, and acceptance criteria must be business-led.

Data quality in analytics and reporting

Analytics failures often stem from poor definitions, inconsistent transformations, incomplete populations, or stale data.

Problem in report or model	Likely data quality issue
Totals differ between dashboards	Definition, lineage, transformation, or timing inconsistency
Model performs poorly for a customer segment	Coverage, completeness, bias, or representativeness issue
Report includes inactive products	Reference/master data or filter logic issue
Trend line changes unexpectedly	Source change, late-arriving data, or transformation change
KPI cannot be reconciled	Lack of lineage, unclear metric definition, aggregation mismatch

Candidate mistake

Do not assume every reporting discrepancy is a data warehouse defect. It may originate in source systems, business definitions, integration timing, transformation logic, or report filters.

Data quality and data integration

Data movement can create or reveal quality defects.

Integration quality checks

Check	Purpose
Record counts	Confirm expected volume moved
Control totals	Reconcile numeric totals
Hash totals or checksums	Detect changes or transfer errors
Referential checks	Confirm relationships remain valid
Domain checks	Confirm valid codes after transformation
Mapping validation	Confirm source-to-target logic
Exception handling	Capture rejected or suspect records
Latency monitoring	Confirm timeliness
Lineage documentation	Show how values were produced

Trap

A successful file load does not mean the data is fit for purpose. Technical completion and data quality are related but different.

Data quality costs and business value

Data quality initiatives should be justified by business impact, risk reduction, efficiency, and trust.

Cost categories

Cost type	Example
Prevention cost	Training, validation controls, standards
Appraisal cost	Profiling, monitoring, audits
Internal failure cost	Rework, manual correction, process delays
External failure cost	Customer impact, incorrect reporting, operational failure

Business value examples

Reduced operational rework.
More reliable reporting.
Improved customer experience.
Better regulatory or risk reporting support.
Reduced duplicate processing.
Faster integration and migration.
More trustworthy analytics.
Improved process automation.

Prioritization

Not all data defects deserve equal effort. Prioritize based on criticality, impact, and feasibility.

Prioritization matrix

High impact?	Easy to fix?	Typical action
Yes	Yes	Fix quickly and monitor
Yes	No	Escalate, plan remediation, implement compensating controls
No	Yes	Fix if low effort and no adverse effects
No	No	Defer, monitor, or accept risk

Better prioritization considers

Critical data elements.
Business process dependency.
Customer or stakeholder impact.
Risk and control implications.
Number of affected records.
Severity of errors.
Frequency and recurrence.
Root cause complexity.
Remediation cost.
Availability of preventive controls.

Data quality strategy

A mature data quality program is proactive, governed, measured, and continuously improved.

Strategy components

Component	Purpose
Scope and priorities	Focus on highest-value domains and data
Governance model	Define accountability and decision rights
Standards	Promote consistent rules, definitions, and controls
Metrics and thresholds	Make quality measurable
Issue management	Provide repeatable resolution process
Tooling	Support profiling, rules, monitoring, and remediation
Communication	Build awareness and transparency
Training	Improve data capture and stewardship behavior
Continuous improvement	Reduce recurrence and mature controls

Maturity perspective

Data quality maturity generally progresses from reactive correction to proactive prevention and optimization.

Maturity level	Characteristics
Ad hoc	Issues fixed manually when noticed
Reactive	Cleansing projects respond to recurring problems
Managed	Rules, owners, and issue processes exist
Measured	Metrics, scorecards, and thresholds guide action
Optimized	Prevention, automation, governance, and continuous improvement are embedded

Exam logic

If a scenario asks how to improve maturity, prefer actions that institutionalize ownership, standards, measurement, and root-cause prevention over isolated clean-up.

Common scenario patterns

Scenario: many missing values

Best response depends on why values are missing.

Likely cause	Better response
Field not required at entry	Add validation or workflow requirement
Users do not know value	Provide training or change process
Value not applicable	Adjust rule to account for applicability
Source system does not capture value	Change source process or source mapping
Optional data being treated as mandatory	Revisit business requirement

Notes and examples

Scenario: duplicate customers

Good answer usually includes:

Define matching criteria.
Profile duplicates.
Establish survivorship rules.
Assign stewardship review for ambiguous matches.
Merge or link records carefully.
Improve capture and matching controls at onboarding.
Monitor duplicate rate.

Scenario: inconsistent report numbers

Compare business definitions.
Review lineage and transformations.
Check timing and refresh cycles.
Reconcile source-to-target counts and totals.
Identify authoritative source.
Establish governed KPI definition.

Scenario: invalid reference codes

Align code sets and definitions.
Validate against approved reference data.
Fix source mappings.
Add interface controls.
Establish owner for reference data changes.
Monitor exceptions.

Scenario: recurring defects after cleansing

Perform root cause analysis.
Fix upstream process or system controls.
Clarify ownership and rules.
Add monitoring.
Avoid another isolated cleansing-only project.

Data quality tools

Tools support data quality work, but they do not replace governance or business rules.

Tool capability	Supports
Profiling	Discovery of patterns and defects
Rule engine	Automated validation
Data cleansing	Standardization and correction
Matching and deduplication	Entity resolution
Monitoring	Ongoing scorecards and alerts
Metadata management	Definitions, lineage, rules
Workflow	Issue tracking and stewardship tasks
Reference data management	Controlled code lists
Master data management	Golden records and entity consistency
Data observability	Pipeline and anomaly monitoring

Tooling trap

Selecting a tool before defining business requirements, ownership, and rules is usually not the strongest answer.

Formulas worth knowing conceptually

You do not need to over-memorize formulas, but you should understand the structure of basic quality rates.

\[ \text{Validity Rate} = \frac{\text{Records Passing Validation Rule}}{\text{Records Tested}} \]\[ \text{Defect Rate} = \frac{\text{Records Failing Quality Rule}}{\text{Records Tested}} \]\[ \text{Completeness Rate} = \frac{\text{Applicable Records With Required Value Present}}{\text{Applicable Records}} \]

Key exam point: define the applicable population carefully. A completeness denominator should exclude records where the field is genuinely not applicable.

Mini review: from issue to action

Issue type	Immediate action	Sustainable action
Missing mandatory fields	Identify affected records	Add capture control and ownership
Invalid codes	Reject or correct exceptions	Govern reference data and mappings
Duplicate entities	Match and merge carefully	Improve onboarding and matching controls
Late feeds	Alert and reload if needed	Define service expectations and monitoring
Inconsistent definitions	Reconcile current outputs	Establish glossary and governed KPI
Bad source extract	Quarantine and investigate	Add source validation and contract expectations
Transformation error	Correct mapping	Add testing and lineage documentation
Untrusted report	Validate calculations	Govern metrics and certify data source

What to practice next

After reviewing these concepts, move into IT Mastery practice for the DAMA International DAMA CDMP Data Quality Specialist (CDMP Quality) exam. Start with topic drills on data quality dimensions, profiling, rules, issue management, governance roles, and root-cause scenarios. Then use original practice questions and mock exams with detailed explanations to test whether you can choose the best action in realistic data quality situations.

Put the review into practice

Study Plan