Free DAMA DQ-1220 Practice Exam with Questions & Answers | Set: 2

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.

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

A Business Continuity Plan is fundamentally concerned with maintaining essential business operations when normal services are disrupted. Therefore, the correct response is that it outlines how the business will continue operating during an unplanned disruption.

Within the DAMA-DMBOK2 framework, continuity concerns interact particularly with Data Governance, Data Storage and Operations, Data Security, and operational metadata. The DMBOK2 index explicitly identifies Business Continuity Plans and associates them with operational resilience and recovery concepts. A continuity plan must address how critical processes, information assets, personnel, technology, dependencies, and recovery arrangements will sustain or restore required business capability. The established definition of a BCP likewise centers on continued operation during unplanned service disruption.

Option E is incomplete: identifying potential disruptions belongs to risk assessment and continuity planning, but merely listing disruptions does not explain how operations will continue. Options B and D concern communications rather than continuity itself.

From a Data Quality perspective, continuity controls also protect availability, timeliness, integrity, and reliability. Recovery arrangements must ensure that restored data is complete, current enough for business use, and reconciled against authoritative sources after disruption.

Reference Topics: DAMA-DMBOK2 — Data Governance; Data Storage and Operations; Business Continuity; Disaster Recovery; Backup and Recovery; Chapter 13 — Timeliness, Integrity and Fitness for Purpose.

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

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.

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

Pname is Metadata because it is the name assigned to a database column and therefore describes the structure in which the actual Family Name values are stored. A value such as Smith or Patel would be data; Pname is structural information describing that data.

DAMA-DMBOK2 defines Metadata broadly as information about data and data-related processes. Technical metadata includes physical database characteristics such as table names, column names, datatypes, lengths, indexes, constraints, and related structural properties. The interpretation of Pname as metadata is also consistent with the published version of this exact certification question.

The fact that Pname may be an unclear abbreviation does not change its classification. It may represent a poor naming convention from a usability or governance perspective, but technically it remains metadata. A stronger physical name might be FamilyName, while the metadata repository could additionally map that field to the authoritative business glossary term.

This distinction matters to Data Quality because rules are frequently attached to metadata objects. For example, the Family Name attribute might have completeness, permitted-character, maximum-length, and standardization requirements.

Effective Metadata Management connects the technical column to its business meaning, system lineage, stewardship, and applicable Data Quality controls.

Reference Topics: DAMA-DMBOK2 Chapter 11 — Technical Metadata; Database Metadata; Business Glossary; Chapter 13 — Data Quality Rules and Metadata.

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

A high percentage of returned mail is primarily a Data Quality problem. Returned correspondence frequently results from inaccurate, incomplete, obsolete, incorrectly formatted, or otherwise unusable address data. The operational symptom therefore indicates that address information is failing to meet its intended business purpose.

Published versions of this DAMA question identify Data Quality as the intended knowledge area. The underlying principle aligns directly with DMBOK2 Chapter 13: quality is assessed relative to the requirements of the business process consuming the data.

Several quality dimensions may contribute. Accuracy concerns whether the address correctly represents the customer's actual location. Completeness concerns missing apartment numbers, postal codes, or address components. Validity evaluates whether values conform to accepted formats and domains. Currency addresses whether a previously correct address has become obsolete. Consistency can also be involved where address information differs between systems.

Reference and Master Data Management may provide customer-master consolidation and standardized geographic reference values, but the direct defect represented by returned mail is poor-quality address data.

A mature response should involve profiling returned-mail records, determining defect patterns and root causes, establishing address-quality rules, correcting affected records, and introducing preventive validation at capture.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Fitness for Purpose; Accuracy; Completeness; Validity; Currency; Profiling; Root-Cause Analysis.

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

Source-to-target mapping enables Transformation. DAMA-DMBOK2 treats mapping as closely synonymous with transformation because a mapping defines how data in one source structure will be converted into the structure, format, representation, or value required by the target.

A mapping specification typically identifies the source attribute, target attribute, extraction conditions, target population rules, intermediate staging transformations, calculations, lookup requirements, and any changes required to make the source data conform to the target representation. DMBOK2 specifically explains that mapping sources to targets involves defining the rules for transforming information from one location and format into another.

Extraction simply retrieves data from the source. Loading places data into the target. Transformation is the activity that applies structural, syntactic, semantic, or value-level modifications between those stages.

The Data Quality connection is substantial. Mappings may standardize dates, convert units, harmonize codes, resolve reference values, remove duplicates, or enforce business rules. If mapping metadata is incomplete or incorrect, the transformation process can introduce rather than correct quality defects.

For this reason, source-to-target mapping should be governed, version-controlled, documented as metadata, traceable through lineage, and validated against agreed business definitions and Data Quality requirements.

Reference Topics: DAMA-DMBOK2 Chapter 8 — Map Data Sources to Targets; Transformation; ETL/ELT; Metadata Lineage; Chapter 13 — Data Cleansing and Standardization.

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

The organization should determine the root cause and authoritative remediation point before multiple teams independently modify downstream copies.

If a defective value originates in a source system and is distributed to five downstream applications, correcting those five copies independently may provide temporary relief but leaves the upstream defect intact. The incorrect value may simply be redistributed again.

Lineage should be used to trace the defect through source systems, transformations, integration layers, Master Data hubs, warehouses, and reports. Once the origin is understood, governance can determine which system or process is authoritative and where correction should occur.

This approach minimizes inconsistent local fixes and reduces the risk that different teams apply incompatible interpretations of the same issue.

DAMA's Chapter 13 revision explicitly strengthens the relationship between Data Quality and Metadata Management, Reference/Master Data Management, Modeling, and Data Integration. Those connections are precisely what enable cross-system issue resolution.

Downstream correction may still be required after the authoritative source is fixed, but it should be coordinated.

Reference Topics: DAMA-DMBOK2 Chapter 13 — Root-Cause Analysis; Issue Management; Metadata Lineage; Authoritative Sources; Data Integration.

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

A business-data-driven roadmap translates the desired enterprise data architecture into an executable sequence of initiatives. DAMA-DMBOK2 explains that business capabilities consume and produce data, which creates dependencies between capabilities. The roadmap begins with relatively independent capabilities and progresses toward capabilities whose execution depends on data generated elsewhere. The architecture therefore establishes a coherent dependency chain before implementation work is organized.

The decisive final planning action is to turn that dependency sequence into implementable projects. Consequently, establishing the sequence of projects that will establish the data value chain is the best answer. Describing the data value chain, analysing data flows, identifying dependency challenges, and resequencing capabilities are analytical steps that precede portfolio sequencing.

DMBOK2 states that the roadmap should move from capabilities with the least dependency toward those with progressively greater dependencies, thereby providing the implementation order. It also emphasizes integrating the Enterprise Data Architecture roadmap with enterprise milestones, resources, and business-capability workstreams.

From a Data Quality perspective, sequencing matters because upstream master and reference data must reach an acceptable quality state before downstream transactional processes can depend on it.

Reference Topics: DAMA-DMBOK2 Chapter 4 — Data Architecture; Develop a Roadmap; Data Dependencies; Data Value Chain; Chapter 13 — Data Quality and other Knowledge Areas.

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

An effective Data Governance communication program should employ multiple complementary communication mechanisms, making All answers correct. Governance changes how people define, create, use, approve, and resolve issues with data; consequently, sustained adoption requires more than publishing policies.

Regular newsletters keep stakeholders aware of progress, decisions, metrics, and upcoming activities. A Data Governance Portal provides a persistent location for policies, standards, stewardship information, glossaries, issue processes, and supporting materials. Custom training develops the capabilities required for individuals to understand their specific governance responsibilities. Informal networking events help establish relationships across business and technical groups, which is particularly important when resolving data ownership and definition conflicts.

DAMA-DMBOK2 treats communication and organizational change as core implementation considerations because governance depends on participation across functions rather than on a single technical team. Published CDMP material for this item identifies the combined response—newsletters, portal, training, and networking—as the intended answer.

For Data Quality, communication ensures that quality definitions, issue-management procedures, stewardship responsibilities, thresholds, and remediation decisions are understood and consistently applied.

Reference Topics: DAMA-DMBOK2 Chapter 3 — Governance Communications; Organizational Change; Training; Data Governance Portal; Stewardship Engagement; Chapter 13 — Data Quality Culture.

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

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

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

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

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

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

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

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