Pass the DAMA CDMP DQ-1220 Questions and answers with ExamsMirror

DAMA-DMBOK2 explicitly states that a Data Governance program must be sustainable. Governance is not a temporary implementation project that ends after policies, committees, or stewardship roles are established. It is an ongoing organizational capability requiring continuing leadership, sponsorship, ownership, decision rights, and operational integration.

The DMBOK2 governance guidance describes sustainable governance as “sticky”: it must survive beyond its initial implementation and become embedded in normal business and Data Management practices. Sustainable governance depends specifically on business leadership, sponsorship, and ownership.

This distinction matters for Data Quality because quality improvement is likewise continuous. New applications, data sources, business processes, regulatory requirements, and transformations continually create new risks. Governance must therefore continue assigning accountability, approving definitions and quality rules, resolving cross-domain disputes, and overseeing remediation.

Options focused on financial registration or assigning a dollar value confuse data-as-an-asset thinking with formal accounting treatment. Data valuation can support investment decisions, but it is not a prerequisite for Data Governance. Likewise, treating governance as a fixed-duration initiative contradicts the operating model described by DAMA.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Data Governance Goals and Principles; Sustainable Governance; Leadership; Sponsorship; Ownership; Chapter 13 — Data Quality Governance.

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

The need to manage data movement efficiently is a primary business driver for Data Integration and Interoperability (DII). DAMA-DMBOK2 states this directly. Modern organizations operate hundreds or thousands of databases, applications, files, services, data stores, external interfaces, and analytical platforms. Data must continually move among these environments, often across organizational boundaries.

Without disciplined integration management, data movement becomes fragmented, expensive, difficult to monitor, and highly dependent on duplicated point-to-point interfaces. DII addresses this problem by establishing controlled mechanisms for extraction, transformation, messaging, replication, orchestration, APIs, data virtualization, and other forms of information exchange.

From a Data Quality perspective, every movement of data presents an opportunity either to preserve quality or to damage it. Source-to-target mappings must maintain semantic meaning, transformations must be controlled, reference values must remain consistent, and lineage must show how values were altered.

Metadata Management therefore records mappings, interface definitions, transformation rules, and lineage. Master Data Management uses integration mechanisms to distribute governed master and reference data consistently between systems.

Data Warehousing is a major consumer of integration capabilities, but the broader discipline whose explicit driver is efficient movement across systems is Data Integration and Interoperability.

Reference Topics: DAMA-DMBOK2 Chapter 8 — Business Drivers; Data Integration and Interoperability; Data Movement; Chapter 13 — Consistency, Integrity and Transformation Quality.

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

Whether the rule is mandatory is a business governance decision and should be approved through the appropriate Data Owner, Data Steward, or governance authority responsible for the Supplier domain.

A developer can implement a database constraint, but technical implementation does not establish business policy. The organization must determine whether every active supplier genuinely requires a tax identifier, whether exceptions exist by jurisdiction or supplier type, and what consequences should follow when the rule is violated.

The approved rule should be documented as metadata and linked to the relevant business term, physical fields, authoritative sources, threshold, and responsible steward.

This illustrates the separation between governance and execution. Governance defines and authorizes the requirement; operational and technical teams implement the validation and monitoring.

DAMA's public framework places Governance across the Data Management knowledge areas and Metadata Management as the mechanism for maintaining definitions, lineage, and usage context.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Governance and Stewardship; Chapter 13 — Data Quality Rules; Metadata Management; Supplier Master Data.

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

Data transformation includes operations such as format changes, structural changes, semantic conversion, de-duplication, and re-ordering. These activities modify source information so that it conforms to the syntactic, structural, or semantic requirements of a target environment.

A format transformation may convert dates from DD/MM/YYYY to an ISO representation. Structural transformation may split, combine, flatten, or restructure attributes. Semantic conversion changes representation while preserving intended meaning—for example, translating a source status code into the standardized enterprise code. De-duplication identifies multiple records representing the same real-world entity, while re-ordering changes the sequence or organization of records or attributes. The listed combination aligns directly with DAMA-oriented transformation guidance.

The distinction from the distractors is important. Organizational change, infrastructure replacement, or application modernization may trigger data transformation, but they are not themselves data-transformation techniques. “Re-duplication” is also inconsistent with the objective of improving integrated datasets.

Transformation is strongly connected to Data Quality. Poorly specified conversion rules can create invalid values, truncate data, introduce semantic inconsistencies, or produce duplicate entities. Consequently, transformations should be documented through mappings and metadata, tested against quality rules, reconciled with source totals, and monitored for exceptions.

Reference Topics: DAMA-DMBOK2 Chapter 8 — Transformation and Mapping; ETL/ELT; Chapter 13 — Standardization, Cleansing, De-duplication and Validation.

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

Country codes associated with country names are a classic example of Reference Data. DAMA-DMBOK2 defines Reference Data as data used to characterize or classify other data or to relate organizational data to externally defined information. The simplest reference-data structure consists of a code and its corresponding description. DMBOK2 specifically uses geographic and standards-based examples, including country codes such as DE, US, and TR.

A code such as GB therefore acts as a standardized machine-processable value, while “United Kingdom” supplies the human-readable meaning. Such code lists are reused across applications, integrations, reporting platforms, Master Data systems, and analytical environments.

Reference Data quality is important because inconsistent code sets can create widespread downstream defects. If different systems use incompatible country codes, the organization may experience failed integrations, incorrect aggregation, duplicate mappings, reporting discrepancies, and inconsistent interpretation. Data Governance should therefore establish authoritative sources and stewardship responsibilities for important reference domains.

Metadata Management records the meaning, provenance, permitted values, relationships, and mappings between code sets. Master Data Management frequently consumes these governed codes to classify master entities such as customers, suppliers, products, and locations.

The other choices describe relationships or transformations, but they do not represent the straightforward code-value/description list structure identified by DAMA.

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

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

The definition describes Data Policies. DAMA-DMBOK2 states that data policies are directives that translate organizational principles and management intent into fundamental rules controlling how data is created, acquired, protected, maintained, assured for quality, and used.

The distinction between governance and policy is important. Data Governance is the broader authority and decision-making framework. Policies are one of the principal instruments produced or sponsored through that framework. They define what must or must not occur. Standards and procedures subsequently translate those policies into specific implementation requirements and operational methods.

For Data Quality, a policy might require business-critical data to have designated ownership, documented definitions, measurable quality rules, monitored thresholds, and formal remediation processes. The detailed thresholds themselves may reside in standards or rule repositories rather than in the high-level policy.

Metadata Management makes policy operational by documenting definitions, classifications, ownership, lineage and applicable quality rules. Master Data Management applies those policies to shared business entities and controlled reference values. Data Stewards then monitor compliance and escalate violations through governance mechanisms.

Data asset valuation is concerned with determining economic value, while Data Management encompasses the complete discipline. Neither provides the specific “directive” definition stated in the question.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Data Policies; Governance Principles; Standards and Procedures; Chapter 13 — Data Quality Governance; Metadata and Master Data interactions.

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

DAMA-DMBOK2 distinguishes the two concepts according to origination versus authoritative consumption. A System of Record (SoR) is an authoritative system in which data is created, captured, or maintained according to defined rules and expectations. A System of Reference (SoRef) is an authoritative location from which consumers obtain reliable information for transactions or analysis even though that information may have originated elsewhere.

Therefore, option A expresses the essential distinction most accurately. For example, an operational CRM may be the System of Record for customer data because customer information is captured and maintained there. An MDM hub or enterprise data-sharing platform can subsequently become the System of Reference used by other applications, even though the original data was created in the CRM.

This distinction is important for Data Quality and lineage. Consumers need to know where values originated, where authoritative corrections are performed, which system distributes trusted values, and which stewardship process governs conflicts between sources. Metadata should therefore record source lineage, system roles, transformations, and authoritative status.

Option D is incorrect because “System of Record” and “System of Reference” do not correspond respectively to master data and reference data categories. Either architectural role can participate in managing different categories of enterprise data.

Reference Topics: DAMA-DMBOK2 Chapter 10 — System of Record and System of Reference; Trusted Sources; MDM Architecture; Metadata Lineage; Chapter 13 — Data Quality and Reference/Master Data Management.

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

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.

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

DAMA-DMBOK2 identifies two recognized approaches for resolving logical supertype-subtype abstractions when moving into physical database design: Subtype Absorption and Supertype Partition.

With Subtype Absorption, attributes belonging to subtype entities are incorporated into the table representing the supertype. Attributes that apply only to particular subtypes may consequently be nullable. This approach reduces the number of physical tables but can introduce sparsity and requires explicit rules to ensure subtype-specific attributes remain semantically valid.

With Supertype Partition, the attributes belonging to the supertype are carried into separate physical tables representing each subtype. This can simplify subtype-specific processing but introduces duplication of common structures and requires disciplined metadata and modelling control.

The choice has direct consequences for Data Quality. Subtype absorption requires validity and completeness rules to distinguish legitimate nulls from missing data. Supertype partition requires consistency controls to ensure shared attributes retain identical definitions and constraints across subtype tables. Metadata repositories should document subtype discriminators, attribute definitions, constraints, and inheritance rules.

DMBOK2 therefore treats the transformation as a deliberate physical modelling decision rather than the generic “merge/split” terminology presented in the distractors.

Reference Topics: DAMA-DMBOK2 Chapter 5 — Physical Data Modeling; Resolve Logical Abstractions; Chapter 13 — Validity, Completeness and Consistency; Metadata Management.

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

An enterprise Master Data Repository serving multiple applications is a classic Hub-and-Spoke integration pattern. In this architecture, shared information is consolidated physically or virtually in a central hub, while participating applications interact with that hub rather than building a separate direct interface to every other application.

DAMA-DMBOK2 explicitly identifies Master Data Management hubs, Data Warehouses, Data Marts, and Operational Data Stores as familiar examples of data hubs. The hub-and-spoke model reduces the proliferation of point-to-point interfaces and can provide a consistent enterprise view of shared data.

This architecture is particularly appropriate for MDM because customer, product, supplier, location, or other master entities often need to be standardized, matched, governed, and redistributed across many systems. The central hub can apply survivorship rules, reference mappings, stewardship decisions, and quality controls before distributing trusted values.

Replication and Change Data Capture are techniques for moving or detecting changes in data, but neither describes the overall interaction topology. Publish-subscribe may operate alongside an MDM hub as a distribution mechanism, but the enterprise repository itself represents the hub within a hub-and-spoke architecture.

Reference Topics: DAMA-DMBOK2 Chapter 8 — Hub-and-Spoke; Integration Interaction Models; Chapter 10 — Master Data Management; Enterprise Master Data Hub; Data Quality Consistency.

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