CDMP — DAMA Data Management Fundamentals Cheat Sheet

Last revised: September 16, 2026

Cheat sheet: CDMP Data Management Fundamentals reference for DAMA concepts, knowledge areas, governance, quality, metadata, architecture, and exam distinctions.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

What each data management knowledge area is responsible for.
Which artifacts, roles, and processes belong together.
How to distinguish governance, architecture, quality, metadata, MDM, integration, warehousing, and security scenarios.
Common exam traps where similar terms are intentionally contrasted.

It is IT Mastery exam-prep support and is not affiliated with DAMA International. Use it to refresh the major data management concepts, sharpen decision rules, and identify weak areas before using an original question bank for deeper practice.

Item	Detail
Provider	DAMA International
Official exam title	DAMA CDMP Data Management Fundamentals
Official exam code	CDMP
Review focus	Core data management principles, terminology, decision-making, and common exam traps
Best use	Read once, drill weak topics, review explanations, then take mixed mock exams

Core DAMA Data Management Frame

Data Management in One View

Concept	Exam-ready meaning	Common trap
Data management	Development, execution, and supervision of plans, policies, programs, and practices that deliver, control, protect, and enhance data and information assets	Not just database administration or analytics
Data as an asset	Data has value, risk, lifecycle, ownership/accountability, and quality expectations	Treating data as an IT byproduct only
Data lifecycle	Creation/acquisition, storage, use, sharing, retention, archive, disposal	Lifecycle is broader than system development lifecycle
Data management function	Cross-functional business and IT discipline	Not owned only by a central data team
Knowledge area	A discipline such as Data Governance, Data Quality, Metadata, Security, etc.	Knowledge areas overlap; they are not isolated silos
Data strategy	Direction and priorities for using data to support business goals	Not a project plan or a technology roadmap alone
Data management program	Organized capabilities, roles, policies, processes, and metrics to manage data	Not a one-time cleanup effort

Notes and examples

DAMA-Style Knowledge Areas

Knowledge area	Primary purpose	Typical artifacts	High-yield distinction
Data Governance	Authority, accountability, policy, decision rights, issue escalation	Policies, standards, stewardship model, council charters, decision logs	Sets rules and accountability; does not perform every operational data task
Data Architecture	Enterprise view of data assets and flows aligned to business strategy	Data architecture, subject-area model, data flow maps, target-state roadmap	Describes what data exists and how it should be organized across the enterprise
Data Modeling and Design	Represent data requirements and structures at conceptual, logical, and physical levels	ERDs, dimensional models, normalization design, naming standards	Modeling is about structure and meaning, not only database implementation
Data Storage and Operations	Manage physical persistence, availability, performance, backup, recovery, and operations	Database standards, operational procedures, backup/recovery plans	Focuses on running and protecting stored data assets
Data Security	Protect confidentiality, integrity, and availability through controls	Access policies, classification, encryption rules, audit logs	Security is risk-based and applies across lifecycle, not only login control
Data Integration and Interoperability	Move, combine, exchange, and synchronize data across systems	ETL/ELT design, APIs, mappings, interface specs, lineage	Integration is about consistency and movement between systems
Document and Content Management	Manage unstructured/semi-structured documents, records, and content	Taxonomies, retention schedules, content repositories, records policies	Content is not always row/column structured data
Reference and Master Data	Manage shared core entities and valid value sets	Golden records, match/merge rules, hierarchies, code sets	MDM is about core business entities; reference data is controlled value lists
Data Warehousing and BI	Support reporting, analytics, decision support, and historical analysis	Data warehouse, marts, cubes, semantic layer, reports, dashboards	Optimized for analysis, not transaction processing
Metadata Management	Manage information about data meaning, origin, rules, structure, and usage	Business glossary, data catalog, lineage, technical metadata	Metadata enables understanding, control, traceability, and reuse
Data Quality	Define, measure, monitor, and improve fitness for purpose	DQ rules, scorecards, issue logs, remediation plans	Quality depends on business use, not abstract perfection
Big Data and Data Science	Use large, varied, fast, or complex data for advanced analytics and models	Data lakes, feature sets, ML pipelines, analytic sandboxes	Adds scale/variety/analytics complexity; governance still applies
Data Management Maturity	Assess capability levels and improvement priorities	Maturity assessments, gap analysis, roadmap	Measures capability, not data quality alone
Data Management Organization and Roles	Define responsibilities, accountabilities, and operating model	RACI, role descriptions, committees, stewardship network	Organizational design supports execution of governance and management
Organizational Change Management	Drive adoption of data practices, standards, and behaviors	Stakeholder plans, communications, training, resistance management	Data initiatives fail without adoption, not just technical delivery

High-Yield Knowledge Area Map

Use this table as a fast scan before practice questions.

Area	Know the purpose	Watch for these traps
Data governance	Sets decision rights, accountability, policies, standards, and stewardship	Confusing governance with hands-on data administration
Data architecture	Aligns data capabilities, flows, stores, and standards with business needs	Jumping to platform choices before understanding requirements
Data modeling and design	Represents business concepts, relationships, rules, and structures	Mixing conceptual, logical, and physical models
Data storage and operations	Manages databases, storage, availability, backup, recovery, and operational support	Treating backup, recovery, disaster recovery, and business continuity as identical
Data security	Protects confidentiality, integrity, and availability of data	Assuming security is only encryption or only IT’s responsibility
Data integration and interoperability	Moves, shares, transforms, synchronizes, and exposes data across systems	Confusing ETL, ELT, replication, federation, APIs, and streaming
Document and content management	Manages unstructured and semi-structured information through its lifecycle	Ignoring retention, classification, search, and records controls
Reference and master data	Manages shared identifiers, codes, core business entities, and trusted records	Confusing reference data with master data
Data warehousing and BI	Supports reporting, analytics, historical analysis, and decision support	Confusing operational systems with analytical systems
Metadata management	Manages data about data: meaning, structure, lineage, usage, and operations	Treating metadata as only technical column definitions
Data quality	Measures, improves, and monitors fitness for use	Treating cleansing as the same thing as quality management
Big data and data science	Applies scalable data processing and analytic methods to high-volume or complex data	Focusing on buzzwords instead of governance, quality, ethics, and lifecycle controls

High-Yield Distinctions

Governance vs Management vs Stewardship

Term	Main question answered	Typical owner/accountable party	Example
Data Governance	Who has authority and what rules apply?	Data governance council, executives, data owners	Approving a policy that customer data must have an assigned owner
Data Management	How are data assets planned, built, operated, controlled, and improved?	Data management professionals, IT, business teams	Implementing metadata, quality monitoring, MDM, integration, storage
Data Stewardship	Who ensures rules are applied and issues are resolved for specific data?	Business or technical stewards	Reviewing DQ exceptions for customer address completeness
Data Ownership	Who is accountable for data decisions and value/risk?	Business data owner	Approving definition of “active customer”
Data Custodianship	Who technically safeguards and operates data?	IT/platform/database/security teams	Applying access controls and backups

Notes and examples

Policy, Standard, Procedure, Guideline

Artifact	Force	Purpose	Example
Policy	Mandatory, high-level	State required rule or intent	Sensitive data must be classified and protected
Standard	Mandatory, specific	Define uniform requirements	Customer identifiers must follow approved format
Procedure	Mandatory or controlled process	Explain steps to perform work	Steps to request access to restricted data
Guideline	Recommended	Provide advice or preferred practice	Suggested naming pattern for analytic data sets

Conceptual, Logical, Physical Models

Model level	Audience	Contains	Does not usually contain
Conceptual	Business stakeholders, architects	Major subject areas, entities, relationships, business vocabulary	Database columns, indexes, storage details
Logical	Data analysts, modelers, architects	Entities, attributes, relationships, keys, normalization, business rules	Platform-specific storage implementation
Physical	DBAs, engineers, developers	Tables, columns, datatypes, indexes, partitions, constraints	Purely business-only abstractions

OLTP vs OLAP

Characteristic	OLTP	OLAP / Data Warehouse
Purpose	Run business transactions	Analyze historical and integrated data
Data shape	Current, detailed, normalized	Historical, integrated, often dimensional
Workload	Inserts/updates/deletes, high concurrency	Reads, aggregations, trend analysis
Users	Operational applications, front-line users	Analysts, managers, decision makers
Design priority	Integrity and transaction performance	Query performance and usability
Example	Order entry system	Sales trend dashboard

Data Governance Cheat Sheet

Governance Components

Component	What it does	Exam clue
Data governance strategy	Sets direction, scope, outcomes, and alignment to business goals	“Enterprise approach,” “program direction,” “business alignment”
Decision rights	Defines who can approve definitions, standards, access, changes	“Who has authority?”
Data ownership	Assigns accountability for data domains or subject areas	“Accountable business role”
Stewardship	Operationalizes governance decisions and issue resolution	“Day-to-day data responsibility”
Policies and standards	Formalize expected behavior and controls	“Consistent rules”
Issue management	Captures, prioritizes, escalates, and resolves data problems	“Escalation path”
Metrics	Measures adoption, quality, compliance, and value	“How do we know it works?”
Communications	Builds awareness and adoption	“Stakeholder buy-in”

Notes and examples

Governance Operating Model Patterns

Pattern	When useful	Risk
Centralized	Strong consistency, regulated or enterprise-wide control needs	May be slow or detached from business domains
Decentralized	Business units need autonomy and local responsiveness	Inconsistent definitions and duplicated effort
Federated	Enterprise standards plus domain-level execution	Requires clear accountability and coordination
Committee/council-based	Cross-functional decisions and escalation	Can become bureaucratic without decision authority
Stewardship network	Broad operational adoption	Needs training, role clarity, and management support

Governance Scenario Decisions

Scenario	Best governance response
Different departments define “customer” differently	Establish authoritative business definition, owner, glossary entry, and usage context
Reports conflict across departments	Investigate lineage, source definitions, transformations, and calculation rules
No one approves changes to critical data definitions	Define data ownership and decision rights
Repeated unresolved DQ defects	Implement issue management, stewardship accountability, root-cause remediation
Business resists new data standards	Use change management, stakeholder engagement, and value-based communication
Sensitive data is widely accessible	Apply data classification, access policy, security controls, and monitoring

Data Architecture

Architecture Views

View	Focus	Common artifacts
Enterprise data architecture	Organization-wide data assets, subject areas, flows, and principles	Enterprise data model, capability map, data domain model
Business/data domain view	Core business concepts and their relationships	Subject-area model, canonical definitions
Application/data flow view	Movement of data between systems	Data flow diagrams, system context diagrams, interface maps
Technology/platform view	Data stores, platforms, integration tools, storage technologies	Platform architecture, deployment patterns
Target-state roadmap	Transition from current to desired capabilities	Gap analysis, migration roadmap

Notes and examples

Architecture Principles

Principle	Practical interpretation
Business alignment	Data architecture supports business strategy and capabilities
Shared data	Common data should be reusable and consistently defined
Data quality by design	Validation, controls, and ownership should be built into architecture
Metadata-driven management	Meaning, lineage, and controls should be documented and discoverable
Security and privacy by design	Protection is embedded early, not bolted on later
Lifecycle management	Retention, archive, and disposal are planned
Interoperability	Systems exchange data using agreed structures and semantics

Architecture vs Modeling vs Integration

If the question focuses on…	Think first of…
Enterprise subject areas and target state	Data Architecture
Entity attributes, relationships, keys	Data Modeling and Design
Mapping source to target and moving data	Data Integration and Interoperability
Enterprise-approved definitions	Data Governance and Metadata
Shared customer/product/vendor records	Reference and Master Data
Historical analytical store	Data Warehousing and BI

Data Architecture

Data architecture describes how data is organized, integrated, stored, shared, and governed across the enterprise.

Architecture Review Points

Concept	What to remember
Enterprise data architecture	Broad view of data domains, flows, systems, standards, and capabilities
Data domain	A major subject area, such as customer, product, supplier, employee, asset, or transaction
Data flow	Movement or sharing of data between processes, applications, stores, and users
Target architecture	Desired future-state design aligned to strategy
Current-state architecture	Existing data environment, including constraints and technical debt
Roadmap	Sequenced path from current state to target state

Common Architecture Traps

Choosing a tool before defining business requirements.
Designing only for one project rather than enterprise reuse.
Ignoring data lineage, ownership, and quality requirements.
Treating architecture diagrams as documentation only, rather than decision-support tools.
Forgetting that architecture must balance business, information, application, and technology concerns.

Data Modeling and Design

Modeling Terms

Term	Meaning	Trap
Entity	Thing of business interest	Not necessarily a physical table
Attribute	Fact or property about an entity	Should have clear definition and domain
Relationship	Association between entities	Cardinality and optionality matter
Cardinality	Number of instances that may participate	One-to-one, one-to-many, many-to-many
Optionality	Whether participation is required	Mandatory vs optional relationship
Primary key	Unique identifier for a record/entity instance	Natural or surrogate depending on design
Foreign key	Attribute referencing another table/entity key	Enforces referential integrity in physical design
Normalization	Reduce redundancy and update anomalies	Too much normalization may impair analytic usability
Denormalization	Add redundancy for performance/usability	Increases maintenance and consistency risk
Domain	Permitted set or type of values	Supports validation and consistency
Constraint	Rule enforced on data	May be business, logical, or physical

Notes and examples

Normalization Review

Normal form concept	Core idea	Typical issue prevented
1NF	Values are atomic; repeating groups removed	Multiple values in one field
2NF	Non-key attributes depend on whole key	Partial dependency on part of composite key
3NF	Non-key attributes depend only on the key	Transitive dependency
Higher forms	Address more complex dependency issues	Subtle redundancy and anomaly cases

Dimensional Modeling

Term	Meaning	Example
Fact table	Numeric measurements at a defined grain	Sales amount by order line
Dimension table	Descriptive context for facts	Date, product, customer, store
Grain	Lowest level of detail represented by a fact table	One row per order line per product
Star schema	Fact table connected to denormalized dimensions	Common BI design
Snowflake schema	Dimensions normalized into related tables	Less redundancy, more joins
Slowly changing dimension	Method for handling dimension attribute changes over time	Customer address history
Conformed dimension	Shared dimension used consistently across facts/marts	Common date or product dimension

Modeling Traps

Trap	Correct exam reasoning
Treating conceptual model as physical schema	Conceptual models communicate business meaning, not implementation details
Starting physical design before requirements	Modeling should be driven by business rules and data requirements
Assuming all redundancy is bad	Redundancy may be deliberately introduced for performance or analytics
Ignoring grain in fact design	Grain must be declared before selecting facts and dimensions
Confusing master data with dimensional data	Master data manages authoritative core entities; dimensions provide analytic context

Data Modeling and Design

Data modeling is a high-yield area because questions often test levels of abstraction, relationships, and business meaning.

Conceptual, Logical, and Physical Models

Model type	Main audience	Focus	Example content
Conceptual	Business stakeholders	Major business concepts and relationships	Customer places Order
Logical	Analysts, data modelers, designers	Attributes, relationships, business rules, normalization	Customer, Order, Order Line, Product with keys and cardinality
Physical	DBAs, engineers, platform teams	Implementation details	Tables, columns, indexes, partitions, datatypes

Decision rule: If the question emphasizes business concepts and shared understanding, choose conceptual. If it emphasizes detailed entities, attributes, and relationships independent of technology, choose logical. If it emphasizes implementation in a specific database or platform, choose physical.

Modeling Concepts to Review

Concept	Meaning	Exam cue
Entity	Thing of business interest	Customer, Product, Invoice
Attribute	Property of an entity	Customer Name, Order Date
Relationship	Association between entities	Customer places Order
Cardinality	Number of instances that can relate	One-to-many, many-to-many
Optionality	Whether relationship participation is required	Customer may have Account
Primary key	Uniquely identifies a record	Customer ID
Foreign key	References another entity’s key	Order contains Customer ID
Domain	Valid set of values	Status code list, date range, allowed category

Normalization and Denormalization

Approach	Purpose	Tradeoff
Normalization	Reduce redundancy and update anomalies	May require more joins
Denormalization	Improve read performance or simplify access	May introduce redundancy and consistency risks

Exam trap: Normalization is not automatically “better” in every context. Operational systems often benefit from normalized design; analytical systems may intentionally use dimensional or denormalized structures for query performance and usability.

Data Storage and Operations

Operational Responsibilities

Area	Focus	Examples
Database operations	Availability, performance, capacity, monitoring	Tuning, backup jobs, index maintenance
Backup and recovery	Restore data after failure or corruption	Recovery procedures, restore tests
Data retention	Keep data as long as required by policy/business need	Retention schedules, archive strategy
Archiving	Move inactive data to lower-cost or long-term storage	Historical transaction archive
Disposal	Defensible deletion at end of lifecycle	Secure deletion, disposal evidence
Performance management	Ensure workloads meet service expectations	Query tuning, resource monitoring
Data environment management	Manage development, test, production data safely	Refreshes, masking, change control

Notes and examples

Backup and Recovery Terms

Term	Meaning
Backup	Copy of data for restoration
Restore	Process of bringing backup data back into an environment
Recovery	Returning service/data to usable state after failure
RPO	Maximum acceptable data loss, expressed as time
RTO	Maximum acceptable time to restore service
Point-in-time recovery	Restore to a specific prior moment
Disaster recovery	Broader recovery of systems/processes after major disruption
Business continuity	Maintaining critical business operations during disruption

Data Storage and Operations

Data storage and operations covers the practical management of databases, storage platforms, operational support, availability, and recovery.

Core Terms

Term	Quick meaning
Database	Organized collection of data managed for access and update
DBMS	Software used to define, store, secure, query, and manage databases
Backup	Copy of data for recovery purposes
Recovery	Restoring data or service after failure
Archive	Long-term storage, often for inactive or historical data
Retention	How long data should be kept based on business and control requirements
Disposal	Controlled deletion or destruction when data is no longer needed
Availability	Ability of systems and data to be accessible when required

Backup, Recovery, DR, and Continuity

Concept	Primary concern
Backup	Having recoverable copies
Recovery	Restoring data or service after an incident
Disaster recovery	Restoring technology capability after major disruption
Business continuity	Maintaining critical business operations during disruption

Common mistake: Selecting “backup” as the complete answer when the question is about broader continuity, resilience, or recovery planning.

Data Security

Security Concepts

Concept	Meaning	Exam cue
Confidentiality	Prevent unauthorized disclosure	Sensitive data exposure
Integrity	Prevent unauthorized or improper modification	Tampering, incorrect changes
Availability	Ensure authorized access when needed	Outage, resilience, denial of service
Authentication	Verify identity	Login, identity proof
Authorization	Grant permitted actions	Roles, privileges, access rights
Least privilege	Grant only access needed	Over-permissioned users
Segregation of duties	Separate conflicting responsibilities	Avoid one person controlling entire process
Data classification	Categorize data by sensitivity/value/risk	Public, internal, confidential, restricted
Encryption	Protect data by encoding it	At rest, in transit
Masking	Obscure sensitive data, often for non-production or display	Test data, partial display
Tokenization	Replace sensitive value with non-sensitive token	Payment or identifier protection
Auditing	Track access and changes	Evidence, monitoring, compliance support

Notes and examples

Security Control Types

Control type	Purpose	Examples
Preventive	Stop unwanted event	Access control, encryption, input validation
Detective	Identify event after or during occurrence	Logging, monitoring, anomaly detection
Corrective	Restore or remediate	Incident response, restore, patching
Administrative	People/process rules	Policies, training, procedures
Technical	Technology-enforced controls	IAM, database permissions, encryption
Physical	Facility/media protection	Locked rooms, secure disposal

Security Decision Points

Scenario	Likely control
Users should see only data for their region	Role-based or attribute-based access control
Developers need production-like data without sensitive values	Data masking or synthetic data
Data moves between systems	Encryption in transit and secure interface controls
Data stored in a database contains sensitive fields	Encryption at rest, column-level controls, access restrictions
Need evidence of who changed data	Audit logging and change tracking
Business must know sensitivity before applying controls	Data classification

Data Security

Data security protects data from unauthorized access, misuse, alteration, disclosure, or loss.

Security Principles

Principle	Meaning	Example
Confidentiality	Only authorized users can access data	Access controls, encryption, masking
Integrity	Data is accurate, complete, and not improperly altered	Validation, checks, audit trails
Availability	Data is accessible when needed	Resilience, monitoring, recovery planning
Least privilege	Users get only the access needed	Role-based access
Defense in depth	Multiple complementary controls	Network, application, database, identity, monitoring

Security Controls to Distinguish

Control	Purpose
Authentication	Verifies identity
Authorization	Determines allowed actions
Encryption	Protects data confidentiality by encoding it
Masking	Hides sensitive values from users or environments
Tokenization	Replaces sensitive values with substitute tokens
Auditing	Records activity for monitoring and investigation
Classification	Labels data based on sensitivity, value, or handling needs

Exam trap: Security is not only a technical function. Governance defines policies and accountability; security teams and custodians implement controls; data owners help determine classification, sensitivity, and acceptable use.

Data Integration and Interoperability

Integration Patterns

Pattern	Best for	Watch for
Batch ETL	Scheduled movement and transformation before loading	Latency, reconciliation
ELT	Load first, transform in target platform	Governance and target platform capacity
Real-time/event streaming	Low-latency event processing	Ordering, replay, monitoring, schema evolution
API-based integration	Controlled service-to-service exchange	Versioning, security, throttling, contract management
Data replication	Copy/sync data between stores	Consistency, conflict handling
Virtualization/federation	Query data without physically moving it	Performance, source availability, semantic consistency
Messaging/queueing	Decoupled asynchronous exchange	Delivery guarantees, idempotency

Notes and examples

Integration Artifacts

Artifact	Purpose
Source-to-target mapping	Defines how fields transform from source to destination
Interface specification	Describes exchange structure, format, protocol, frequency
Data contract	Agreed expectations for data structure, semantics, and changes
Transformation rules	Business/technical logic applied during movement
Reconciliation report	Confirms completeness and consistency after transfer
Lineage documentation	Tracks origin, movement, and transformation of data
Error handling rules	Define rejects, retries, exception management

Integration Traps

Trap	Correct reasoning
Assuming integration fixes data quality	Integration can expose or move poor-quality data; quality rules and ownership are still needed
Ignoring semantic differences	Same field name may mean different things across systems
No lineage for transformed data	Users cannot trust reports if origin and transformations are opaque
Treating APIs as only technical	APIs require contracts, governance, security, and lifecycle management
Duplicating data without synchronization rules	Copies diverge unless ownership and update rules are clear

Data Integration and Interoperability

Integration enables data to move between applications, databases, platforms, partners, reports, and analytics environments.

Integration Pattern Review

Pattern	Best fit	Watch out for
ETL	Transform before loading into target	Batch-oriented; transformation happens before load
ELT	Load first, transform in target platform	Often used with scalable analytical platforms
API	Controlled application-to-application access	Requires interface design, security, versioning
Messaging	Event or message exchange between systems	Useful for decoupling systems
Streaming	Near-real-time event processing	Requires attention to latency, ordering, and reliability
Replication	Copies data between environments	Does not automatically resolve meaning or quality issues
Change data capture	Captures changes from source systems	Useful for incremental movement
Data virtualization/federation	Accesses data without physically moving all of it	Performance, governance, and consistency must be considered

Integration Decision Rules

If the issue is meaning, resolve definitions and metadata before building pipelines.
If the issue is timeliness, compare batch, near-real-time, and streaming needs.
If the issue is reuse, consider shared services, APIs, canonical models, and standards.
If the issue is trust, include quality checks, lineage, reconciliation, and monitoring.
If the issue is sensitivity, include classification, access controls, encryption, and masking.

Document and Content Management

Structured vs Semi-Structured vs Unstructured

Data type	Description	Examples	Management focus
Structured	Organized in defined schema	Relational tables, coded fields	Modeling, integrity, query performance
Semi-structured	Has tags/markers but flexible schema	XML, JSON, emails with metadata	Parsing, schema evolution, metadata
Unstructured	No fixed data model	Documents, images, audio, video	Classification, search, retention, content lifecycle

Notes and examples

Content and Records Terms

Term	Meaning
Document management	Control creation, storage, retrieval, and lifecycle of documents
Content management	Broader management of digital content for use and publication
Records management	Manage records as evidence of business activity
Taxonomy	Controlled classification structure
Ontology	Formal representation of concepts and relationships
Retention schedule	Rules for how long content/records are kept
Legal hold	Preservation requirement that suspends normal disposal when needed
Version control	Management of revisions and history
eDiscovery	Identification and production of electronically stored information

Document and Content Management

Document and content management focuses on unstructured and semi-structured information such as documents, images, web content, emails, records, and knowledge assets.

Concept	Quick meaning
Document management	Controls documents through creation, versioning, storage, retrieval, and disposition
Content management	Broader management of digital content for use, publishing, search, and reuse
Records management	Manages records that provide evidence of business activity
Taxonomy	Controlled structure for classifying content
Search and retrieval	Enables users to find content efficiently
Version control	Tracks changes and current approved versions

Common trap: Treating documents as outside data management. Content still needs ownership, metadata, classification, retention, access control, and quality expectations.

Reference and Master Data

Master Data vs Reference Data

Aspect	Master data	Reference data
Meaning	Core business entities shared across processes	Controlled lists of valid values/classifications
Examples	Customer, product, vendor, employee, location	Country codes, currency codes, status codes
Management focus	Identity resolution, survivorship, hierarchy, golden record	Standard values, code mappings, valid value governance
Change pattern	Can be complex and frequent	Often more stable, but changes must be controlled
Main risk	Duplicate/inconsistent core entities	Inconsistent coding and interpretation

Notes and examples

MDM Concepts

Term	Meaning
Golden record	Best authoritative representation of an entity
Match	Identify records that may represent same entity
Merge	Combine duplicate records according to rules
Survivorship	Determine which source value wins for an attribute
Hierarchy management	Manage parent-child relationships among master entities
Identity resolution	Determine whether records refer to the same real-world entity
Data stewardship	Review exceptions, approve merges, maintain rules
Registry style	Maintains cross-reference/index to source records
Consolidation style	Creates consolidated view for reporting/analytics
Coexistence style	MDM hub and sources share ongoing maintenance
Transaction style	MDM hub becomes authoritative system of entry for master data

MDM Style Selection

Requirement	Likely style
Need cross-reference without replacing source systems	Registry
Need consolidated reporting view of customers/products	Consolidation
Need shared maintenance across hub and source systems	Coexistence
Need central authoritative creation/update of master data	Transaction
Need quick visibility into duplicates with minimal disruption	Registry or consolidation
Need strong operational control over entity lifecycle	Transaction or coexistence

Reference Data and Master Data

Reference data and master data are commonly confused. The distinction is high-yield.

Reference Data vs. Master Data

Type	Meaning	Examples
Reference data	Standard values used to classify or categorize other data	Country codes, currency codes, status codes, product categories
Master data	Core business entities shared across processes and systems	Customer, product, supplier, employee, location, asset

Master Data Management Concepts

Concept	Meaning
Golden record	Best trusted representation of an entity
Matching	Identifying records that refer to the same real-world entity
Merging	Combining duplicate or overlapping records
Survivorship	Rules for selecting the preferred value among conflicting sources
Hierarchy management	Managing parent-child or grouping relationships
Data stewardship	Resolving ambiguous matches, definitions, and quality issues

MDM Implementation Styles

Style	General idea
Registry	Maintains cross-references and identifiers across systems
Consolidation	Combines data for reporting or reference use
Coexistence	Shares updates between master hub and source systems
Centralized	Master data is authored and managed centrally

Exam trap: MDM is not just deduplication software. It requires governance, ownership, quality rules, integration, matching logic, stewardship, and lifecycle management.

Data Warehousing and Business Intelligence

Warehouse Architecture Terms

Term	Meaning
Data warehouse	Integrated, historical, subject-oriented data store for analytics
Data mart	Subset of warehouse data for department/process/domain
Operational data store	Integrated current/near-current operational data store
Staging area	Temporary landing area for loading/transformation
Semantic layer	Business-friendly abstraction over data structures
Cube	Multidimensional analytic structure
Dashboard	Visual summary of metrics and trends
Report	Structured output answering recurring business questions
KPI	Key performance indicator linked to business objective

Notes and examples

Warehouse vs Lake vs Lakehouse

Platform	Best fit	Governance concern
Data warehouse	Curated, structured, trusted reporting and BI	Definitions, lineage, quality, access control
Data lake	Store large volumes of raw/diverse data	Avoid unmanaged “data swamp” through metadata and governance
Lakehouse	Combine lake flexibility with warehouse-like management features	Clear zones, quality controls, catalog, security
ODS	Current integrated operational reporting	Latency, operational impact, source consistency

BI Metric Traps

Trap	Correct reasoning
KPI without business objective	A KPI should measure progress toward a defined goal
Dashboard as governance solution	Dashboards display data; governance defines meaning, accountability, and rules
Report disagreement treated as visualization issue	Investigate source data, definitions, transformations, and lineage
Data mart built independently without conformed dimensions	Creates inconsistent metrics across departments

Data Warehousing and Business Intelligence

Data warehousing and BI support analysis, reporting, performance management, and decision-making.

Operational vs. Analytical Systems

Feature	Operational systems	Analytical systems
Main purpose	Run business processes	Support reporting and analysis
Data pattern	Current, transaction-focused	Historical, integrated, subject-oriented
Design priority	Fast transactions and integrity	Query performance and usability
Users	Operational staff, applications	Analysts, managers, data consumers
Common design	Normalized relational structures	Dimensional models, warehouses, marts

Dimensional Modeling

Term	Meaning
Fact	Measurable business event or numeric measure
Dimension	Descriptive context for facts
Grain	Level of detail represented by a fact table
Star schema	Fact table connected to dimension tables
Slowly changing dimension	Technique for handling changes in dimension attributes over time

Decision rule: Always identify the grain before evaluating a fact table design. Many dimensional modeling errors come from mixing different levels of detail in the same structure.

BI and Analytics Traps

Confusing dashboards with data governance.
Assuming a report is correct because it was produced by a system.
Ignoring lineage from source to report.
Mixing metrics with different definitions.
Building analytics before agreeing on business terms and calculation rules.

Metadata Management

Metadata Categories

Category	Describes	Examples
Business metadata	Business meaning and usage	Definitions, business rules, owners, policies
Technical metadata	Technical structure and processing	Tables, columns, datatypes, schemas, jobs
Operational metadata	Runtime and processing information	Load times, error counts, usage logs
Process metadata	Data movement and transformations	ETL mappings, workflow steps
Governance metadata	Accountability and controls	steward, classification, retention rule
Lineage metadata	Origin and transformation path	Source-to-report trace
Usage metadata	How data is accessed and used	Query frequency, report usage

Notes and examples

Metadata Tools and Artifacts

Artifact/tool	Purpose
Business glossary	Shared definitions for business terms
Data dictionary	Technical definitions of data structures
Data catalog	Searchable inventory of data assets and metadata
Metadata repository	Central store for metadata
Lineage tool	Shows where data came from and how it changed
Data profiling tool	Analyzes actual data values and patterns
Classification tags	Identify sensitivity, domain, quality, retention, ownership

Glossary vs Dictionary vs Catalog

Item	Primary audience	Focus
Business glossary	Business and governance users	Meaning, definition, ownership, approved terms
Data dictionary	Developers, DBAs, analysts	Technical fields, tables, datatypes, constraints
Data catalog	Broad data consumers	Discoverability, metadata, lineage, usage, access path

Metadata Management

Metadata is data about data. It makes data understandable, traceable, usable, and governable.

Metadata Types

Type	Describes	Examples
Business metadata	Business meaning and context	Definitions, owners, rules, glossary terms
Technical metadata	Structure and implementation	Tables, columns, datatypes, mappings
Operational metadata	Processing and usage	Job runs, load times, error counts, access logs
Administrative metadata	Management and control	retention, classification, stewardship, ownership

Metadata Capabilities

Capability	Why it matters
Business glossary	Aligns terminology across business and technology teams
Data catalog	Helps users discover, understand, and evaluate data assets
Lineage	Shows where data came from and how it changed
Impact analysis	Helps assess effects of changes
Data dictionary	Describes structures, fields, formats, and constraints
Metadata repository	Stores and manages metadata centrally or federatively

Exam trap: A data dictionary is not the same as a full metadata management program. A dictionary may describe fields; metadata management also includes ownership, lineage, rules, quality, usage, and governance processes.

Data Quality

Data Quality Dimensions

Dimension	Question answered	Example check
Accuracy	Does data correctly represent reality?	Address matches verified source
Completeness	Are required values present?	Customer record has required contact fields
Consistency	Do values agree across systems/rules?	Same customer status in CRM and billing
Timeliness	Is data available/current when needed?	Daily sales loaded before morning reporting
Validity	Does data conform to format/domain/rules?	Date is valid; status is from approved list
Uniqueness	Are duplicates avoided?	One active customer record per real customer
Integrity	Are relationships and constraints maintained?	Order references valid customer
Conformity	Does data follow standards?	Phone format follows standard pattern
Reasonableness	Is value plausible?	Birth date not in future

Notes and examples

Data Quality Process

Step	Purpose	Output
Define requirements	Identify fitness-for-purpose expectations	DQ rules, thresholds, critical data elements
Profile data	Understand actual values and patterns	Profiling results, anomalies
Measure quality	Quantify against rules/dimensions	DQ scorecards, metrics
Analyze root cause	Identify why defects occur	Root-cause analysis
Remediate	Correct data and/or process	Cleansed data, process fixes
Monitor	Detect recurrence and trends	Alerts, dashboards
Prevent	Embed controls upstream	Validation, training, improved process

Data Quality Formulas

Completeness rate:

\[ \text{Completeness Rate} = \frac{\text{Number of populated required values}}{\text{Number of required values expected}} \times 100 \]

Defect rate:

\[ \text{Defect Rate} = \frac{\text{Number of records failing a rule}}{\text{Total records tested}} \times 100 \]

Duplicate rate:

\[ \text{Duplicate Rate} = \frac{\text{Number of duplicate records identified}}{\text{Total records evaluated}} \times 100 \]

DQ Scenario Decisions

Scenario	Best response
Missing required fields in a source application	Add validation and process controls at capture point
Different customer counts in two reports	Compare definitions, filters, source lineage, and transformations
Duplicate customer records	Use matching rules, MDM/steward review, prevention at entry
Valid values differ by system	Govern reference data and code mappings
Dashboard shows stale data	Check load timeliness, SLAs, operational metadata
Quality score improves only after manual cleanup	Address root cause and preventive controls, not just correction

Data Quality

Data quality means data is fit for its intended use. It is not absolute perfection.

Common Data Quality Dimensions

Dimension	Meaning	Example question
Accuracy	Data correctly represents the real-world value	Is the customer address correct?
Completeness	Required data is present	Is date of birth missing where required?
Consistency	Data agrees across systems or records	Does customer status match in two systems?
Timeliness	Data is current enough for use	Was the balance updated in time for reporting?
Validity	Data conforms to rules or allowed values	Is the status code in the approved list?
Uniqueness	Entity is not duplicated unnecessarily	Are there duplicate customer records?
Integrity	Relationships and constraints are maintained	Does every order reference a valid customer?

Data Quality Activities

Activity	Purpose
Profiling	Examines data to discover patterns, anomalies, and quality issues
Assessment	Evaluates quality against business requirements
Cleansing	Corrects or standardizes data values
Matching/deduplication	Identifies and resolves duplicate entities
Monitoring	Tracks quality over time
Root-cause analysis	Finds why defects occur
Prevention	Improves processes and controls to stop defects at source

High-yield distinction: Cleansing fixes existing data; quality management also prevents future defects through governance, standards, controls, process changes, and monitoring.

Big Data and Data Science

Big Data Characteristics

Characteristic	Meaning
Volume	Large quantities of data
Velocity	Speed of generation, ingestion, or processing
Variety	Multiple formats and structures
Veracity	Trustworthiness and uncertainty
Value	Business benefit derived from use

Notes and examples

Analytics Types

Type	Question	Example
Descriptive	What happened?	Monthly sales report
Diagnostic	Why did it happen?	Root-cause analysis of churn
Predictive	What is likely to happen?	Churn prediction model
Prescriptive	What should be done?	Recommended next best offer

Data Science Lifecycle

Stage	Focus	Governance touchpoints
Problem framing	Define business objective and success criteria	Business ownership, ethical use
Data acquisition	Identify and collect data	Consent/permissions, source quality, lineage
Preparation	Clean, transform, engineer features	DQ rules, reproducibility
Modeling	Train and evaluate models	Bias, explainability, validation
Deployment	Operationalize model	Monitoring, access, change control
Monitoring	Track performance and drift	Metrics, auditability, retraining triggers

Data Science Traps

Trap	Correct reasoning
More data always means better model	Relevance, quality, bias, and representativeness matter
Data lake eliminates governance need	Big data requires metadata, quality, security, lifecycle controls
Model accuracy is the only concern	Ethics, explainability, bias, operational fit, and monitoring also matter
Experiment data can ignore lineage	Reproducibility requires data and process traceability

Big Data, Data Science, and Analytics Governance

For CDMP review, focus less on buzzwords and more on how data management principles apply at scale.

Concept	What to remember
Big data	Data with volume, velocity, variety, or complexity that challenges traditional approaches
Data lake	Stores raw or varied data for exploration and analytics; still needs governance and metadata
Data lakehouse	Combines lake-style storage with warehouse-like management features
Data science	Uses statistical, computational, and machine learning methods to generate insight or predictions
Machine learning model	Learns patterns from data to make predictions or classifications
Feature	Input variable used by a model
Model governance	Controls model development, validation, deployment, monitoring, and responsible use

Common Analytics Traps

Assuming more data automatically means better results.
Ignoring bias, representativeness, and data provenance.
Using data without understanding definitions and lineage.
Treating models as one-time deliverables rather than lifecycle assets.
Forgetting security, privacy, ethics, and access controls in analytical environments.

Data Lifecycle Review

Data management spans the full lifecycle, not just storage.

Lifecycle stage	Key concerns
Plan	Strategy, requirements, ownership, architecture, standards
Create or acquire	Source quality, definitions, consent or usage expectations, validation
Store and maintain	Databases, platforms, metadata, security, backup, performance
Use and share	Access, integration, reporting, analytics, interoperability
Archive	Long-term retention, cost, retrieval needs, classification
Dispose	Authorized deletion or destruction when no longer needed

Exam trap: If a question asks for the best long-term solution, prefer lifecycle controls and prevention over repeated manual cleanup.

Data Ethics and Responsible Data Handling

Principle	Practical meaning
Respect for persons	Consider individual rights, expectations, and impacts
Beneficence	Seek benefit and reduce harm
Justice	Avoid unfair treatment or discriminatory outcomes
Transparency	Be clear about data use where appropriate
Accountability	Assign responsibility for decisions and outcomes
Minimization	Use only data needed for the purpose
Purpose alignment	Use data consistently with legitimate business purpose
Risk awareness	Evaluate misuse, bias, exposure, and downstream impact

Notes and examples

Ethical Red Flags

Red flag	Why it matters
Using data for a purpose unrelated to collection context	Violates trust and may create legal/compliance risk
Combining datasets to infer sensitive attributes	Creates hidden privacy and fairness risks
No accountability for algorithmic decisions	Weakens auditability and remediation
Ignoring biased or unrepresentative training data	Can produce unfair or invalid outcomes
Excessive retention	Increases risk and may conflict with policy
“Because we can” reasoning	Capability does not equal appropriate use

Data Management Maturity

Maturity Assessment Focus Areas

Area assessed	What to look for
Strategy	Data goals aligned to business priorities
Governance	Decision rights, policies, ownership, stewardship
Architecture	Enterprise data view and target-state planning
Quality	Defined rules, measurement, remediation, monitoring
Metadata	Catalog/glossary/lineage and active metadata use
Security	Classification, access control, monitoring
Organization	Roles, responsibilities, funding, operating model
Processes	Repeatable, measured, improved practices
Tools	Supporting technology aligned to processes
Culture	Data literacy, adoption, accountability

Maturity vs Capability vs Performance

Term	Meaning
Maturity	Degree to which practices are defined, managed, measured, and improved
Capability	Ability to perform a data management function
Performance	Results achieved by executing the capability
Gap analysis	Difference between current and desired state
Roadmap	Sequenced improvement plan

Organization, Roles, and Change Management

Common Roles

Role	Primary responsibility
Executive sponsor	Provides authority, funding, and strategic support
Data governance council	Makes cross-functional data decisions and resolves escalations
Chief data officer / senior data leader	Leads enterprise data strategy and program direction where established
Data owner	Business accountability for data domain or critical data
Business data steward	Business definitions, quality rules, issue resolution
Technical data steward	Technical metadata, mappings, lineage, platform details
Data architect	Enterprise and solution data architecture
Data modeler	Conceptual/logical/physical models
DBA / data platform administrator	Storage, performance, backup, operational control
Data engineer	Pipelines, integration, transformation, data products
BI developer / analyst	Reports, dashboards, semantic models
Data quality analyst	Profiling, measurement, issue tracking
Information security professional	Security policy, controls, risk management
Records/content manager	Document, content, retention, records lifecycle

Notes and examples

RACI Basics

Letter	Meaning	Exam note
R	Responsible	Performs the work
A	Accountable	Owns outcome and final decision; ideally one accountable party
C	Consulted	Provides input before decision/action
I	Informed	Kept aware after decision/action

Change Management for Data Programs

Need	Practical action
Stakeholder buy-in	Identify affected groups and explain value
Adoption of standards	Train, communicate, embed in workflows
Resistance management	Address incentives, workload, and concerns
Sustained behavior change	Use metrics, leadership support, reinforcement
Data literacy	Teach definitions, quality expectations, and responsible use
Governance participation	Clarify time commitment, authority, and escalation paths

Cross-Knowledge-Area Scenario Matrix

If the prompt says…	Most likely area	Why
“Who is authorized to define this term?”	Data Governance	Decision rights and ownership
“What does this business term mean?”	Metadata Management	Business glossary and definitions
“Where did this report value come from?”	Metadata Management / Integration	Lineage and transformations
“Why are there duplicate customer records?”	MDM / Data Quality	Entity resolution and duplicate prevention
“How should customer data be structured?”	Data Modeling and Design	Entities, attributes, keys, relationships
“How do systems exchange order data?”	Data Integration and Interoperability	Interfaces, mappings, APIs, ETL
“Which platform stores history for analytics?”	Data Warehousing and BI	Historical integrated reporting
“How do we restrict access to sensitive data?”	Data Security	Classification, authorization, controls
“How long should records be retained?”	Records/Content Management and Governance	Retention rules and lifecycle
“How mature is our data program?”	Data Management Maturity	Capability assessment and roadmap
“How do we get people to follow new data standards?”	Organizational Change Management	Adoption and behavior change

Common Exam Traps and Corrections

Trap	Better answer
Governance equals data quality	Governance sets accountability and rules; DQ measures and improves fitness for use
Metadata equals data dictionary only	Metadata includes business, technical, operational, lineage, governance, and usage information
MDM equals data warehouse	MDM manages authoritative core entities; warehouses support analytics
Data architecture equals database design	Architecture covers enterprise data assets, flows, principles, and target state
Data security belongs only to IT	Security requires business classification, risk decisions, and technical controls
Data quality means 100% perfect data	Quality means fit for purpose at acceptable cost/risk
Data lake means raw data without controls	Data lakes still need cataloging, security, lineage, quality, and lifecycle management
Data owner performs all data work	Owner is accountable; stewards/custodians/engineers perform specific tasks
Reports are wrong because the BI tool is wrong	Check definitions, sources, transformations, lineage, and quality first
Cleanup is enough to solve quality	Prevent recurrence through upstream process and control changes
Reference data and master data are interchangeable	Reference data is valid value sets; master data is core business entities
Logical model is platform-specific	Physical model is platform-specific; logical model is business-structured but implementation-neutral

Compact Term Table

Term	Quick meaning
Critical data element	Data element important to business operations, decisions, risk, or reporting
Authoritative source	Trusted source designated for a data element or domain
System of record	Official source for a particular business transaction or data set
System of entry	System where data is initially captured
Data lineage	Path from origin through movement, transformation, and use
Data provenance	Origin and history of data
Data profiling	Analysis of actual data values, patterns, completeness, uniqueness, validity
Data cleansing	Correcting or standardizing defective data
Data enrichment	Adding value by appending or deriving additional data
Data standardization	Applying consistent formats, codes, names, or structures
Data stewardship	Accountability-in-action for definitions, quality, and issue resolution
Data domain	Logical grouping of related data, such as customer or product
Data product	Packaged data asset designed for consumption and reuse
Data contract	Agreement about structure, semantics, quality, and change expectations
Data classification	Categorization by sensitivity, value, or risk
Semantic consistency	Same meaning across contexts
Canonical model	Standard shared representation for exchange or integration
CRUD matrix	Create, read, update, delete mapping between processes and data
Referential integrity	Valid relationships between related records
Survivorship rule	Rule determining preferred source value in MDM
Conformed dimension	Dimension shared consistently across analytic structures
Data lineage gap	Missing traceability between source and consumption
Data swamp	Poorly governed data lake with low discoverability and trust

Fast Review Checklist

Before Answering a Scenario Question

Identify the business problem: authority, meaning, movement, quality, security, analytics, or storage.
Separate accountability from execution.
Look for lifecycle stage: create, store, use, share, retain, dispose.
Check whether the question asks for policy, process, artifact, role, or technology.
Prefer prevention and root-cause correction over after-the-fact cleanup.
Prefer business-aligned definitions and ownership over purely technical fixes.
Do not ignore metadata, lineage, or stewardship when trust is the issue.

Last-Pass Knowledge Area Cues

Cue word or phrase	Think
Authority, accountability, policy	Governance
Subject area, target state, enterprise view	Architecture
Entity, attribute, relationship, key	Modeling
Backup, recovery, performance, retention	Storage and Operations
Confidentiality, access, classification	Security
ETL, API, source-to-target, exchange	Integration
Documents, records, taxonomy, retention	Content Management
Customer/product/vendor golden record	MDM
Valid codes, value lists	Reference Data
Dashboard, KPI, dimensional model	DW/BI
Glossary, catalog, lineage	Metadata
Accuracy, completeness, profiling	Data Quality
Model, prediction, data lake, features	Big Data/Data Science
Maturity, capability, roadmap	Maturity Assessment
Adoption, training, resistance	Change Management

The Core Mental Model

The CDMP exam rewards candidates who understand data management as a coordinated business capability, not as a set of isolated technical tasks.

A useful mental model:

Layer	What it answers	Examples
Business direction	Why are we managing data?	Strategy, value, risk reduction, compliance support, analytics enablement
Governance	Who decides and who is accountable?	Policies, stewardship, ownership, councils, standards
Architecture and design	How should data capabilities fit together?	Data architecture, models, integration patterns, platforms
Operations	How is data created, stored, moved, protected, and used?	Databases, data pipelines, APIs, warehouses, backups
Controls and improvement	How do we keep data trusted and useful?	Data quality, metadata, lineage, security, monitoring

A common candidate mistake is to treat every issue as a technology problem. In DAMA-style data management, many problems are governance, ownership, definition, quality, or lifecycle problems before they are tool problems.

Governance: Decision Rights, Accountability, and Control

Data governance is one of the most important CDMP review areas because it connects business accountability to data management execution.

Governance vs. Management

Concept	Primary question	Typical outputs
Data governance	Who has authority and accountability for data decisions?	Policies, standards, decision rights, issue escalation, stewardship model
Data management	How are data capabilities planned, built, operated, and improved?	Models, platforms, processes, controls, data quality rules, metadata repositories
Data stewardship	Who helps define, monitor, and improve data in practice?	Definitions, quality rules, issue resolution, glossary content, usage guidance

Notes and examples

Key Governance Roles

Role	Main responsibility	Common trap
Data owner	Accountable for data within a business domain or process	Not necessarily the person who stores or administers the data
Data steward	Helps define, manage, monitor, and improve data	Stewardship is not just clerical cleanup
Data custodian	Operates or administers data systems and storage	Custodians usually do not own business meaning
Data architect	Designs structures, flows, models, and standards	Architecture should support business strategy, not just technical elegance
Data consumer	Uses data for operations, reporting, analytics, or decisions	Consumers also create requirements and quality expectations

Policies, Standards, Procedures, and Guidelines

Item	Meaning	Example
Policy	High-level rule or intent	Sensitive data must be protected according to classification
Standard	Required way to comply	Customer identifiers must follow an approved format
Procedure	Step-by-step method	Process for approving a new data sharing request
Guideline	Recommended practice	Preferred naming pattern for analytics datasets

Exam trap: If the question asks about accountability, authority, escalation, or enterprise-wide rules, think governance. If it asks about execution, operation, implementation, or administration, think management.

Data Strategy and Business Value

Data management should support business outcomes. Candidates often over-focus on definitions and under-focus on purpose.

Business goal	Data management contribution
Better decisions	Trusted, timely, well-defined data and analytics
Operational efficiency	Standardized data, reduced rework, fewer reconciliation issues
Risk reduction	Controls for security, retention, quality, lineage, and access
Regulatory support	Traceable, governed, classified, and auditable data practices
Customer or product insight	Integrated, high-quality data across channels and systems
Innovation	Reusable data assets, scalable platforms, and responsible analytics

A good exam answer often favors the option that improves data as an enterprise asset rather than a narrow local workaround.

Common CDMP Wording Traps

Watch for these patterns when answering practice questions.

Wording pattern	What it often tests	Better approach
“Best first step”	Sequencing	Understand requirements, ownership, definitions, or impact before implementing tools
“Most responsible for”	Accountability	Distinguish owner, steward, custodian, architect, and consumer
“Enterprise-wide”	Governance or architecture	Avoid local project-only fixes
“Trusted data”	Quality, metadata, lineage, governance	Do not choose only storage or reporting
“Common definition”	Business glossary or metadata	Do not choose physical database design
“Duplicate customers”	MDM and data quality	Include matching, survivorship, stewardship
“Sensitive data exposure”	Security and governance	Include classification, access, monitoring, and handling rules
“Inconsistent reports”	Definitions, lineage, integration, quality	Avoid assuming the BI tool is the root cause
“Historical analysis”	Data warehousing/BI	Operational database is usually not the best answer
“Impact of a change”	Metadata and lineage	Need traceability across sources, transformations, and reports

Fast Decision Rules

Use these quick rules during topic drills and mock exams.

If the question emphasizes…	Think first about…
Accountability, ownership, decision rights	Data governance
Business definitions and shared terminology	Business glossary and metadata
Structure of business concepts	Conceptual or logical data modeling
Tables, indexes, partitions, datatypes	Physical design and operations
Data movement between systems	Integration and interoperability
Trusted entity records across systems	Master data management
Standard code lists	Reference data management
Reporting, history, dashboards, metrics	Data warehousing and BI
Meaning, lineage, discovery, impact analysis	Metadata management
Missing, invalid, duplicated, inconsistent data	Data quality management
Access, sensitivity, misuse, disclosure	Data security
Documents, records, versions, retention	Content and records management
Large-scale analytics or ML	Big data, data science, and analytics governance

What Strong Candidates Can Explain

Before moving into mixed mock exams, make sure you can explain these without looking them up:

The difference between data governance, data management, and data stewardship.
Why data owners are accountable for business meaning while custodians often manage technical environments.
The difference between conceptual, logical, and physical data models.
Why reference data and master data are related but not the same.
How metadata supports lineage, impact analysis, quality, governance, and discovery.
Why data quality is “fitness for use,” not abstract perfection.
The difference between profiling, cleansing, monitoring, and root-cause prevention.
Why data warehousing supports analytics differently from operational systems.
How ETL, ELT, APIs, replication, streaming, and virtualization differ.
Why security requires classification, access control, monitoring, and accountability.
How lifecycle thinking changes retention, archiving, and disposal decisions.
Why tool selection is rarely the best first answer when governance, definitions, or requirements are unclear.

Review-to-Practice Plan

Use this Cheat Sheet as a bridge into IT Mastery practice.

Step 1: Diagnose by Topic

Start with short topic drills from an original question bank. Do not begin with only full mock exams unless you already know your weak areas.

Recommended drill order:

Data governance and stewardship
Data modeling and architecture
Metadata and data quality
Reference data and master data
Integration and interoperability
Data warehousing and BI
Security, lifecycle, storage, and operations
Content management, big data, and data science

Step 2: Read Detailed Explanations Carefully

For every missed or guessed question, identify the reason:

Miss reason	What to do
Term confusion	Build a short contrast table
Role confusion	Review owner, steward, custodian, architect, and consumer responsibilities
Sequencing error	Ask what should happen before implementation
Tool-first thinking	Reframe the issue as governance, quality, metadata, or lifecycle
Overlooking wording	Highlight “first,” “best,” “most responsible,” and “enterprise-wide”
Weak domain knowledge	Return to targeted topic drills before another mock exam

Step 3: Move to Mixed Practice

After topic drills, use mixed question sets to practice switching domains quickly. The real challenge is often recognizing which knowledge area a scenario belongs to.

Step 4: Use Mock Exams for Timing and Judgment

Mock exams are most useful after you have already corrected major topic gaps. Review detailed explanations for both incorrect and correct answers, especially when you chose correctly by guessing.

Final Rapid Check

Before your next practice session, ask yourself:

Is this problem about governance, management, architecture, quality, metadata, or security?
Who is accountable for the data decision?
Is the issue caused by unclear definitions, poor quality, weak controls, or bad integration?
Does the answer solve the root cause or only clean up symptoms?
Is the question asking for a strategic, tactical, or operational response?
Would a business stakeholder, steward, architect, custodian, or analyst be the right lead?
Is the answer enterprise-reusable or only a local workaround?

Put the review into practice

Study Plan