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

The primary issue is Uniqueness because more than one record represents the same real-world entity. Uniqueness evaluates whether unintended duplicate instances exist within a dataset or across integrated datasets.

Duplicate customer records can arise because of spelling variation, abbreviations, different contact details, weak matching rules, or inconsistent identifier capture. Exact duplicate detection alone is therefore insufficient. Effective entity resolution frequently requires probabilistic or deterministic matching across names, addresses, identifiers, telephone numbers, and other attributes.

DAMA-aligned Data Quality frameworks define uniqueness in terms of avoiding duplicate representation of the same entity. They also recognize that duplicate records may differ in individual attribute values while still representing the same person or object.

The issue is closely related to Master Data Management. An MDM process may match the three source records, establish that they belong to one customer, and apply survivorship rules to construct an authoritative master representation.

The correct remediation should also address the source process that allowed duplicates to be created; otherwise cleansing will merely remove symptoms while new duplicates continue to appear.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Uniqueness; Matching; De-duplication; Chapter 10 — Master Data Management; Entity Resolution.

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

The process is Encryption. DAMA-DMBOK2 defines encryption as converting readable plaintext into coded information so that privileged or sensitive content cannot be understood without the appropriate decryption mechanism. The DMBOK2 security section specifically describes encryption as translating plain text into complex codes to hide privileged information and also notes its use in protecting transmission integrity and validating identity.

Encryption supports confidentiality both at rest and in transit. Depending on implementation, organizations may use symmetric encryption, asymmetric or public-key encryption, hashing for particular integrity or authentication functions, and other cryptographic mechanisms.

The crucial distinction is that encryption deliberately changes the representation of information according to a cryptographic algorithm and key structure. Encapsulation, enhancement, elimination, and exaggeration are not substitutes for cryptographic protection.

Within the wider DAMA framework, encryption should be applied according to classification and risk. Highly sensitive information may require stronger cryptographic controls, restricted key management, rotation procedures, and separation of duties.

Data Quality and Data Security intersect at integrity: unauthorized changes may produce inaccurate data even when availability remains unaffected. Security controls therefore protect not merely secrecy but the reliability and trustworthiness of managed information.

Reference Topics: DAMA-DMBOK2 Chapter 7 — Encryption; Confidentiality; Data Integrity; Cryptographic Controls; Security Classification.

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

Ensuring enterprise business processes are effectively documented is not primarily a Data Architecture mechanism for defining project scope boundaries. That responsibility belongs more directly to Business Architecture, process management, and business-analysis disciplines.

DAMA-DMBOK2 explains that Enterprise Data Architecture influences projects by defining enterprise data requirements, reviewing project data designs, determining lineage impacts, controlling unnecessary replication, enforcing Data Architecture standards, and guiding technology and renewal decisions.

Consequently, options A, B, D, and E all represent valid ways architecture can constrain or guide project scope. A design review checks that local solutions remain compatible with enterprise strategy. Standards prevent individual projects from creating incompatible structures. Replication controls limit uncontrolled proliferation of redundant data. Enterprise data requirements ensure that projects account for information needs beyond their immediate application boundaries.

Documenting business processes remains important because processes produce and consume data, but comprehensive process documentation is not itself a primary Enterprise Data Architecture scope-control activity.

From a Data Quality perspective, architectural influence prevents project-level decisions from creating duplicated authoritative sources, inconsistent definitions, undocumented lineage, or uncontrolled transformations.

Reference Topics: DAMA-DMBOK2 Chapter 4 — Manage Enterprise Requirements within Projects; Architecture Governance; Project Scope Boundaries; Data Replication; Chapter 13 — Consistency and Lineage.

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

DAMA-DMBOK2 recommends an incremental implementation strategy for Data Governance because governance introduces changes in accountability, decision rights, standards, processes, and organizational behaviour. Attempting an enterprise-wide implementation immediately creates unnecessary cultural and operational risk.

The implementation guidance is explicit that most governance rollout strategies are incremental, commonly beginning with a significant initiative such as Master Data Management or with a particular region, business unit, or domain. Enterprise-wide deployment as the initial step is described as uncommon.

Incremental implementation provides several control advantages. The organization can validate roles and decision mechanisms, establish stewardship practices, prove business value, refine policies, develop metrics, and correct weaknesses before expanding the governance framework. This aligns closely with Data Quality management, where organizations normally prioritize Critical Data Elements and high-value domains rather than attempting to measure and remediate every data element simultaneously.

Executive sponsorship is important, but a mandate alone does not produce sustainable adoption. Likewise, individual leadership charisma cannot substitute for operating processes, accountability, metrics, and change management. A short consultant-driven exercise also conflicts with DAMA's treatment of governance as an ongoing organizational capability.

Incremental rollout therefore offers the strongest mechanism for embedding governance permanently while demonstrating measurable value.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Implementation Guidelines; Organization and Culture; Adjustment and Communication; Chapter 13 — Data Quality Improvement and Governance.

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

This is two-factor authentication (2FA). Authentication factors are distinguished by the type of evidence used to verify identity. A username identifies the account but does not constitute a separate authentication factor. The password represents something the user knows, while the code generated or delivered through an authentication application represents something the user has. Because two different factor categories are involved, the mechanism is two-factor authentication.

DAMA-DMBOK2 discusses multiple-factor identification as a security control for systems containing sensitive information. Its examples include a code returned to a user's mobile device, possession of a hardware device, and biometric factors such as fingerprints or facial recognition. DMBOK2 specifically notes that two-factor identification makes unauthorized account access substantially more difficult.

Three-factor authentication would require a third independent category, typically something the user is, such as a biometric characteristic. The mere fact that a username, password, and code are entered does not create three factors because the username is an identifier rather than authentication evidence.

From a Data Quality perspective, strong authentication protects integrity by reducing the risk that unauthorized users alter governed data, quality rules, metadata, or master records.

Reference Topics: DAMA-DMBOK2 Chapter 7 — Authentication; Multiple-Factor Identification; Authorization; Data Security; Data Integrity.

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

The primary issue is Data Integrity, specifically referential integrity. The Orders record references a Customer_ID that does not correspond to an existing Customer record, meaning the relationship defined by the data model has been violated.

Integrity concerns whether structural relationships and constraints among data elements remain valid. In relational environments, this commonly includes primary-key uniqueness, foreign-key relationships, mandatory relationships, and cardinality constraints.

A customer identifier could be syntactically valid and populated, yet still fail integrity because no corresponding parent entity exists. This illustrates why integrity is different from completeness or validity. The DMBOK2 dimension model explicitly associates integrity with unique identifiers, cardinality, and referential integrity concepts.

Remediation should determine why the orphan record occurred. Potential causes include incorrect load sequencing, deletion of the parent record, integration failure, transformation defects, or absence of database constraints.

Metadata and Data Modeling establish the expected relationship; Data Quality controls then measure whether operational data conforms to it.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Data Integrity; Referential Integrity; Chapter 5 — Relationships and Keys; Data Integration Controls.

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

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.

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

The conventional flow is Extract, Transform, and Load (ETL). Data is extracted from source systems, placed in a staging environment where required transformations are performed, and then loaded into the target Data Warehouse. Consequently, the transformed staging data is made ready and loaded into the Data Warehouse. DAMA-oriented training material presents this exact progression.

The staging area provides a controlled environment in which source data can be integrated without imposing transformation workloads directly on operational systems. Typical activities include datatype conversion, standardization, code translation, matching, deduplication, validation, derivation, consolidation, and handling rejected records.

From a Data Quality perspective, staging is especially important because many quality controls can be applied before data reaches the analytical repository. Profiling can identify unexpected distributions, invalid values, missing records, duplicate entities, referential-integrity defects, and inconsistent reference values. Failed records can then be quarantined or remediated according to governed rules.

Although metrics and profiling may occur in staging, they are supporting activities rather than the final destination in the ETL sequence. Likewise, metadata repositories document the transformation rather than serving as the main target for the transformed business data.

Reference Topics: DAMA-DMBOK2 — Data Warehousing and Business Intelligence; ETL; Staging Areas; Data Integration; Chapter 13 — Profiling, Cleansing, Standardization and Validation.

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

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.

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

DAMA-DMBOK2 organizes Data Handling Ethics around three fundamental considerations: impact on people, potential for misuse, and the economic value of data. The text explains that data frequently represents individuals and is used in decisions that materially affect them; consequently, organizations have an ethical responsibility to ensure that data is reliable and appropriately managed. It also recognizes that data can be intentionally or unintentionally misused and that its economic value creates questions concerning ownership, access, rights, and permitted use.

These concepts directly intersect with Data Quality. Incorrect or misleading data may result in decisions that adversely affect customers, employees, patients, citizens, or other stakeholders. For that reason, accuracy, completeness, transparency, provenance, and appropriate interpretation are not merely technical characteristics—they can have ethical consequences.

Governance operationalizes these ethical principles through policies, decision rights, stewardship responsibilities, access rules, monitoring, and escalation procedures. Metadata Management supports transparency by documenting meaning, provenance, classification, and permitted use. Master Data Management also has an ethical dimension because consolidated person or customer records may create significant consequences when matching or identity-resolution errors occur.

Privacy and security are important controls, but they do not constitute DAMA's complete set of core ethical concepts.

Reference Topics: DAMA-DMBOK2 Chapter 2 — Data Handling Ethics; Impact on People; Potential for Misuse; Economic Value of Data; Chapter 13 — Accuracy, Reliability and Governance.

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