Data Foundations (CMDB and CSDM) common mistakes
Data Foundations (CMDB and CSDM) · Understand the traps and how to avoid them.
Treating the CMDB as a simple inventory list and answering questions as if recording a CI's attributes is the whole job, ignoring that the CMDB is the data store within the broader Configuration Management System.
Candidates skim the fundamentals domain and conflate the database (the CMDB) with the overall system of people, process, and tools (the CMS) that produces and consumes configuration data.
What to do instead
Memorize the containment hierarchy: CMDB is one component of the Configuration Management System, which is itself part of the overall service management system. For any question, ask whether it is asking about the store, the process, or the wider system before answering.
Assuming every asset, record, or piece of data in the environment is automatically a CI, and selecting 'all assets are CIs' style answers.
The word 'configuration item' sounds like a synonym for 'thing we track', so candidates skip the defining criterion that a CI is any component that needs to be managed in order to deliver a service.
What to do instead
Apply the control test: is this component under configuration control and does it need to be managed to deliver a service? If it is merely purchased or owned but not managed for service delivery, it is not necessarily a CI. Practice classifying borderline items (a license, a spare laptop, a business process).
Answering CSDM questions by describing it as a database schema or a set of tables, rather than as a prescriptive, common data model with defined domains and layers.
Candidates map CSDM onto their technical experience with database design and miss that CSDM is a modeling standard for how service, product, and infrastructure data relate.
What to do instead
Frame every CSDM answer around its purpose: providing a common, prescriptive model so that data is consistent, reusable, and supports multiple use cases. Reject answers that reduce CSDM to physical tables or to a single application.
Confusing the CSDM layers (e.g., foundation, service, and the higher-order/business-facing layers) and placing records such as business services, service offerings, or technical services in the wrong layer.
The layers are abstract and overlap conceptually, so candidates rely on intuition about where a record 'feels' like it belongs instead of the model's defined placement.
What to do instead
Build a one-page diagram mapping each CSDM domain and layer to its key record types and the questions it answers (foundation = what exists; service layers = how it is offered and consumed). Drill by placing sample records into layers until placement is automatic.
Treating CSDM domains as independent silos and failing to recognize that the domains are interrelated and that data flows between them to support end-to-end service views.
Candidates study each domain in isolation for memorization and never practice questions that require connecting a business-facing record to the underlying technical and foundational records.
What to do instead
For each domain, write down its upstream and downstream relationships to the other domains. Practice 'trace the path' exercises: given a business service, identify the service offerings, technical services, and foundational CIs that support it.
Believing that CMDB health is achieved by filling in every field and recording every possible attribute, and choosing answers that emphasize completeness over controlled, purposeful data.
Candidates equate data quality with volume and completeness, missing that governance prioritizes accuracy, currency, and fitness for the intended use cases over exhaustive capture.
What to do instead
Adopt the governance mindset: data should be right-sized to the use cases it supports. When a question offers 'capture all possible attributes' versus 'capture the attributes required for the defined use cases and keep them accurate', choose the latter and be able to justify why.
Confusing CMDB health metrics such as completeness, correctness, and compliance, and picking a metric that measures the wrong dimension for the scenario described.
The terms sound interchangeable, so candidates pattern-match on the word 'complete' or 'accurate' without checking what the scenario is actually measuring.
What to do instead
Define each metric in your own words with an example: completeness (required fields populated), correctness (values match reality), compliance (records conform to governance rules and standards). Read the scenario's evidence before choosing the metric.
Modeling every relationship as a simple dependency and ignoring relationship types, direction, and the distinction between depends-on, contains, and other relationship semantics.
Candidates think of relationships as generic links and underweight that the type and direction determine how impact analysis and service mapping behave.
What to do instead
Learn the common relationship types and their directionality, and practice drawing them with arrows. For impact-analysis questions, trace direction explicitly (what depends on what) rather than assuming any connection implies impact.
Assuming service mapping is the same as manual CI entry or that automated discovery alone produces a complete, correct service map without human-defined service context.
Candidates conflate discovery (finding infrastructure) with service mapping (understanding how components combine to deliver a service) and choose answers that overstate automation.
What to do instead
Separate the concepts: discovery populates foundational CI data; service mapping expresses how those CIs combine into services and requires service context. For mapping questions, look for answers that combine automated data with defined service boundaries and validation.
Treating CMDB/CSDM reporting as a technical inventory report exercise and missing questions about value realization, such as how the data supports impact analysis, change risk, and service-level decisions.
Candidates focus on learning record structures and neglect the 'so what' of the model, so they cannot connect data quality to business outcomes.
What to do instead
For each reporting topic, state the decision it enables and the stakeholder who uses it (e.g., impact analysis for change managers, service health for service owners). Practice converting a data question into a value question and back again.