DQ-1220 Questions and Answers

DAMA-DMBOK2 assigns primary responsibility for business glossary content to Business Data Stewards. Business Data Stewards are typically subject-matter experts who understand how data is defined, created, interpreted, and consumed within their business domain. DMBOK2 explicitly states that Data Stewards are generally responsible for business glossary content and identifies Business Data Stewards as professionals who work with stakeholders to define and control data.

A business glossary is not simply a technical dictionary. It establishes agreed business terminology, definitions, synonyms, business rules, responsible stewards, and relationships between business concepts. This makes stewardship involvement essential because definitions must reflect operational and business meaning rather than merely database structures.

Data Architects may contribute candidate definitions and structural context from subject-area and conceptual models, but they do not generally own the business meaning. Business users provide valuable input, while Coordinating Data Stewards help reconcile definitions across domains, yet the normal accountability remains with Business Data Stewards.

This relationship is particularly important for Data Quality. Quality rules depend on unambiguous definitions of data elements. If “Customer,” “Active Account,” or “Order Date” has inconsistent meanings, measurements of completeness, accuracy, and validity cannot be consistently interpreted.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Develop a Business Glossary; Business Data Stewardship; Metadata Management; Chapter 13 — Data Quality Rules and Business Definitions.

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

DAMA-DMBOK2 explicitly identifies a core goal of Reference and Master Data Management as ensuring that shared Master and Reference Data is complete, consistent, current, and authoritative across organizational processes.

Complete means required shared entities and attributes are sufficiently populated for their intended use. Consistent means equivalent data has compatible meaning and representation wherever it is consumed. Current means the information reflects an acceptably recent state. Authoritative means the organization recognizes a trusted source or governed process for determining the accepted value.

These characteristics are particularly important because Master and Reference Data is reused widely. An incorrect Product classification, Customer identifier, Country code, or Supplier status can therefore propagate defects across many systems and business processes.

DAMA also emphasizes that shared Master and Reference Data belongs to the organization rather than to a single application or department. This creates a strong requirement for enterprise stewardship and governance.

Reference and Master Data Management consequently interacts directly with Chapter 13. MDM can consolidate and distribute shared data, but it does not guarantee quality automatically. Matching, survivorship, validation, standardization, stewardship, and continuous monitoring are required to ensure the resulting records remain trustworthy.

Reference Topics: DAMA-DMBOK2 Chapter 10 — Reference and Master Data Management Goals; Shared Data; Authoritative Sources; Stewardship; Chapter 13 — Completeness, Consistency and Currency.

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

Integrated strategic reviews provide the strongest mechanism for managing a Data Architecture roadmap because the roadmap must remain synchronized with enterprise strategy, business capability priorities, other architecture domains, projects, resources, and changing dependencies.

DAMA-DMBOK2 describes the Enterprise Data Architecture roadmap as the three-to-five-year path by which the target architecture becomes reality. Crucially, it states that this roadmap must be integrated into the overall Enterprise Architecture roadmap, including milestones, required resources, cost estimates, and business-capability workstreams. The roadmap should also reflect business requirements, current conditions, technical assessments, and organizational maturity.

This means roadmap management cannot sensibly be reduced to a once-a-year exercise. Strategic conditions, technology decisions, project sequencing, dependencies, and regulatory requirements may change throughout the roadmap period. Integrated reviews allow those changes to be evaluated in the context of the wider enterprise architecture rather than independently.

Senior-management support is necessary for authority and funding, while peer reviews and results evaluation are useful control activities. None, however, provides the same integrated strategic mechanism for keeping architectural direction aligned with enterprise priorities.

From a Data Quality perspective, such reviews also ensure that architecture changes preserve authoritative sources, lineage, integration controls, and enterprise quality requirements.

Reference Topics: DAMA-DMBOK2 Chapter 4 — Develop a Roadmap; Enterprise Architecture Integration; Data Dependencies; Lifecycle Reviews; Architecture Governance.

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

Discovering and documenting metadata about physical data assets provides visibility into how data moves and is transformed between systems. This is a core function of technical metadata and data lineage.

DAMA-DMBOK2 states that technical metadata describes the technical characteristics of data, the systems that store it, and the processes that move it within and between systems. Examples include physical table and column names, ETL job information, source-to-target mappings, and lineage documentation with upstream and downstream impact information. The certification question therefore points directly to option D; the same interpretation is independently reflected in published CDMP-oriented material.

This capability is critical to Data Quality because a defect observed in a report or downstream application may not originate in the current system. It may have been introduced through extraction logic, transformation rules, reference-data conversion, aggregation, or loading.

Documented physical metadata allows analysts to trace the affected value backward, identify its source, inspect each transformation, and isolate the point at which the defect occurred. It also supports change-impact analysis: modifying a source field or mapping can reveal which downstream assets may be affected.

Metadata therefore provides the evidence required for systematic root-cause analysis rather than symptom-based correction.

Reference Topics: DAMA-DMBOK2 Metadata Management — Technical Metadata; Source-to-Target Mapping; Data Lineage; Data Integration and Interoperability; Chapter 13 — Root-Cause Analysis and Quality Monitoring.

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

The appropriate dimension is Reasonableness. A value may comply with technical and business-domain constraints while still being implausible in its operating context. An individual customer purchasing 750,000 office chairs is technically possible, but it is sufficiently unusual that it should trigger review.

Reasonableness controls evaluate whether values and combinations of values fall within credible expectations. These controls often depend on business context, historical behaviour, peer comparisons, statistical limits, or relationships between multiple fields.

The current DMBOK2 revision standardizes the term Reasonableness within its nine standard dimensions. The broader DMBOK2 dimension framework links reasonableness to whether data should be regarded as credible within the operational context.

Useful controls might compare order quantity against customer type, historical maximums, product availability, typical basket size, or statistical deviation from normal purchasing behaviour.

Reasonableness rules are especially valuable for identifying errors that conventional validation cannot detect. However, unusual data should not automatically be treated as incorrect; it should usually be flagged for investigation.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Reasonableness; Statistical Validation; Exception Detection; Business Rules.

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

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 mechanism is designed to meet confidentiality and privacy requirements. Customer bank-account details constitute sensitive financial information. Inspecting outgoing email for such values is a form of Data Loss Prevention control intended to identify or prevent inappropriate disclosure before sensitive information leaves the organization's controlled environment.

DAMA-DMBOK2 treats confidentiality and privacy as fundamental Data Security requirements. Its electronic-communication guidance warns that restricted or confidential information should not be sent through insecure communication channels because messages can be intercepted, forwarded, or otherwise disclosed after leaving the sender's control. DAMA International's own privacy practices likewise classify bank-account and similar financial information as protected personal/financial data requiring security safeguards against unauthorized disclosure.

The other responses concern transparency, definitions, user experience, or availability and do not address the security objective demonstrated in the scenario.

Data Governance determines the classifications and policies governing such information; Metadata Management can record sensitivity classifications against physical data elements; and security technology then enforces the resulting controls.

Data Quality remains relevant because confidentiality controls must distinguish genuinely sensitive values accurately. Poor classification or inaccurate detection rules may either expose protected information or unnecessarily block legitimate communication.

Reference Topics: DAMA-DMBOK2 Chapter 7 — Confidentiality and Privacy; Electronic Communication Security; Sensitive Data; Data Loss Prevention; Data Governance.

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

Within DAMA-DMBOK2, establishing a Data Architecture practice is divided into several complementary workstreams. The Results workstream is specifically responsible for producing Data Architecture artifacts within an overall roadmap. The other answer choices correspond to different aspects of the architecture practice rather than to the Results workstream itself.

DMBOK2 distinguishes the workstreams clearly: Strategy selects frameworks and develops the roadmap; Acceptance and Culture addresses awareness and behavioural change; Organization assigns architecture accountability and responsibility; Working Methods establish practices and coordinate architecture work with development initiatives; and Results produces the architectural artifacts that collectively realize the roadmap.

Typical artifacts include enterprise data models, high-level data-flow designs, architectural standards, transition-state specifications, and related metadata. These artifacts represent both current and target architectural states and allow individual projects to align with enterprise direction.

The Data Quality connection is substantial because architectural artifacts identify authoritative sources, integration points, critical data flows, entities, relationships, and dependencies. Those structures provide the context needed to establish validity, integrity, consistency, lineage, and quality-monitoring requirements.

Reference Topics: DAMA-DMBOK2 Chapter 4 — Establish Data Architecture Practice; Results Workstream; Data Architecture Artifacts; Architecture Roadmap; Chapter 13 — Data Quality Dependencies.

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

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.

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

The immediate requirement is Business Glossary governance. The issue is semantic: two departments use the same term but assign different meanings to it.

A governed business glossary establishes agreed terminology, definitions, synonyms, related concepts, ownership, and usage context. Resolving the definition does not necessarily mean forcing every business process to use one operational rule; there may be legitimate variants. The critical requirement is that those variants be explicitly named and documented so consumers understand the distinction.

Metadata Management provides the structures needed to preserve and distribute these definitions. DAMA's public Metadata Management guidance identifies business glossaries and data dictionaries as core mechanisms for improving shared understanding.

This semantic clarity is fundamental to Data Quality. A completeness or accuracy score for "Active Customer" is meaningless if departments measure different populations under the same label.

After the definition is governed, technical metadata should link the glossary concept to physical fields, calculations, reports, and quality rules.

Reference Topics: DAMA-DMBOK2 — Business Glossary; Metadata Management; Data Stewardship; Semantic Consistency; Data Quality Rules.

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

The process is Survivorship. In Master Data Management, survivorship determines which value should become the preferred or authoritative representation when multiple source records contain conflicting values for the same attribute.

Rules may prioritize particular systems, use recency, trust scores, verification status, completeness, or combinations of factors. For example, a verified customer-service update might outrank an older marketing-system telephone number.

Survivorship occurs after or in conjunction with matching and entity resolution. The organization first determines that records from different sources represent the same real-world customer and then determines which attribute values should populate the mastered representation.

The process requires governance because the "best" value is a business decision, not merely a technical one. Data Stewards should approve the rules, and metadata should record source priority, rule logic, and lineage.

DAMA's framework positions Reference and Master Data Management as the discipline responsible for ensuring consistent core entities across the organization.

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

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

DAMA-DMBOK2 establishes the guiding principle that Big Data management requires more discipline than relational data management. The reason is not simply data volume. Big Data environments combine large volumes with substantial variation in structure, source, velocity, semantics, and reliability. These characteristics increase the probability of uncontrolled duplication, inconsistent interpretation, poor provenance, inappropriate use, and undetected quality defects. DAMA's Big Data guidance specifically emphasizes disciplined management of metadata describing Big Data sources, their origins, and their value.

From a Data Quality perspective, scale does not make data fit for purpose. Large datasets still require defined quality expectations, profiling, monitoring, lineage, controlled transformations, ownership, and governance. Metadata becomes particularly important because analysts must understand where datasets originated, how they were transformed, their meaning, and whether they are appropriate for a particular analytical objective.

Data Governance must consequently establish accountability, acceptable-use policies, security requirements, quality expectations, and escalation mechanisms. Statistical and automated controls are also essential because manual inspection becomes impractical at Big Data scale.

Neither larger budgets nor data-science certification substitutes for sound data-management discipline. Likewise, reducing controls because data is large creates greater—not lower—operational and analytical risk.

Reference Topics: DAMA-DMBOK2 — Big Data and Data Science; Big Data Management Principles; Metadata Management; Data Governance; Chapter 13 — Fitness for Purpose and Data Quality Controls.

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

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.

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

The broad role of Metadata is to help organizations understand their data, systems, and workflows. Metadata provides the context required to interpret data correctly and connect business meaning with technical implementation and operational processing. This answer is also explicitly identified in DAMA-oriented certification material.

Business metadata explains concepts, definitions, rules, ownership, stewardship, and terminology. Technical metadata describes tables, columns, datatypes, interfaces, transformations, and system structures. Operational metadata captures information about processing, execution, schedules, and usage. Together, these categories explain what information means, where it resides, how it moves, and how it is used.

Metadata can certainly improve decision-making, support Big Data solutions, group concepts, and assist reporting, but those are secondary outcomes. Option C expresses its enterprise-wide role most comprehensively.

Its connection to Data Quality is fundamental. Quality cannot be assessed consistently without metadata explaining the intended meaning and acceptable characteristics of a data element. Lineage allows a defect to be traced to its origin, while business definitions establish the context for accuracy and validity measurements.

Reference Topics: DAMA-DMBOK2 Metadata Management — Business, Technical and Operational Metadata; Data Lineage; Business Glossary; Chapter 13 — Data Quality Rules and Metadata Dependencies.

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

Remediation should principally be prioritized according to business impact and risk. Not all defects have equivalent consequences, even when they occur at similar frequencies.

A defect affecting regulatory reporting, customer payments, safety-critical operations, executive reporting, or high-value master data may require immediate remediation. A larger number of defects affecting a low-impact optional field may legitimately receive lower priority.

A robust prioritization model may consider financial loss, regulatory exposure, operational disruption, customer impact, reputational damage, number of dependent systems, recurrence rate, remediation cost, and whether a Critical Data Element is involved.

This risk-based approach prevents Data Quality programs from becoming simple defect-count reduction exercises. The objective is not merely to maximize the number of corrected records but to improve fitness for purpose where poor data creates material consequences.

Governance should approve prioritization criteria and resolve conflicts where different business areas assign different importance to the same issue. Metadata and lineage provide evidence about downstream dependencies and affected processes.

DAMA's revision of Chapter 13 adds a clearer Critical Data Element concept and clarifies responsibility within the Data Quality Improvement Lifecycle, reinforcing risk-based prioritization.

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

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

A complete absence of reported issues immediately after introducing an enterprise Data Issue process is more likely to indicate lack of confidence in the governance process than genuinely flawless enterprise data. The certification material explicitly identifies lack of credibility in the process's ability to effect change as the plausible explanation.

Effective issue management depends on organizational trust. Employees need to believe that documenting an issue will lead to triage, ownership, escalation, root-cause investigation, remediation, and appropriate communication. If previous problems disappeared into a queue without action—or if raising defects creates organizational friction—users may simply stop reporting them.

DAMA-DMBOK2 treats Data Governance implementation as an organizational-change challenge rather than a purely procedural exercise. Governance must demonstrate authority, responsiveness, transparency, and measurable outcomes to establish credibility.

For Data Quality, issue volumes must also be interpreted carefully. “Zero issues reported” is not equivalent to “zero defects.” Complementary evidence should come from profiling, automated monitoring, quality metrics, user feedback, reconciliation, and operational outcomes.

Management should investigate reporting barriers, communicate resolved cases, establish clear escalation paths, and demonstrate that identified problems produce tangible improvements.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Governance Adoption and Credibility; Data Issue Management; Chapter 13 — Issue Identification, Escalation, Root-Cause Analysis and Remediation.

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

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.

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

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.

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

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 critical wording is “possible, but incorrect values.” This describes values that satisfy basic syntactic or domain validation—they look like legitimate dates—but do not accurately represent the real-world attribute defined by the field.

If two systems contribute data and one maps marriage date into the birth-date field, the resulting values can be perfectly valid calendar dates while being semantically incorrect as birth dates. This is principally an Accuracy defect, because DAMA defines accuracy in terms of how correctly data represents the real-world object or event it is intended to describe. It may also expose a consistency and integration-mapping problem between source systems. DAMA's quality framework distinguishes accuracy from completeness: data can be populated and formally valid while still being factually wrong.

Missing values would primarily produce a Completeness defect rather than populated-but-incorrect values. Two correctly mapped systems would not inherently explain the problem. An offset or technical date representation could create transformation problems, but the scenario most directly illustrates semantic mis-mapping between data elements.

The appropriate remediation is therefore not simple cleansing alone. Metadata mappings, source-to-target specifications, lineage, business definitions, and integration rules should be corrected at the root cause.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Accuracy, Completeness and Consistency; Root-Cause Remediation; Data Profiling; Metadata Management; Data Integration and Interoperability.

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

Document and Content Management focuses on information stored outside conventional relational databases, including documents, images, multimedia, email, and other semi-structured or unstructured assets. Integrating this knowledge area with Data Security therefore guides the implementation of appropriate access and authorization controls for unstructured data.

DAMA's framework treats security as a cross-cutting discipline rather than something applicable only to database tables. Organizational documents can contain personally identifiable information, intellectual property, contracts, financial records, or other confidential material and therefore require the same disciplined approach to authentication, authorization, classification, retention, and monitoring as structured data. DAMA-aligned references explicitly identify appropriate access and authorization to unstructured data as the relevant interaction between these knowledge areas.

Metadata is also important because document classifications, ownership, retention category, confidentiality level, and permitted audiences provide the information needed to enforce controls.

Option A refers to structured data and therefore misses the specific contribution of Document and Content Management. Fitness-for-purpose measurement belongs primarily to Data Quality, while data-mart privacy addresses a narrower structured analytical environment.

Reference Topics: DAMA-DMBOK2 Chapter 7 — Data Security; Chapter 9 — Document and Content Management; Unstructured Data; Access Control; Authorization; Information Classification.

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

DAMA-DMBOK2 identifies capacity, availability, cache performance, and user statistics as representative metrics captured by database-monitoring tools. Database monitoring is an operational control mechanism used by Database Administrators and platform teams to understand whether database infrastructure is available, adequately sized, responsive, and being used as expected. DMBOK2 explicitly describes monitoring tools as automating the observation of metrics such as capacity, availability, cache performance, and user statistics.

Capacity metrics indicate resource consumption and future growth requirements. Availability measures whether data services remain accessible when required. Cache-performance measures help identify inefficient access patterns and bottlenecks, while user statistics provide information about workload and database consumption.

The other choices mix design concepts, CRUD operations, or Data Quality concepts with operational monitoring measures. For example, normalization is a modelling technique rather than a routine runtime performance metric. Similarly, “create, read, update, delete” describes basic data operations rather than monitoring indicators.

Although database performance and Data Quality are distinct disciplines, poor operational performance can affect Data Quality dimensions such as timeliness and availability. Monitoring therefore supports the technical environment in which governed, reliable information is delivered to users and applications.

Reference Topics: DAMA-DMBOK2 — Data Storage and Operations; Database Operations; Capacity and Availability Management; Monitoring; Chapter 13 — Timeliness and Operational Fitness for Purpose.

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

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.

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

Compound authorization groups allow access rights from multiple groups or roles to be combined so that an individual's effective permissions can be configured with greater precision. The user may inherit one set of privileges from an organizational role, another from a functional group, and additional permissions from a specialized operational responsibility. The resulting authorization can therefore be more granular than assigning every privilege individually.

DAMA's Data Security framework separates authentication—establishing identity—from authorization, which determines what an authenticated identity is permitted to access or perform. Group-based authorization is a practical mechanism for implementing those decisions. CDMP-oriented references for this specific item identify “precisely configure an individual's access to a system” as the intended answer.

The principle must nevertheless be governed carefully. Excessive overlapping group memberships can make effective permissions difficult to review and can create segregation-of-duties conflicts. Periodic access reviews, least-privilege design, role ownership, and audit trails are therefore necessary complementary controls.

Encryption addresses confidentiality of data in transit or storage and is unrelated to how permissions are assigned. Audit preparation may benefit from structured authorization, but it is not the principal purpose.

Reference Topics: DAMA-DMBOK2 Chapter 7 — Authorization; Access Control; Least Privilege; Security Roles; Audit and Monitoring.

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

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 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.

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

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.

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

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.

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

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.

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

DAMA-DMBOK2 defines Data Governance as the exercise of authority and control over the management of data assets. This definition distinguishes governance from the operational execution of Data Management. Independent literature describing DAMA's framework uses the same core formulation, and the DAMA Wheel places Data Governance across the other knowledge areas through this authority-and-control function.

Governance establishes decision rights, accountability, policies, standards, stewardship, issue escalation, compliance expectations, and mechanisms for monitoring whether data is being managed appropriately. It determines who is authorized to make decisions and what rules must be followed; individual Data Management knowledge areas then execute the corresponding operational activities.

Option E is closer to the broad definition of Data Management, because it refers to planning, implementation, and control across the information lifecycle. Option A describes an assessment or maturity activity. Option B describes selected governance benefits rather than its definition, while option C characterizes a collection of functions.

For Data Quality, governance provides the authority needed to define critical data, approve quality requirements and thresholds, assign accountability, prioritize remediation, and enforce standards. Without this authority structure, profiling may identify defects but the organization may lack the decision mechanisms required to correct their underlying causes.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Data Governance Definition; Authority and Control; Policies and Standards; Chapter 13 — Data Quality Governance.

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

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.

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