DAMA CDMP Data Quality Specialist Scenario Practice Guide

How to Approach CDMP Quality Scenario Questions

Scenario questions on the DAMA CDMP Data Quality Specialist exam, exam code CDMP Quality, usually test whether you can apply data quality concepts to a realistic business or data management situation. The best answer is rarely the option that sounds most technical. It is the option that best fits the business problem, data lifecycle stage, quality dimension, governance context, and evidence given in the scenario.

Use the scenario as a case file. Your job is to identify:

• What data is affected
• What business process or decision depends on it
• What quality issue is described
• Whether the question asks for diagnosis, prevention, remediation, measurement, governance, or communication
• Which option is most defensible from the facts provided

This guide is independent exam-preparation guidance and is not affiliated with DAMA International.

Start by Finding the Actual Decision Point

Before reading the answer options deeply, pause and ask: What decision am I being asked to make?

Many data quality scenarios include several issues at once: missing values, inconsistent codes, duplicate records, unclear ownership, and weak controls. The exam question may not ask you to solve everything. It may ask for the first step, best control, most appropriate metric, primary cause, or most suitable governance action.

Look for the verb in the question stem:

• Identify: classify the issue, dimension, role, or cause.
• Select / choose: pick the best method, control, metric, or next action.
• Recommend: balance business impact, feasibility, governance, and sustainability.
• Determine: use the scenario evidence to infer root cause, quality dimension, or process weakness.
• Prioritize: choose the action that addresses risk, business value, or dependency first.

A useful habit is to rewrite the question in plain language:

“Given these facts, what should the data quality professional do next?”

or:

“Which choice best addresses the quality requirement without ignoring governance, ownership, and business impact?”

That short rewrite helps prevent you from chasing every detail in the scenario.

Read the Scenario in Layers

Do not try to interpret every sentence at once. Read the scenario in layers, from context to decision.

Layer 1: Identify the Data Environment

First, locate the setting. Data quality practices differ depending on whether the scenario is about operational data entry, analytics, reference data, master data, migration, integration, reporting, or regulatory reporting.

Ask:

• Is the data created manually, system-generated, imported, or derived?
• Is the issue in a source system, integration layer, warehouse, lakehouse, report, or downstream application?
• Is the affected data operational, analytical, reference, metadata, or master data?
• Is the problem recurring, historical, one-time, or newly discovered?
• Is the data used for customer service, finance, compliance, risk, marketing, operations, or executive reporting?

A scenario about duplicate customer records in multiple operational systems points toward master data, matching, stewardship, and governance. A scenario about inconsistent values in a reporting dashboard may point toward definitions, transformation logic, lineage, or metric standardization.

Layer 2: Find the Business Goal or Impact

Data quality is not only a technical cleanliness exercise. Scenario questions often expect you to connect quality to business use.

Look for:

• Decisions being made from the data
• Business process failure or inefficiency
• Customer, financial, regulatory, operational, or reputational impact
• Service-level expectations
• Risk exposure
• A stakeholder who depends on the data

Examples of business impact clues:

• “Executives no longer trust the dashboard”
• “Invoices are being sent to the wrong address”
• “Customer records cannot be matched across systems”
• “Regulatory submissions require documented data controls”
• “Analysts spend days reconciling conflicting figures”
• “A migration project found many invalid source values”

Once you identify impact, you can choose answers that improve fitness for use, not just answers that make the data look cleaner in isolation.

Layer 3: Determine the Quality Problem

Next, classify the issue. Common data quality dimensions include concepts such as:

• Accuracy
• Completeness
• Consistency
• Timeliness
• Validity
• Uniqueness
• Integrity
• Conformity
• Reliability or trustworthiness
• Fitness for purpose

Do not force a dimension too early. Use the scenario evidence.

For example:

• Missing required tax identifiers suggests completeness.
• Codes that do not match the permitted code set suggest validity or conformity.
• Customer names represented differently across systems may suggest consistency, standardization, or identity resolution.
• Duplicate customer profiles suggest uniqueness and master data management concerns.
• A report updated too late for daily operations suggests timeliness.
• Orders linked to nonexistent customers suggest referential integrity.

When two dimensions seem possible, ask which one the scenario emphasizes. If the issue is “the data arrives after the decision window,” timeliness is usually more central than accuracy, even if the values are correct.

Layer 4: Identify the Lifecycle Stage

The best answer often depends on where the organization is in the data quality lifecycle.

Ask whether the scenario is about:

• Discovery: profiling, assessment, baseline measurement, issue identification
• Definition: business rules, data requirements, standards, dimensions, thresholds
• Prevention: validation at entry, controlled reference data, process redesign, ownership
• Detection: monitoring, profiling, exception reporting, dashboards, controls
• Correction: cleansing, remediation, standardization, matching, enrichment
• Root cause analysis: finding why defects occur
• Sustainment: governance, stewardship, metrics, continuous improvement

If the scenario says the organization has not yet measured or profiled the data, a broad cleansing effort may be premature. If a recurring defect is already understood, profiling alone may not be the best next step. If the issue continues to reappear after cleanup, prevention and root cause controls become more defensible.

Separate Facts, Assumptions, and Distractors

Scenario questions are designed to include more information than you need. Treat every detail as one of three types.

Facts That Drive the Answer

These are details that directly affect the best choice:

• A stated business requirement
• A documented data defect
• A system constraint
• A governance or stewardship requirement
• A known root cause
• A required quality threshold
• A recurring pattern
• A dependency on reference data or master data
• A stated need for monitoring, control, or accountability

Assumptions You Should Not Add

Avoid inventing facts the scenario does not provide. For example, do not assume:

• The organization already has a mature data governance program
• A cleansing tool is available
• The source system can easily be changed
• A data owner has authority to resolve the issue
• A dashboard problem is caused by visualization software
• A migration problem can be solved only by one-time cleanup
• All quality issues are best solved by automation

The answer should be based on the scenario, not on what might be true in your workplace.

Distractors That May Be True but Not Best

An answer can be technically valid and still not be the best answer. For example:

• “Cleanse the data” may help, but it may not address root cause.
• “Create a dashboard” may measure the problem, but not fix it.
• “Implement a new platform” may be excessive if standards or ownership are missing.
• “Ask IT to correct the database” may ignore business rule ownership.
• “Document metadata” may be useful, but not sufficient if the question asks for prevention.

The exam often rewards the answer that fits the decision point most precisely.

Use a Data Quality Decision Sequence

When you are unsure, move through a consistent decision sequence.

1. What is the business use of the data?

Data quality is defined in relation to use. The “best” quality action depends on what the data must support.

Ask:

• Who uses the data?
• What decision or process depends on it?
• What level of quality is required for that use?
• What risk is created by poor quality?

2. What quality requirement is being violated?

Translate the scenario into a requirement.

Examples:

• “All customer accounts must have a valid billing address.”
• “Product category codes must come from the approved reference list.”
• “Monthly revenue must reconcile between finance and reporting.”
• “Duplicate customer identities must be resolved before campaign segmentation.”
• “Data must be available by 8:00 a.m. for daily operations.”

This helps you distinguish vague improvement from targeted quality management.

3. Is the issue known, measured, or only suspected?

Choose the action appropriate to the level of evidence:

• If the issue is suspected, assess or profile.
• If the issue is measured but not understood, analyze root cause.
• If the cause is known, implement corrective and preventive controls.
• If remediation is underway, monitor results and manage exceptions.
• If quality must be sustained, define ownership, metrics, and governance routines.

4. Is the answer preventive, detective, or corrective?

Classify answer options:

• Preventive: stops defects from entering or being created.
• Detective: identifies defects after they occur.
• Corrective: repairs known defects.
• Governance-oriented: assigns accountability, defines standards, and sustains quality.
• Analytical: profiles, measures, or diagnoses.

If the scenario says defects repeatedly reappear, a one-time corrective answer is usually weaker than a preventive or governance-based answer.

5. Who should own the decision?

Data quality scenarios often involve business and technical roles. The most defensible answer usually respects the distinction between:

• Business ownership of meaning, rules, priorities, and acceptable quality
• Technical implementation of validation, integration, storage, and controls
• Data stewardship for coordination, monitoring, issue management, and standards
• Governance bodies for cross-domain decisions, escalation, and policy alignment

If a question involves defining what a field means or what values are acceptable, the answer should usually involve business stakeholders or data owners, not only technical teams.

Match Scenario Clues to Likely Reasoning

Use this quick mapping during review.

Do not use the table mechanically. Use it to direct attention, then confirm with the exact wording of the question.

Interpreting Common Data Quality Scenario Types

Scenario Type 1: Choosing the Best First Step

A “first step” question usually favors understanding before action.

Good first-step reasoning:

• If the business rule is unclear, clarify the rule with the appropriate business owner.
• If the extent of the issue is unknown, profile or assess the data.
• If multiple stakeholders disagree, establish common definitions and ownership.
• If a recurring issue is known but the source is unclear, perform root cause analysis.
• If the risk is urgent and already understood, prioritize containment or remediation.

Example:

A company discovers that customer birth dates are missing in several systems. Marketing wants to cleanse all records immediately, while compliance asks whether birth date is required for all customer types.

The best first step is not automatically “cleanse the missing values.” The scenario questions whether the requirement applies to all records. A defensible first step is to confirm the business rule, required population, and acceptable completeness threshold with the appropriate stakeholders.

Scenario Type 2: Selecting a Data Quality Dimension

Dimension questions require precision. Do not choose the broadest-sounding term if a more specific dimension fits.

Example:

A report includes customer records where the state field contains values such as “California,” “CA,” “Calif,” and “06.”

The issue may involve consistency or conformity to a standard format. If the question emphasizes permitted representation or standardization, conformity or consistency may be more defensible than accuracy. The values may all refer to the correct state, but they do not follow a common standard.

Scenario Type 3: Choosing a Control

Control questions ask how to prevent, detect, or manage defects.

Read for:

• Where the defect is introduced
• Whether the rule is known
• Whether automation is appropriate
• Whether exceptions are allowed
• Who should approve exceptions
• How monitoring will occur

Example:

Sales representatives can enter free-text product codes, causing invalid codes to flow into downstream billing.

A strong control is likely closer to the point of capture: validation against approved reference data or selection from a controlled list. A monthly report may detect errors, but it does not prevent them.

Scenario Type 4: Diagnosing Root Cause

Root cause scenarios often include symptoms across reports, systems, or teams. Avoid treating symptoms as causes.

Possible root causes include:

• Undefined business rules
• Inconsistent data entry processes
• Lack of reference data control
• Poor integration mapping
• Unclear ownership
• Conflicting metric definitions
• Missing validation
• Inadequate metadata
• Process incentives that encourage poor data entry

Example:

The data warehouse team corrects customer status values each month, but the same errors reappear after each load.

The recurring pattern suggests the root cause is upstream. A better answer is likely to investigate and correct the source process, mapping, or validation rule, rather than continuing warehouse-level correction only.

Scenario Type 5: Evaluating Remediation Options

Remediation questions require balancing business impact and sustainability.

Consider:

• Is this a one-time historical cleanup or an ongoing defect?
• Is the correction rule deterministic or does it require human review?
• Is the source of truth known?
• Is there a risk of overwriting valid values?
• Are auditability and traceability required?
• Will corrected data remain corrected?

A defensible remediation answer usually combines correction with controls, especially when the issue is recurring.

Scenario Type 6: Selecting Metrics and Monitoring

Metric scenarios test whether you can measure quality in a way that supports management action.

Strong metrics are:

• Linked to business requirements
• Clearly defined
• Measurable and repeatable
• Assigned to data domains or critical data elements
• Compared to thresholds or targets
• Monitored over time
• Actionable when exceptions occur

Example:

A company wants to improve vendor master data and track whether required payment fields are available before invoices are processed.

A completeness metric for required payment fields, measured before invoice processing and tracked against an agreed threshold, is more relevant than a generic count of total vendor records.

Decide Between Similar Answer Choices

Scenario questions often include two answer choices that both sound reasonable. Use these comparisons to choose the stronger one.

Profiling vs. Cleansing

Choose profiling when:

• The extent, pattern, or severity of issues is unknown.
• The organization needs a baseline.
• Business rules must be tested against actual data.
• Multiple issue types may exist.

Choose cleansing when:

• The defect is known and confirmed.
• Correction rules are defined.
• The data must be remediated for a specific use.
• There is a plan to prevent recurrence or manage exceptions.

Cleansing vs. Root Cause Analysis

Choose cleansing when the question focuses on immediate correction of known bad data.

Choose root cause analysis when:

• The issue recurs.
• Manual rework is repeated.
• Multiple downstream systems show the same defect.
• The organization wants sustainable improvement.
• The scenario asks why the issue occurs.

Business Rule Definition vs. Technical Validation

Choose business rule definition when:

• The valid values or requirements are unclear.
• Stakeholders disagree on meaning.
• The field’s purpose or mandatory status is uncertain.
• A threshold must be approved.

Choose technical validation when:

• The rule is already defined.
• The issue occurs at data capture or integration.
• The requirement can be enforced by system control.

Data Stewardship vs. IT Ownership

Choose data stewardship or business ownership when:

• The issue concerns meaning, policy, standards, or prioritization.
• Cross-functional agreement is needed.
• Exceptions require business judgment.
• Data quality issues must be tracked and resolved across teams.

Choose IT implementation when:

• The business rule is already agreed.
• The question asks about technical enforcement.
• The control requires configuration, integration, or automation.

Dashboard vs. Data Quality Management Process

Choose a dashboard or scorecard when the question asks about visibility, monitoring, trend tracking, or communicating quality results.

Choose a data quality management process when the issue requires ownership, issue workflow, remediation planning, root cause analysis, and continuous improvement.

Read for Constraints, Not Just Preferences

Scenarios often include constraints that change the best answer.

Hard Constraints

Hard constraints usually must be respected:

• Regulatory reporting requirement
• Auditability requirement
• Required approval or ownership
• Known system limitation
• Business deadline
• Data privacy or security restriction
• Critical process dependency
• Source-of-truth designation
• Required use of controlled reference data

Preferences

Preferences are weaker unless the question makes them decisive:

• A team wants the fastest option
• A stakeholder prefers a new tool
• Users dislike manual review
• IT wants to fix the issue downstream
• A department wants its own definition
• A project wants to avoid governance review

When a preference conflicts with a data quality principle, choose the answer that preserves accountability, correctness, and fitness for purpose.

Apply Least Disruptive, Sustainable Reasoning

In data quality scenarios, the best answer often improves quality without creating unnecessary complexity.

Prefer answers that:

• Address the issue at or near its source
• Clarify business rules before automating them
• Use existing governance structures when appropriate
• Establish ownership and accountability
• Prevent recurrence, not just clean existing defects
• Support monitoring and continuous improvement
• Preserve traceability when changes affect reporting or compliance
• Balance business impact with implementation effort

Be cautious with answers that:

• Replace systems before diagnosing the issue
• Clean data without defining rules
• Push all responsibility to IT
• Add manual review for every record without risk-based prioritization
• Monitor defects without a remediation path
• Standardize data without stakeholder agreement
• Ignore downstream business impact

Mini Scenario Walkthroughs

Walkthrough 1: Duplicate Customer Records

Scenario summary:

A retail company has customer records in e-commerce, loyalty, and service systems. Marketing campaigns over-contact some customers because the same person appears multiple times. Teams disagree on which system should be trusted.

Reasoning steps:

1. Environment: Multiple operational systems with customer identity data.
2. Business impact: Poor customer experience and ineffective campaigns.
3. Quality issue: Duplicates, identity matching, uniqueness, possibly consistency.
4. Decision point: Need a sustainable approach, not just ad hoc cleanup.
5. Likely defensible answer: Establish matching and survivorship rules with business ownership and stewardship, then implement controls or master data practices.

A weak answer would focus only on deleting duplicates from one file, because the scenario involves multiple systems and disagreement about trusted sources.

Walkthrough 2: Conflicting Revenue Reports

Scenario summary:

Finance and sales produce different monthly revenue totals. Both teams use the same source system, but they apply different inclusion rules for returns and pending orders.

Reasoning steps:

1. Environment: Reporting and metric calculation.
2. Business impact: Conflicting management information.
3. Quality issue: Consistency of metric definition, business rules, metadata.
4. Decision point: Resolve definition and rule alignment.
5. Likely defensible answer: Agree on standardized revenue definitions, document calculation rules, and align reporting logic.

A purely technical answer, such as rebuilding the dashboard, does not address the underlying rule conflict.

Walkthrough 3: Invalid Reference Values

Scenario summary:

A claims system accepts free-text country names. Downstream analytics must group claims by country, but values include abbreviations, misspellings, and obsolete names.

Reasoning steps:

1. Environment: Operational data capture feeding analytics.
2. Business impact: Unreliable grouping and reporting.
3. Quality issue: Validity, conformity, reference data control.
4. Decision point: Prevent invalid values and standardize existing ones.
5. Likely defensible answer: Use controlled reference data and validation at capture, plus remediation of existing values using approved mapping.

A reporting-only fix may help analytics temporarily, but it does not prevent new invalid values.

Walkthrough 4: Data Quality Scorecard Request

Scenario summary:

Leadership asks for a scorecard showing whether critical product data is improving over time. No baseline metrics currently exist.

Reasoning steps:

1. Environment: Data quality measurement and reporting.
2. Business goal: Track improvement.
3. Quality issue: Not one defect, but lack of measurement.
4. Decision point: Define metrics and establish baseline.
5. Likely defensible answer: Identify critical data elements, define business rules and metrics, profile to establish a baseline, then report trends against thresholds.

Jumping straight to a scorecard tool is less defensible if metrics and baseline are not defined.

A Compact Checklist for Each Scenario

Use this checklist during final review:

1. What data is involved?

   • Customer, product, vendor, financial, reference, master, operational, analytical?

2. What is the business use?

   • Reporting, billing, compliance, analytics, service, operations, migration?

3. What is the issue?

   • Missing, invalid, duplicate, inconsistent, late, inaccurate, unclear, unowned?

4. Which quality dimension is most central?

   • Completeness, validity, consistency, timeliness, uniqueness, integrity, or another dimension?

5. What lifecycle stage is implied?

   • Assess, define, prevent, detect, correct, analyze root cause, monitor?

6. What is the question asking for?

   • First step, best control, metric, role, cause, remediation, governance action?

7. What constraints matter?

   • Business rule, deadline, auditability, ownership, system location, source of truth?

8. Which answer is sustainable?

   • Does it prevent recurrence or only repair symptoms?

9. Who must be involved?

   • Data owner, steward, business subject matter expert, IT, governance group?

10. Which option is best supported by the facts?

• Avoid adding assumptions from personal experience.

How to Practice Scenario Questions Efficiently

For final review, do not only check whether you got a question right. Review why the correct answer is more defensible.

After each practice scenario, write one sentence for each of these:

• The decision point was:
• The key scenario fact was:
• The quality dimension or principle was:
• The best answer was stronger because:
• The tempting alternative was weaker because:

This builds the habit you need on exam day: slow down, identify the actual data quality decision, and choose the answer that best fits the business context and evidence.

Practical Next Step

Continue with focused CDMP Quality scenario practice by drilling one topic at a time, such as profiling, business rules, data stewardship, root cause analysis, metrics, or remediation. Then use mixed mock exams to practice switching between scenario types under time pressure while keeping the same decision sequence.