DQ-1220 DAMA Data Quality Specialist Free Practice Exam Questions (2026 Updated)

Critical Data Elements are identified so that organizations can concentrate governance and Data Quality effort where failure would create the greatest business impact.

Not every attribute deserves the same level of profiling, monitoring, stewardship, lineage documentation, control, and remediation. Applying identical controls to every field would usually be economically inefficient and may divert resources away from information that supports regulation, financial reporting, key operations, customer outcomes, or strategic decisions.

The DMBOK2 maintenance revision explicitly adds and clarifies the concept of a Critical Data Element within Chapter 13.

Once a CDE is identified, the organization can define applicable quality dimensions, measurable rules, thresholds, ownership, authoritative sources, lineage, issue escalation, and monitoring frequency.

Criticality is contextual. An attribute may be critical to one process and relatively insignificant to another. The decision should therefore reflect documented business use and risk rather than technical prominence.

Metadata remains essential because it links the CDE to definitions, systems, lineage, owners, and quality controls.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Critical Data Elements; Prioritization; Business Impact; Risk; Data Governance; Metadata.

===============

Loading standardized country codes into a CRM is a classic example of Reference Data Integration. Country codes constitute controlled reference values used to classify or characterize other data. They differ from transactional information such as orders and payments and from master entities such as individual customers or products.

DAMA treats countries, currencies, geographic classifications, status codes, and similar controlled domains as typical Reference Data. The uploaded question therefore tests the distinction between integrating reusable code sets and integrating Master or Transaction Data. Published versions of the same DAMA item confirm Reference Data Integration as the intended answer.

In practice, an authoritative reference source may provide standardized country identifiers to CRM, ERP, MDM, analytical, and integration systems. Central management prevents different applications from independently inventing or changing equivalent codes.

This is also a Data Quality control. Reference integration improves Validity by restricting values to approved domains and Consistency by ensuring that different systems interpret equivalent countries identically. For example, an uncontrolled mixture of GB, UK, 826, and proprietary internal codes may create integration and reporting errors unless mappings are formally governed.

Metadata should document the authoritative source, code meaning, effective dates, mappings, ownership, and applicable standards.

Reference Topics: DAMA-DMBOK2 Chapter 10 — Reference Data; Code Sets; Reference Data Integration; Authoritative Sources; Chapter 13 — Validity and Consistency.

===============

The precise DAMA-DMBOK2 purpose of Data Governance is to ensure that data is managed properly according to policies and best practices. DMBOK2 distinguishes this governance purpose from the broader objective of Data Management, which is concerned with obtaining value from data throughout its lifecycle.

Governance establishes the authority and control framework within which operational data-management functions work. This includes strategy, policy, standards, accountability, stewardship, compliance, issue escalation, quality oversight, and decision rights. DMBOK2 specifically identifies governance responsibilities involving policies for metadata, access, security and quality; setting Data Quality and Data Architecture standards; and providing oversight and corrective action.

This distinction is critical for Data Quality. Data Quality Management performs activities such as profiling, measurement, root-cause analysis, cleansing and monitoring. Data Governance determines who has authority, which requirements are mandatory, what thresholds are acceptable, which issues require escalation, and who owns remediation decisions.

Metadata Management supports governance by recording authoritative definitions, lineage, ownership and quality rules. Master Data Management operationalizes governance for shared business entities and reference domains.

Options B, C and D describe legitimate aspects of wider Data Management, but they do not state the specific purpose assigned to Data Governance by DMBOK2.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Introduction; Goals and Principles; Governance Oversight; Chapter 13 — Data Quality and Governance.

===============

An MDM investment is justified when the business value obtained from centralized coordination of shared data exceeds the additional cost of managing and integrating another controlled representation of that data. This is the economic trade-off expressed by option C and is also the intended answer in published versions of this DAMA question.

DAMA-DMBOK2 positions Master Data Management as a mechanism for improving consistency and control over enterprise entities such as customers, products, suppliers, employees, and locations. Uncoordinated local copies create redundant maintenance, inconsistent definitions, duplicate records, reconciliation costs, and integration complexity. DAMA sources emphasize that controlling shared master and reference data reduces both cost and risk generated by inconsistencies between systems.

However, introducing an MDM repository also incurs costs: integration, stewardship, matching, survivorship logic, synchronization, governance, maintenance, and potentially another physical copy of shared information. The business case must therefore demonstrate that improved coordination, quality, reuse, reporting, and operational consistency outweigh those costs.

MDM does not require all contributing systems to be decommissioned, nor does it eliminate Reference Data Management. Similarly, “mining golden records” is not the fundamental economic basis for MDM.

Reference Topics: DAMA-DMBOK2 Chapter 10 — Master Data Management; Business Drivers; Shared Data; Central Coordination; Data Integration; Data Quality and Stewardship.

===============

The activity is Standardization. Standardization converts semantically equivalent values into a consistent representation so they can be compared, matched, integrated, and interpreted reliably.

In the scenario, Street, St., and Str may represent the same address concept but differ syntactically. Converting them to an approved standard reduces superficial variation before entity matching.

Standardization is commonly used for names, addresses, telephone numbers, units of measure, dates, product descriptions, geographic references, abbreviations, and coded values. It frequently precedes matching and de-duplication because entity-resolution algorithms perform more effectively when predictable representational differences have already been normalized.

Reference Data and Metadata Management are important supporting disciplines. Reference Data can define approved abbreviations or formats, while metadata documents transformation rules and intended meaning.

Standardization does not prove that the resulting address is factually accurate. It improves consistency and comparability. An address can be perfectly standardized yet belong to the wrong customer.

Therefore, standardization should be combined with validation, verification, matching, and source-improvement controls where appropriate.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Standardization; Cleansing; Matching; Consistency; Reference Data Management.

===============

Within the DMBOK2 framing used by this certification material, the expanded characteristics are Volume, Velocity, Variety/Variability, Viscosity, Volatility, and Veracity. Option E is therefore the only choice that correctly contains the DAMA terms represented in the question. DMBOK-oriented study material explains that the original three Vs—Volume, Velocity, and Variety—were expanded to include Variability, Viscosity, Volatility, and Veracity in the broader characterization.

Volume concerns data quantity; Velocity concerns the rate of creation and processing; Variety/Variability concerns differing structures and changing representations; Viscosity describes difficulty in using or integrating the data; Volatility concerns how quickly usefulness or meaning changes; and Veracity addresses credibility and trustworthiness.

These characteristics have direct Data Quality implications. Increased variety creates semantic and structural consistency challenges. Velocity reduces the time available for traditional validation. Volatility affects currency and timeliness. Veracity is directly concerned with reliability.

DAMA's key point is that Big Data does not reduce the need for management discipline. Its scale and complexity increase the need for metadata, governance, automated profiling, lineage, and statistically driven quality controls.

Reference Topics: DAMA-DMBOK2 Big Data and Data Science — Big Data Characteristics; Volume; Velocity; Variety/Variability; Viscosity; Volatility; Veracity; Chapter 13 — Scalable Data Quality.

===============

DAMA-DMBOK2 distinguishes descriptive, structural, and administrative metadata when discussing metadata classifications used outside conventional IT contexts. Descriptive metadata identifies and describes a resource sufficiently to enable discovery and retrieval. DMBOK2 gives title, author, and subject as explicit examples of descriptive metadata.

A book's author, title, and subject therefore answer practical discovery questions: What is the resource? Who created it? What is it about? These attributes allow catalogues, repositories, search tools, and users to identify and retrieve the required resource.

Option A is principally structural metadata. DMBOK2 specifically identifies the number of pages and chapters as examples describing relationships within or among the components of a resource. Option D represents administrative metadata because version numbers and archive dates help manage the resource throughout its lifecycle.

The distinction is important to Data Quality because metadata itself must have appropriate completeness, consistency, currency, and accuracy. Incorrect descriptive metadata can make a valid data asset effectively undiscoverable or lead users to select an inappropriate source.

Metadata Management therefore supports Data Quality by giving data consumers reliable definitions, context, provenance, ownership, lineage, and usage information.

Reference Topics: DAMA-DMBOK2 Metadata Management — Descriptive Metadata; Structural Metadata; Administrative Metadata; Metadata Quality; Chapter 13 — Data Quality and Metadata Management.

===============

A Business Data Steward, working with relevant business stakeholders and governance bodies, is the appropriate role to define or coordinate business meaning and quality expectations.

Quality requirements cannot be derived solely from database structures. The organization must understand what the attribute means, how it is used, what values are acceptable, which source is authoritative, and what consequences arise when it is wrong.

Data Stewards bridge business knowledge and formal Data Management controls. They commonly participate in maintaining glossary definitions, defining business rules, resolving issues, clarifying ownership, and establishing Data Quality expectations.

Technical specialists contribute implementation knowledge. A DBA may identify datatype constraints, while an integration specialist can implement transformations. Neither should independently determine business meaning.

DAMA's public framework describes Metadata Management as supporting definitions, lineage, and governance, while Reference and Master Data Management ensures consistency in shared core entities.

The strongest operating model therefore combines business accountability with technical execution.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Data Stewardship; Chapter 11 — Business Metadata; Chapter 13 — Data Quality Requirements; Critical Data Elements.

===============

The concept described is Data Lineage. Data lineage records how data originates, moves, transforms, and is consumed across the information landscape. DAMA-oriented architecture guidance explicitly links implementation of Data Architecture with visibility into transformations occurring as data traverses systems and identifies this as lineage.

Lineage can operate at several levels. At a high level, it may identify that customer information moves from CRM into an integration platform, Master Data hub, warehouse, and reporting environment. At a detailed level, it may show that a particular report column derives from a specific source attribute through documented calculations, mappings, and transformation rules.

This capability is fundamental to Data Quality. When an incorrect result appears in a report, lineage helps analysts trace the defect upstream to the point where it originated or was introduced. It also supports root-cause analysis, impact assessment, regulatory traceability, change management, and reconciliation.

Metadata Management provides the repository structures needed to capture and maintain lineage. Data Governance determines which lineage must be documented and who is accountable for maintaining it.

ETL is one mechanism through which data may move and transform, but ETL is not the architectural concept describing the end-to-end history and derivation of the data.

Reference Topics: DAMA-DMBOK2 Chapter 4 — Data Architecture; Chapter 11 — Metadata Management; Data Lineage; Chapter 13 — Root-Cause Analysis and Data Quality Traceability.

===============

Web-scale search-engine repositories commonly operate according to BASE: Basically Available, Soft State, Eventually Consistent. BASE is associated with distributed and many NoSQL data architectures where availability, horizontal scalability, and tolerance of distributed processing are prioritized over the immediate transactional consistency expected from traditional ACID systems.

A web crawler collects and indexes content continuously across very large distributed environments. Different nodes or indexes may temporarily contain slightly different versions of information while updates propagate. The design is acceptable because the system is expected to converge toward consistency rather than guarantee that every replica reflects the identical state at every instant. DAMA-aligned material explicitly contrasts BASE with traditional ACID approaches for large-scale distributed data processing.

ACID—Atomicity, Consistency, Isolation, Durability—is generally associated with transaction-oriented relational systems where individual transactions require strict integrity guarantees. Search indexing has different workload characteristics and can tolerate temporary inconsistency.

The Data Quality implication is that “consistency” must be evaluated according to architectural context. Temporary divergence can be expected behavior in an eventually consistent platform rather than evidence of a defect, provided convergence occurs within acceptable business thresholds.

Reference Topics: DAMA-DMBOK2 — Data Storage and Operations; Distributed Databases; NoSQL; ACID versus BASE; Availability; Consistency.

===============

The ideal combination is a Data Architect and a Data Steward. DAMA-DMBOK2 states explicitly that, ideally, both roles should be assigned to each subject area and even to individual entities within a subject area. This arrangement integrates architectural control with business accountability.

The Data Architect contributes enterprise-wide structural knowledge: subject-area boundaries, entities, relationships, integration requirements, architectural standards, and alignment with the broader Enterprise Data Architecture. The Data Steward contributes authoritative business knowledge and accountability for terminology, business rules, valid values, quality expectations, and appropriate use of the data.

DMBOK2 also describes the enterprise data model as something that should be developed and maintained jointly by Data Architects and Data Stewards working together in subject-area teams.

This pairing is especially valuable for Data Quality because structural correctness alone does not guarantee fitness for purpose. A technically valid model may still contain ambiguous definitions or inappropriate business rules. Conversely, business requirements without architectural discipline can create duplicated or inconsistent structures.

Working together, the Architect and Steward ensure that definitions, models, metadata, lineage, quality rules, and governance decisions remain aligned. DBAs, analysts, modellers, and business analysts are important contributing roles, but they do not provide the same combined architectural and governance accountability.

Reference Topics: DAMA-DMBOK2 Chapter 4 — Data Architecture Governance; Subject Areas; Chapter 3 — Data Stewardship; Enterprise Data Models; Chapter 13 — Data Quality Accountability.

===============

Agile is not one of the four A's of Data Security. DAMA security guidance groups core security processes around Access, Audit, Authentication, and Authorization. These capabilities collectively control who can interact with information resources, establish identity, determine permitted actions, and provide evidence of activity for monitoring and accountability. DAMA-aligned security references identify these four concepts directly.

Authentication confirms the identity of a user or system. Authorization determines what an authenticated identity is permitted to do. Access concerns the actual ability to obtain or interact with data and services. Audit provides traceability by recording and reviewing relevant activities.

Agile, by contrast, is an approach to iterative delivery and project or product development. It may influence how security controls are implemented within development lifecycles, but it is not itself one of the foundational security-control categories identified in this model.

Data Security and Data Quality are separate but related disciplines. Unauthorized modifications can compromise accuracy and integrity, while weak auditability can prevent organizations from identifying how data was altered. Appropriate security controls therefore help preserve the reliability of governed information.

Metadata classification also supports these controls by identifying sensitive data and linking it to access and protection requirements.

Reference Topics: DAMA-DMBOK2 Chapter 7 — Data Security; Access; Authentication; Authorization; Audit; Data Governance; Chapter 13 — Integrity and Controlled Data Modification.

===============

In a data model, entities are linked by relationships. An entity represents a distinguishable business concept or thing about which the organization stores information, while a relationship expresses how one entity is associated with another.

For example, a Customer places an Order, an Order contains Order Lines, and a Product appears on an Order Line. Relationships therefore capture business semantics rather than merely physical implementation details. Cardinality is an important characteristic of a relationship because it specifies how many instances of one entity may or must be associated with instances of another; however, cardinality is not itself the general mechanism by which entities are linked. DAMA-oriented modelling material identifies relationships as the correct linkage concept.

Indexes and triggers are physical database mechanisms. Processes describe business activities and may interact with entities, but they do not define entity-to-entity structure within a data model.

The Data Quality implications are significant. Properly defined relationships establish expectations for referential integrity. For example, an Order referencing a nonexistent Customer indicates an integrity defect. Profiling can test orphaned foreign keys, invalid relationship cardinalities, and inconsistent associations.

Relationships and their cardinalities should therefore be documented as metadata and enforced through appropriate database, application, or quality controls.

Reference Topics: DAMA-DMBOK2 Chapter 5 — Entities, Relationships and Cardinality; Logical Data Modeling; Chapter 13 — Integrity and Consistency; Metadata Management.

===============

The issue is Currency. Currency concerns whether data remains sufficiently aligned with the current real-world state. The address was accurate when originally captured, but reality changed and the system was not updated.

This distinction matters because Data Quality can degrade over time without any technical error being introduced. Customer addresses, employment details, product prices, organizational structures, regulatory classifications, and contact details all have varying rates of change. A dataset that was reliable last year may no longer be fit for operational use today.

DAMA's current Chapter 13 revision explicitly identifies Currency as one of the nine standard Data Quality dimensions. Related DAMA-derived guidance also notes that real-world information changes and can therefore become outdated even when it was initially correct.

Organizations should establish refresh expectations according to business use. A marketing mailing list may tolerate a different update interval from an emergency-contact database.

Metadata should document refresh frequency and source authority, while quality monitoring can identify records exceeding acceptable age thresholds.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Currency; Accuracy; Timeliness; Data Aging; Monitoring; Fitness for Purpose.

===============

The principal risk is inconsistent customer-name values across systems. When multiple applications can independently update the same business fact without an authoritative source or coordinated Master Data process, conflicting representations are likely to emerge.

The problem is architectural and governance-related as much as it is a Data Quality issue. The organization must determine where the authoritative value is created, who is responsible for approving changes, how updates propagate, and how conflicts are resolved.

DAMA's public framework emphasizes a single trusted or consistent approach to shared core entities through Reference and Master Data Management.

The relevant Data Quality dimensions include Consistency, Accuracy, Currency, and potentially Uniqueness. An application may hold a technically valid legal name but still contain an outdated or conflicting value.

Metadata and lineage should document which systems create, master, distribute, or merely consume the attribute.

Reference Topics: DAMA-DMBOK2 — Authoritative Sources; Master Data Management; Data Architecture; Consistency; Lineage; Stewardship.

===============

The process is Survivorship. After records have been matched and determined to represent the same entity, survivorship rules determine which attribute values should populate the mastered or preferred representation.

For example, the organization may select the most recently verified telephone number, prioritize a government-verified legal name, or prefer addresses originating from a designated Customer Relationship Management system. Different attributes can use different survivorship rules.

Survivorship is not simply "choose the newest value." The appropriate method may consider source trust, verification status, recency, completeness, confidence scores, stewardship decisions, or combinations of these factors.

The rules must be governed because they determine what the organization subsequently treats as trusted master data. Metadata should record the rule, selected source, lineage, and effective date so the mastered record remains explainable.

DAMA identifies Reference and Master Data Management as responsible for maintaining consistency in core entities such as customers, products, and locations and for supporting trusted shared information.

The Data Quality dimensions involved commonly include Accuracy, Consistency, Currency, Completeness, and Uniqueness.

Reference Topics: DAMA-DMBOK2 Chapter 10 — Master Data Management; Matching; Survivorship; Golden Record; Chapter 13 — Consistency and Accuracy.

===============

This is cross-column dependency profiling. The issue cannot be identified merely by counting null values in Closure_Date because some nulls may be legitimate for active accounts. The defect becomes meaningful only when the relationship between two attributes is examined.

The implied business rule is: if Account_Status = Closed, then Closure_Date must be populated. Dependency profiling examines relationships among values and can reveal conditional completeness, inconsistent combinations, functional dependencies, and other multi-attribute patterns.

The next step is to confirm the inferred pattern with business stakeholders rather than automatically converting it into an enforced rule. There may be exceptional account categories where a closed status legitimately lacks a closure date.

Once approved, the rule should be documented as metadata, assigned to a Data Steward, measured against an agreed threshold, and monitored. Root-cause investigation can then determine whether missing dates arise from source-screen design, process bypass, conversion defects, or integration failures.

DAMA's revised Chapter 13 places Data Quality techniques in a more practical sequence and strengthens their linkage with Data Modeling and Metadata Management.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Data Profiling; Dependency Analysis; Completeness; Business Rules; Metadata Management.

===============

DAMA-DMBOK2 explicitly states that Data Governance represents an inherent separation of duty between oversight and execution. It illustrates the principle through an analogy with financial governance: an auditor exercises oversight over financial processes without personally executing financial management. Similarly, Data Governance ensures that data is properly managed but does not itself perform every operational Data Management activity.

This separation is fundamental because governance must retain sufficient independence to establish rules, monitor compliance, resolve conflicts, assign accountability, and evaluate whether operational teams are managing data according to approved policies and standards.

Option B describes activities in which governance and Data Quality practitioners may collaborate, but it is not the defining governance principle. Option D is also incorrect because federated governance is only one possible operating model; DMBOK2 also recognizes centralized and replicated approaches. Option E describes an organizational implementation, not the conceptual distinction.

Within Data Quality Management, this means that governance may approve quality policies, Critical Data Elements, acceptable thresholds, stewardship structures, and escalation procedures, while DQ analysts and operational teams perform profiling, cleansing, monitoring, and remediation.

Maintaining this division reduces conflicts of interest and establishes accountability for whether data-management activities achieve agreed business objectives.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Essential Concepts; Oversight versus Execution; Governance Operating Models; Chapter 13 — Data Quality Governance and Operational Responsibilities.

===============

The correct definition is the fundamental organisation of a system, and the principles governing its design and evolution. DAMA-DMBOK2 incorporates the ISO/IEC 42010 architectural concept when establishing the theoretical basis for Data Architecture.

The fuller ISO formulation describes architecture in terms of the fundamental organization of a system embodied in its components, their relationships to one another and to the environment, together with the principles governing design and evolution. DAMA uses this concept to distinguish true architecture from a collection of diagrams or implementation specifications.

Option E is therefore incomplete: architectural artifacts document architecture, but the artifacts themselves are not the architecture. Option C focuses too narrowly on implementation and maintenance, while options B and D describe potential objectives or constraints rather than the definition.

Applied to enterprise data, this means architecture establishes the high-level organization of data assets, information flows, platforms, relationships, and guiding principles by which the data environment evolves.

Data Quality benefits because architectural principles establish where authoritative information originates, how it moves, how duplication is controlled, and where governance and quality controls must operate.

Reference Topics: DAMA-DMBOK2 Chapter 4 — Architecture Definition; ISO/IEC 42010; Enterprise Data Architecture; Architectural Principles; Chapter 13 — Quality by Design.

===============