Free and Premium DAMA DQ-1220 Dumps Questions Answers

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.

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

Option D is the strongest example because it expresses a Data Quality requirement that is specific, measurable, associated with identified data, and explicitly connected to business need. It identifies the relevant data—transaction data from satellite systems—sets a measurable timeliness threshold of 12:05 a.m., and explains the business reason: ensuring that branches have access to actual customer balances for the required operating window. Published versions of this DAMA question identify the same choice.

This is fundamentally a Timeliness rule. DMBOK2 emphasizes that Data Quality requirements should be defined according to business expectations rather than vague aspirations. A useful rule needs sufficient precision to support objective measurement, exception reporting, and remediation.

Option E captures an important quality expectation—actual customer balances—but it lacks the same precise operational threshold. Option A is a security/confidentiality requirement rather than a Data Quality rule. Options B and C primarily describe processing procedures and do not express the business-quality requirement as cleanly.

Once documented, the rule should be managed as metadata, assigned to an accountable steward, linked to its Critical Data Elements, monitored through metrics, and escalated when the specified threshold is breached.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Data Quality Requirements; Data Quality Rules; Timeliness; Measurement; Business Impact; Metadata Management.

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

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.

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

The organization should continue monitoring the quality metric. A successful remediation does not guarantee that the underlying process will remain controlled indefinitely.

Systems change, source applications are upgraded, personnel and suppliers change, reference values evolve, interfaces are modified, and business rules are revised. Any of these events can cause previously corrected defects to reappear.

A mature Data Quality lifecycle therefore treats improvement as continuous rather than as a one-time cleansing exercise. DAMA's revision of Chapter 13 specifically clarifies the Data Quality Improvement Lifecycle and links it to established continuous-improvement cycles.

Monitoring should confirm that the result remains within agreed thresholds and should provide trend information so deterioration can be detected before it creates significant business impact.

The frequency of monitoring may be reduced after a process demonstrates sustained stability, but the decision should be risk-based. Critical Data Elements generally justify stronger ongoing oversight.

The rule, threshold, owner, and measurement method should remain documented as metadata.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Monitoring; Control; Continuous Improvement; Metrics; Thresholds; Data Quality Scorecards.

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

The primary failure is Timeliness. The transaction may be completely accurate and complete, but it is not available within the period required by the consuming business process.

Timeliness evaluates whether data is available when needed for its intended use. The relevant threshold must therefore come from the business requirement rather than from an arbitrary technical target. In this scenario, the fraud-monitoring process requires the transaction within five minutes, while delivery occurs approximately nine hours later.

The root cause could exist in extraction frequency, integration queues, batch processing, network delays, source-system availability, or downstream ingestion. Lineage and operational metadata should be used to identify where the latency occurs.

Timeliness must also be distinguished from Currency. Currency asks whether information reflects a sufficiently recent real-world state; Timeliness asks whether data is delivered or available within the required period. A current transaction that arrives too late can therefore fail Timeliness even though the underlying value accurately represented reality when captured.

DAMA's revised DMBOK2 Chapter 13 recognizes both Timeliness and Currency as separate standard dimensions.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Timeliness; Currency; Data Quality Requirements; Data Integration; Operational Monitoring.

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

The failed control is principally Reasonableness. DAMA treats reasonableness as the extent to which data values or patterns conform to credible expectations. The current DMBOK2 revision recognizes Reasonableness among the standard Data Quality dimensions, alongside Accuracy, Validity, Completeness, Integrity, Uniqueness, Timeliness, Currency and Consistency.

A $100,000,000 residential electricity bill may be syntactically valid: the field may accept the number, the record may satisfy referential constraints, and the value may have arrived on time. Nevertheless, it is grossly inconsistent with the customer's historical pattern of approximately $300 per quarter. A reasonableness control would therefore compare the amount with expected ranges, historical consumption, statistical limits, peer-group distributions, or business thresholds and flag the value before billing.

This illustrates an important distinction from Accuracy. Accuracy asks whether the stored value correctly represents reality. Reasonableness asks whether the value is credible in context. The absurd magnitude itself is detectable without first obtaining an independently verified “true” bill value.

Practical controls include range checks, deviation-from-history rules, z-score/outlier detection, control limits, and exception thresholds. Such rules should be governed as metadata and owned by an appropriate Data Steward.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Data Quality Dimensions; Reasonableness; Measurement and Monitoring; Statistical Process Control; Data Quality Rules.

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

DAMA-DMBOK2 defines obfuscation or redaction as making information anonymous or removing sensitive information. The purpose is to reduce the risk that protected, confidential, or personally identifiable information can be exposed to users or processes that do not require access to the original values.

Obfuscation can involve masking, substitution, shuffling, temporal variation, partial display, or other methods that change what the recipient sees while preserving sufficient utility for the intended activity. For example, a customer-service agent may see only the final digits of an account identifier, or a development team may receive realistic but anonymized production-derived test data.

Redaction may remove information entirely from a representation when there is no legitimate requirement to expose it.

The technique is therefore a Data Security and privacy control, not database compression, publication, or classification.

There is also an important Data Quality consideration. Masked or obfuscated data used for testing must remain structurally valid and retain required relationships so that applications behave realistically. Metadata should indicate that a dataset has been transformed for privacy purposes so consumers do not mistake masked values for authoritative production data.

Reference Topics: DAMA-DMBOK2 Chapter 7 — Obfuscation; Redaction; Data Masking; Privacy; Sensitive Information; Chapter 13 — Fitness for Purpose and Controlled Transformation.

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

A Data Lineage tool provides the capture and maintenance of source structures for each attribute on the data model. Lineage connects modeled data elements to their originating structures and records how those elements move and transform through downstream systems. DAMA-related practice material identifies this specific capability as the correct function of lineage tooling.

At attribute level, lineage may identify a source table and column, transformation logic, staging structures, intermediate mappings, target columns, and ultimately the report or analytical object in which the value appears. This information allows organizations to answer fundamental questions such as: Where did this value originate? What transformations were applied? Which systems depend on this field? What downstream assets will be affected if its definition changes?

For Data Quality, lineage is a critical diagnostic capability. If a value becomes inaccurate after a transformation, lineage helps isolate the point of failure and distinguish source-system defects from integration or reporting defects. It also supports impact analysis before quality-rule changes are deployed.

Metadata Management normally provides the repository and technical structures that preserve lineage. Governance establishes ownership and documentation standards, while Data Stewards use lineage to understand business impact and coordinate remediation.

The other choices do not describe recognized lineage functions.

Reference Topics: DAMA-DMBOK2 — Metadata Management; Data Lineage; Data Architecture; Source-to-Target Mapping; Chapter 13 — Issue Investigation and Root-Cause Analysis.

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

The correct answer is storage is cheap and easily expanded. DAMA-DMBOK2 discusses retention and disposal as important lifecycle-management responsibilities. Although information that no longer provides business, legal, regulatory, historical, or evidentiary value should normally be disposed of according to approved retention policies, organizations often postpone disposal because modern storage appears inexpensive and technically easy to expand.

This reasoning is deceptive. The acquisition cost of storage is only one component of total information-management cost. Retaining unnecessary information also increases backup requirements, recovery time, discovery obligations, privacy exposure, security risk, metadata-management effort, migration complexity, and the volume of information that must be governed. DMBOK2 therefore stresses that non-value-adding information should not be retained merely because storage capacity is readily available.

From a Data Quality perspective, excessive retention also increases the population of obsolete, redundant, and potentially inconsistent information. This makes profiling, lineage analysis, master-data reconciliation, and authoritative-source identification more difficult.

A sound governance program consequently combines retention schedules, legal requirements, metadata classification, defensible disposal procedures, and clear accountability so that data is retained for legitimate reasons rather than technological convenience.

Reference Topics: DAMA-DMBOK2 — Document and Content Management; Retention and Disposal; Information Lifecycle; Data Governance; Chapter 13 — Data Quality and Obsolete Data.

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

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.

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

In DAMA terminology, stewardship is based on the established concept of managing an asset on behalf of another party. DAMA-DMBOK2 defines the underlying term directly: “A steward is a person whose job it is to manage the property of another person.” It then applies that concept specifically to data: Data Stewards manage data assets on behalf of others and in the best interests of the organization.

A Data Steward is therefore much more than a stakeholder or sponsor. Stewardship carries explicit operational accountability. Typical responsibilities include defining and clarifying business data, participating in issue resolution, supporting standards and policies, establishing quality requirements, approving metadata definitions, and ensuring governance decisions are applied within the steward's data domain.

The relationship to Data Quality is particularly important. DMBOK2 identifies Data Stewards as participants in identifying and resolving data-related issues and in ensuring governance policies are followed. They frequently establish or approve Critical Data Elements, Data Quality rules, acceptable thresholds, business definitions, and remediation priorities. Metadata Management records those definitions and rules, while Master Data Management applies stewardship decisions to shared entities such as Customer, Product, Supplier, or Location.

A stakeholder may have an interest in the data, and a sponsor may provide authority or funding, but neither term inherently includes stewardship accountability.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Types of Data Stewards; Stewardship; Data Quality Issue Management; Chapter 13 — Data Quality Governance and Responsibilities.

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

A strong Release Management process is critical when a Data Warehouse evolves incrementally. DAMA-DMBOK2 states directly that Release Management supports incremental development by coordinating new capabilities, enhancements, production deployment, and recurring maintenance of deployed warehouse assets.

A Data Warehouse is rarely completed in one implementation. Business requirements evolve, additional subject areas are onboarded, models are extended, transformation rules change, new reports are introduced, and defects are corrected. Release Management provides the controlled mechanism for packaging these changes into predictable production increments.

This requires prioritization of the backlog, coordination between business and technical teams, regression testing, deployment control, documentation, reconciliation, and validation of new or changed data structures. Without disciplined release management, incremental development can produce incompatible transformations, unstable reports, inconsistent historical treatment, and uncontrolled changes to definitions.

Data Quality should therefore form part of each release gate. New mappings and transformations should be profiled and reconciled; quality thresholds should be retested; metadata and lineage must be updated; and known exceptions should be documented.

Agile development may be used as a delivery method, but DAMA specifically identifies Release Management as the process critical to sustaining incremental warehouse evolution.

Reference Topics: DAMA-DMBOK2 Data Warehousing and Business Intelligence — Maintain Data Products; Release Management; Incremental Development; Chapter 13 — Quality Monitoring and Change Control.

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

Effective security risk reduction begins by understanding what data exists, how sensitive or critical it is, and where it resides. A classification model provides this foundation by classifying data concepts according to protection requirements and linking those concepts to their physical implementations. The certification material reflects this DAMA principle directly.

Data cannot be protected proportionately if the organization does not know whether it represents public information, internal operational information, personally identifiable information, financial data, intellectual property, regulated information, or another sensitive category. Classification allows the organization to apply appropriate controls according to risk rather than treating every data asset identically.

Once classification is established, security teams can define access requirements, encryption needs, monitoring, retention controls, masking, authorization policies, and other safeguards. Metadata is essential because classifications must ultimately be connected to actual databases, files, attributes, interfaces, and repositories.

A firewall alone does not provide data-level protection, and role classification by itself addresses only one dimension of security. Similarly, an Enterprise Data Model describes organizational data structures but does not replace security classification.

Reference Topics: DAMA-DMBOK2 Chapter 7 — Data Security; Data Classification; Risk Reduction; Sensitive Data Discovery; Metadata Management; Chapter 13 — Integrity and Controlled Use.

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

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.

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

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.

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

Although Data Lakes and Data Warehouses have materially different architectures, both support the broader objective of making organizational data available for reporting, analysis, analytics, and decision support. Therefore, option B identifies their legitimate conceptual overlap.

A traditional Data Warehouse generally contains integrated, curated, structured data designed for repeatable Business Intelligence, reporting, and analytical workloads. A Data Lake typically retains larger volumes of raw or less-structured information and supports flexible processing, exploration, Data Science, and advanced analytics. Both can therefore participate in analytical data pipelines even though their approaches to schema, transformation, governance, and consumption differ.

They do not inherently duplicate every item of operational data. Nor must a Data Lake produce dimensional or star-schema models; that modeling approach is more closely associated with traditional warehouse implementations. Governance is required for both rather than being the defining difference between them.

From a Data Quality standpoint, warehouses typically apply substantial cleansing and conformity before consumption. Lakes may retain raw values and defer interpretation, which increases the importance of metadata, provenance, cataloging, profiling, and consumer awareness.

Reference Topics: DAMA-DMBOK2 — Data Warehousing and Business Intelligence; Big Data; Data Lakes; Analytical Data; Metadata; Chapter 13 — Data Preparation and Fitness for Purpose.

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

The correct answer is Data models. DAMA-DMBOK2 explicitly explains that data models and other Data Architecture artifacts are commonly created or captured within development projects and are subsequently standardized and managed by Data Architects.

Development projects routinely produce conceptual, logical, and physical representations of the data required by a solution. If each project develops those structures independently without architectural review, inconsistent terminology, duplicated entities, conflicting definitions, and incompatible relationship structures can accumulate across the enterprise. Data Architects therefore review project models, reconcile them with enterprise standards, and identify structures suitable for reuse.

An Enterprise Data Model is itself an important architectural artifact, but the wording of the question refers specifically to artifacts typically generated in individual development projects and later standardized. The DMBOK2 passage uses data models in precisely that context.

This process has a direct Data Quality benefit. Standardized models improve consistency of definitions, domains, keys, relationships, and constraints. They also provide metadata from which integrity, uniqueness, validity, and completeness rules can be derived.

Reference Topics: DAMA-DMBOK2 Chapter 4 — Data Architecture; Architectural Artifacts; Development Projects; Chapter 5 — Data Modeling and Design; Chapter 13 — Consistency and Integrity.

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

DAMA-DMBOK2 defines Data Stewardship in terms of accountability and responsibility for data and for the processes that ensure its effective control and use. The wording in option E closely matches the DMBOK2 definition: stewardship describes accountability and responsibility for data and processes that ensure the effective control and use of data assets.

Stewardship may be formalized through named positions or responsibilities embedded within existing business roles. Its practical scope commonly includes managing business terminology, defining valid values and business rules, establishing or approving Data Quality requirements, resolving data issues, applying standards, and supporting governance decisions.

Option C is too narrow and also confuses stewardship with the broader policy-setting responsibilities of Data Governance. Stewards participate in developing and implementing policies and standards, but stewardship is not merely a policy-creation role. Similarly, it is not a privacy technology function or a project-management construct.

Within Data Quality Management, Data Stewards are critical because quality must be defined relative to business requirements. They help determine what “fit for purpose” means, establish acceptable thresholds, prioritize defects according to business impact, and participate in root-cause remediation.

Metadata Management records stewardship decisions, while Master Data Management uses those decisions to govern shared enterprise entities.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Data Stewardship; Steward Responsibilities; Business Glossary; Chapter 13 — Data Quality Governance and Issue Management.

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

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.

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

The integration specification requires a documented transformation rule defining how pounds are converted to kilograms.

Source-to-target mappings should identify source attributes, target attributes, transformation logic, units, datatypes, validation expectations, and handling of exceptions. Without this metadata, different interfaces could apply different conversion factors or rounding rules and create inconsistent downstream values.

The rule should specify the approved conversion factor, precision, rounding method, treatment of nulls, and any acceptable source ranges. Testing should confirm that the transformed values remain within defined quality thresholds.

This illustrates the relationship between Data Integration, Metadata Management, and Data Quality that DAMA's current Chapter 13 revision makes more explicit.

The source value may be completely accurate in pounds while the target value becomes inaccurate through faulty transformation. Therefore, quality responsibility extends beyond original data capture.

Lineage should retain both the source and transformation information so downstream analysts can understand how the kilogram value was derived.

Reference Topics: DAMA-DMBOK2 — Data Integration and Interoperability; Source-to-Target Mapping; Transformation; Metadata Lineage; Accuracy.

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

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.

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

The strongest indicator is the uncontrolled proliferation of multiple integration technologies. Enterprise integration environments often become progressively more complex when different projects independently adopt different ETL platforms, messaging products, APIs, middleware technologies, replication mechanisms, file-transfer approaches, and proprietary interfaces.

The problem is architectural fragmentation. Each integration technology introduces its own configuration methods, transformation logic, monitoring mechanisms, metadata, failure handling, security controls, support skills, and operational procedures. As the number of technologies increases, point-to-point dependencies multiply and the organization accumulates technical debt. This makes end-to-end lineage, troubleshooting, change-impact analysis, and consistent application of Data Quality rules significantly harder. The source question itself identifies this specific integration-management issue. DAMA-oriented exam material likewise identifies multiple integration technologies as the characteristic cause of an overly complex integration landscape.

DAMA-DMBOK2 therefore emphasizes managed Data Integration and Interoperability architecture, reusable patterns, common models, governed interfaces, and metadata describing transformations.

From a Data Quality perspective, uncontrolled integration technology can result in inconsistent transformations, duplicated cleansing rules, mismatched reference values, and poorly understood lineage. Standardization reduces these risks by making movement and transformation processes more transparent and governable.

Reference Topics: DAMA-DMBOK2 Chapter 8 — Data Integration and Interoperability; Integration Architecture; Metadata and Lineage; Chapter 13 — Quality Controls Across Data Movement.

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

A document-management search function depends heavily on metadata to identify, index, classify, and retrieve stored content. If known artefacts exist in the repository but cannot be found through search, inadequate or incorrectly maintained metadata is the most direct explanation.

DAMA-DMBOK2 distinguishes document content from the metadata that describes it. Typical descriptive metadata includes title, author, subject, keywords, document type, creation date, classification, and other characteristics used by retrieval mechanisms. Administrative and structural metadata may additionally support lifecycle management, versioning, access control, and relationships among document components. Without sufficiently accurate and complete metadata, the repository may physically contain a document while users remain unable to discover it.

This is also a Data Quality problem. Metadata itself is data and must satisfy quality expectations such as completeness, validity, consistency, and accuracy. A missing subject classification, incorrect document type, or inconsistent keyword convention can directly reduce findability.

Public access is neither required nor desirable for all documents, especially where confidential information exists. Business Intelligence is unrelated to basic document discovery, and Data Quality metrics alone do not make a document searchable unless the underlying metadata is correctly populated.

Reference Topics: DAMA-DMBOK2 — Document and Content Management; Metadata Management; Descriptive Metadata; Search and Retrieval; Chapter 13 — Metadata Quality and Fitness for Purpose.

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

Periodic archiving is critical for maintaining database performance. As a production CRM accumulates historical transactions, active tables and indexes can become increasingly large. This increases storage consumption, backup duration, index-maintenance overhead, and the quantity of data that database engines must process during operational queries.

DAMA-DMBOK2 treats archiving as an important Data Storage and Operations activity. Historical information that remains subject to retention requirements but is no longer frequently needed for operational processing can be moved to suitable archival storage. DAMA-aligned guidance for this scenario specifically links periodic transaction archiving with maintaining production database performance.

Archiving is not the same as arbitrary deletion. Retention policies, legal obligations, recovery requirements, auditability, and business value determine how long data must remain accessible and where it should be stored. The archive must also be recoverable and appropriately secured.

Data Quality implications include maintaining integrity and traceability during migration to the archive. Records should remain complete, relationships should be preserved, and metadata should indicate retention status and archival location.

Providing reporting sources or managing deleted customers may be secondary considerations, but neither is the principal purpose described in the question.

Reference Topics: DAMA-DMBOK2 Chapter 6 — Data Storage and Operations; Archiving; Database Performance; Retention; Chapter 13 — Integrity and Historical Data.

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

A candidate key is a minimal super key. A super key is any set of attributes sufficient to uniquely identify an entity instance, but it may contain attributes that are unnecessary for uniqueness. A candidate key removes that redundancy: if any attribute is removed from the candidate key, the remaining attributes no longer uniquely identify the entity.

DAMA-DMBOK2 makes this distinction explicitly: a candidate key is a minimal set of one or more attributes identifying an entity instance, and “minimal” means that no subset of the candidate key can perform the same unique-identification function.

Option B is incomplete because a set can uniquely identify an entity while still containing unnecessary attributes; that would qualify as a super key but not necessarily a minimal super key. A surrogate key is different: it is an artificial identifier introduced primarily for technical identification. Foreign-key composition and physical index structures likewise do not define candidate-key minimality.

This concept has direct Data Quality implications. Correctly defined candidate and primary keys support uniqueness and integrity, prevent duplicate entity instances, enable reliable referential relationships, and improve entity matching within Master Data Management. Key definitions should also be captured as structural metadata so profiling and quality rules can consistently test duplicate and orphan conditions.

Reference Topics: DAMA-DMBOK2 Chapter 5 — Data Modeling and Design; Keys; Candidate Keys; Chapter 13 — Uniqueness and Integrity; Metadata Management; Master Data Management.

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

DAMA-DMBOK2 identifies four principal types of data that may be represented in data models: Category Information, Resource Information, Business Event Information, and Detail Transaction Information. Because options A, B, C and E are all legitimate categories, All of these is correct.

Category information classifies things—for example, classifying customers by market segment or products by size or colour. Resource information represents business resources required for operations, including entities such as Customer, Product, Supplier, Facility and Account. These resource entities frequently overlap strongly with Master and Reference Data Management.

Business event information records events created during operational processes, such as orders, invoices or withdrawals. Detail transaction information represents highly granular observations, including point-of-sale records, clickstream data, social-media interactions, sensor outputs and other high-volume events.

This classification matters to Data Quality because quality controls must reflect the semantics and lifecycle of the data being evaluated. Reference and master data require strong uniqueness, definition and consistency controls; event data require integrity and timeliness; high-volume detailed data often require automated profiling and statistical monitoring.

Data models also generate important metadata—definitions, relationships, domains and constraints—which becomes the basis for measurable Data Quality rules.

Reference Topics: DAMA-DMBOK2 Chapter 5 — Types of Data that are Modeled; Chapter 10 — Reference and Master Data; Chapter 13 — Data Quality Rules and Dimensions; Metadata Management.

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

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.

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

A process can be statistically stable yet still perform at an unacceptable quality level. Statistical control means that variation is predictable within the established process; it does not mean that the average level of defects satisfies business expectations.

For example, a process may consistently produce a 3% defect rate with very little month-to-month variation. If the business requirement is below 0.5%, the process is stable but incapable of meeting the desired quality level without improvement.

The appropriate response is therefore deliberate process improvement aimed at changing the underlying process and reducing its baseline defect rate. This differs from reacting to random individual observations within normal control limits.

After improvement, new performance data should be collected and control parameters reevaluated once the revised process reaches a stable state.

DAMA's revised Chapter 13 explicitly maps Shewhart and Deming improvement-cycle stages to Data Quality processes and preserves Statistical Process Control as supporting material.

The central principle is that control and capability are different questions: control asks whether the process is stable; business quality requirements determine whether that stable performance is good enough.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Statistical Process Control; Process Stability; Continuous Improvement; Shewhart/Deming Cycle; Thresholds.

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

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.

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

The values should first be treated as potential exceptions requiring investigation. Profiling identifies anomalies; it does not automatically prove that every unusual value is incorrect or specify the appropriate remediation.

Negative age and 263 years are highly improbable for a conventional person-age attribute, suggesting a validity or reasonableness defect. However, the Data Quality team should confirm the business definition, unit of measure, derivation logic, source mappings, special-value conventions, and intended population before changing the records.

Blindly replacing values with an average introduces fabricated data and destroys traceability. Deleting the records may also remove legitimate information elsewhere in the record. Increasing the datatype range addresses technical storage rather than semantic correctness.

A disciplined Data Quality process moves from profiling to rule validation, issue assessment, root-cause analysis, remediation, and monitoring. The business rule may ultimately specify an acceptable age range, but that rule should be governed and documented rather than inferred from individual anomalies.

Metadata is essential because it should describe whether Age is stored directly, calculated from Date of Birth, or encoded using another convention.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Profiling; Validity; Reasonableness; Root-Cause Analysis; Data Quality Rules; Metadata.

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

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.

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

A meaningful Data Quality metric begins with the business requirement and intended use. Quality is fundamentally contextual: data is considered fit for purpose only relative to the activity, decision, report, or process that depends on it.

For example, a delivery address used for same-day logistics may require stricter timeliness and completeness thresholds than an address retained solely for historical analysis. Without understanding the business use, a numerical quality target becomes arbitrary.

The business requirement should identify what failure matters, which dimension applies, how quality will be measured, the acceptable threshold, who owns the requirement, and what response is expected when the threshold is missed.

DAMA-aligned public guidance follows this same logic by recommending that quality rules and dimensions be prioritized according to user needs and purpose.

Technology selection comes later. Profiling tools help measure data, but they cannot determine the business meaning of an acceptable result.

Governance and stewardship should approve the requirement, while Metadata Management should preserve the definition, rule, owner, and lineage.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Define Data Quality Requirements; Fitness for Purpose; Metrics; Thresholds; Business Rules.

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

An address beginning with HTTPS indicates that the website uses an encrypted security layer for communications between the client and server. DAMA-DMBOK2 explicitly identifies HTTPS as a security technology and states that the prefix indicates that a website is equipped with an encrypted security layer.

HTTPS uses TLS to protect information while it is transmitted across the network. Its principal security objectives include confidentiality of the communication channel, integrity of transmitted information, and authentication of the server through digital certificates. This is especially important when transmitting credentials, personal information, payment details, or other sensitive data.

HTTPS does not indicate what database technology the website uses, whether a content management system is installed, whether third-party cookies are present, or whether language-translation functionality exists. Those characteristics are independent of transport-layer encryption.

From a Data Management standpoint, encryption in transit is one component of a broader Data Security framework. Sensitive data must also be protected at rest, appropriately classified, access-controlled, monitored, and governed throughout its lifecycle.

Data Quality also benefits indirectly because integrity protection helps prevent unauthorized alteration of values during transmission.

Reference Topics: DAMA-DMBOK2 Chapter 7 — HTTPS; Encryption; Data in Transit; Authentication; Confidentiality; Integrity.

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

This is Data Enrichment. Enrichment enhances existing records by adding useful information derived from internal or external sources. The original postal address remains intact, while geographic coordinates are appended to make the customer record more useful for location analysis, logistics, service coverage, route planning, or segmentation.

Enrichment differs from cleansing. Cleansing corrects or standardizes defective data; enrichment adds information that was not previously present. A process may perform both—for example, standardizing an address before passing it to a geocoding service.

External enrichment introduces governance and quality considerations. The organization should assess source reliability, licensing and permitted usage, refresh frequency, match confidence, geographical precision, lineage, and whether enrichment values should be treated as authoritative or derived.

Metadata should record that latitude and longitude were obtained from an external geocoding process rather than directly supplied by the customer. Quality metrics may measure match rate, confidence, completeness, or positional accuracy.

DAMA identifies Data Quality Management as including error detection, cleansing, and enrichment strategies, while Metadata Management supports understanding of lineage, definitions, and usage.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Data Enrichment; Cleansing; Profiling; Metadata Lineage; External Data Sources.

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

The scenario describes a many-to-many relationship: one Person may use several Addresses, while one Address may be associated with several Persons. In relational modelling, this should be resolved using an associative entity—here, Person Address Usage—between Person and Address. The original many-to-many relationship is thereby replaced with two one-to-many relationships. DAMA-oriented references identify this approach directly under the addition of associative entities.

The associative entity normally contains foreign keys referencing both parent entities and may also contain attributes describing the association itself, such as address type, usage purpose, effective date, end date, or primary-address indicator.

Simply modifying the primary keys of Person or Address does not resolve the semantic relationship. Changing foreign-key role names also changes terminology rather than cardinality. The term “partnership entity” is not the appropriate modelling construct.

This design has important Data Quality consequences. It permits explicit integrity constraints between the association and both parent entities, prevents ambiguous repeated columns, and allows the organization to validate rules such as valid effective periods and permitted address-use types.

Reference Topics: DAMA-DMBOK2 Chapter 5 — Relationships; Cardinality; Associative Entities; Resolving Many-to-Many Relationships; Chapter 13 — Referential Integrity and Consistency.

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

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.

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