CSDM Fundamentals practice questions

Hosted on / Hosts

Why it fails: Hosted on / Hosts links a CI to the hardware or virtual host it resides on, not an Application Service to its supporting server. It is tempting because Tomcat runs on a host, but that relationship targets infrastructure hosting, correct when mapping a server CI to its physical or virtual machine.

Member of / Contains

Why it fails: Member of / Contains groups CIs into logical collections such as groups or clusters, not service-to-infrastructure mapping. It is tempting because Application Services contain members, but that relationship expresses grouping, correct when assigning CIs to a CI group or bundle rather than linking a service to its server.

Runs on / Runs

Why it fails: Incorrect. 'Runs on' is typically used between software instances and underlying hardware or operating systems.

Mapping Business Applications directly to User Group records.

Why it fails: CSDM links Business Applications to Business Services through the "Contains::Contained by" relationship, not to User Groups, which model support or access groupings. Mapping to User Groups is tempting because groups appear in application records, but that association provides no enterprise architecture traceability between the two service layers.

Direct foreign key column on the Incident table.

Why it fails: CSDM links Business Services to Business Applications through the Service Offering and Business Application relationship tables, not a foreign key on Incident. Incident holds an affected-CI reference, so it records impact, not architecture traceability. A direct column would be tempting for quick reporting, but it cannot express many-to-many mapping.

Embedding Business Applications inside Hardware Asset records.

Why it fails: Business Applications are logical CIs, not children of Hardware Asset records; embedding them there conflates logical and physical layers and breaks CSDM traceability. Hardware Asset records describe physical devices, so this suits asset lifecycle tracking, not mapping a Business Service to the applications that deliver it.

Business Application -> Linux Servers -> Application Service

Why it fails: Reverses the CSDM dependency: the Business Application sits above the Application Service, not beneath Linux Servers. Servers host Application Services, which the Business Application consumes. The ordering here implies infrastructure depends on the business layer, inverting the actual hierarchy that CSDM prescribes.

Application Service -> Linux Servers -> Business Application

Why it fails: Places Linux Servers between Application Service and Business Application, but servers are CI infrastructure that hosts Application Services, not an intermediate layer. CSDM links Business Application to Application Service directly; the servers belong lower, in the infrastructure domain, not in this path.

Linux Servers -> Business Application -> Application Service

Why it fails: Puts Business Application beneath Linux Servers and Application Service above it, so infrastructure appears to depend on the business layer. CSDM instead has servers hosting Application Services, which the Business Application consumes, giving the reverse ordering from infrastructure upward.

Database Server -> Business Service -> Application Service

Why it fails: Traversal must run from the failing CI upward to the Business Service, not downward through Application Service. This path inverts the dependency direction, so impact cannot propagate to the business layer. It is tempting because it starts at the failing component, but CSDM impact flows CI to service.

Business Service -> Application Service -> Database Server

Why it fails: This path descends from Business Service to Database Server, which is the reverse of impact traversal. CSDM requires starting at the failing CI and following relationships upward to identify affected Business Services. It is tempting because it lists all three tiers, but direction determines whether impact is visible.

Business Service -> Database Server -> Application Service

Why it fails: Placing Database Server between Business Service and Application Service breaks the CSDM dependency chain, since applications consume database CIs, not the reverse. Impact traversal must ascend from CI through Application Service to Business Service. It is tempting because all tiers appear, but the ordering is inverted.

Run

Why it fails: Incorrect. Run involves advanced operational management.

Fly

Why it fails: Incorrect. Fly represents full optimization.

Crawl

Why it fails: Incorrect. Crawl focuses strictly on foundation and basic CI data.

Foundation

Why it fails: Incorrect. Foundation covers basic users and locations.

Manage Technical Services

Why it fails: Manage Technical Services covers the operational delivery and support of services, not vendor software asset tracking, lifecycle or financial portfolio management. It is tempting because technical services underpin the software estate, but that domain would be the right answer when the requirement concerns service delivery models, support ownership or operational SLAs rather than asset and cost governance.

Sell/Consume

Why it fails: Incorrect. Sell/Consume covers offerings and catalogs.

Fly

Why it fails: Incorrect. Fly represents optimization and transformation.

Crawl

Why it fails: Crawl establishes initial domain foundations and basic data population, not sustained quality assurance. The scenario demands ongoing data-quality maintenance with operational metrics integrated across all four CSDM domains — that is the Manage phase's remit. Crawl would be right when starting CSDM adoption and loading foundational entities for the first time.

Walk

Why it fails: Walk expands coverage across domains and refines relationships, but does not own continuous data-quality upkeep or cross-domain operational metric integration. Those belong to the Manage phase. Walk is the correct choice when broadening CSDM scope beyond the initial foundation, not when maintaining quality and metrics across all four domains.

Hardware Application Service

Why it fails: Incorrect. Hardware Application Service is not a standard service type.

Foundation Application Service

Why it fails: Incorrect. Foundation Application Service is not a standard service type.

Portfolio Application Service

Why it fails: Incorrect. Portfolio Application Service is not a standard service type.

Human Resources

Why it fails: Incorrect. HR is a separate application suite, not a CSDM domain.

Security Operations

Why it fails: Incorrect. SecOps is a separate product line, not a CSDM domain.

Computer [cmdb_ci_computer]

Why it fails: Computer is a Manage Technical Service domain table representing infrastructure CIs, not a Sell/Consume artefact. Sell/Consume holds Product, Service Offering, Catalog Item and Sold Product records. Computer would be correct when modelling the physical or virtual servers that underpin technical services, not the commercial offerings customers consume.

User [sys_user]

Why it fails: User is a Foundation domain table holding people and identity reference data, not a Sell/Consume artefact. Sell/Consume contains Product, Service Offering, Catalog Item and Sold Product records. User would be correct when classifying the individuals who raise requests or consume offerings, not the offerings themselves.

Business Application [cmdb_ci_business_app]

Why it fails: Business Application is a Design domain table describing logical groupings of capabilities, not a Sell/Consume artefact. Sell/Consume holds Product, Service Offering, Catalog Item and Sold Product records. Business Application would be correct when modelling the applications that support business capabilities, not the commercial offerings presented to consumers.

User [sys_user]

Why it fails: User [sys_user] sits in the Foundation domain as a people record, not the Design domain, which holds conceptual models such as Business Application and Application Service. It is tempting because CI ownership references users, but ownership linkage does not place the table itself in Design.

Computer [cmdb_ci_computer]

Why it fails: Computer [cmdb_ci_computer] belongs to the Manage Technical Service domain as an operational CI, not Design, which covers conceptual and logical models. It is tempting because computers underpin applications, yet Design tables describe intent and architecture rather than deployed infrastructure instances.

Incident [incident]

Why it fails: Incident [incident] is an ITIL process table in the Service Operations domain, not a CSDM Design-domain table. It is tempting because incidents reference CIs and appear in CMDB reporting, but process records describe activity, not the conceptual or logical design of services.

Service Offering [service_offering]

Why it fails: Service Offering sits in the Design domain, describing what is offered to consumers, not the Foundation domain's authoritative CI and relationship data. It is tempting because offerings reference business services, but Foundation covers company, location, user, group and service data instead.

Application Service [cmdb_ci_service_calculated]

Why it fails: Application Service is a calculated CI belonging to the Design domain, derived from application service mapping rather than Foundation's core CI records. Its name suggests foundational infrastructure, which is why it tempts, but Foundation holds company, user, group, location and service data.

Business Application [cmdb_ci_business_app]

Why it fails: Business Application is a Design-domain CI describing logical applications and their owners, not Foundation's authoritative infrastructure and people records. It is tempting because applications feel fundamental, yet Foundation covers company, location, user, group and service data only.

Delete all Business Application records once Discovery runs for the first time.

Why it fails: Business Applications must persist as the logical layer that Application Services map to; deleting them after Discovery removes the traceability the mapping depends on. The temptation is that Discovery populates CIs automatically, but it discovers infrastructure and application CIs, not the business context Business Applications carry.

Map all servers directly to the Business Application without creating Application Services.

Why it fails: Collapsing servers straight onto the Business Application removes the Application Service layer that groups CIs by function, so dependency and impact mapping break. It tempts because fewer records look tidy, but Application Services exist precisely to model multi-tier service composition between business and infrastructure.

Publishing public employee onboarding catalog items.

Why it fails: Incorrect. Employee onboarding catalog items belong in Sell/Consume.

Managing enterprise business architecture capabilities.

Why it fails: Incorrect. Business capabilities belong in Design.

Defining corporate organizational departments and locations.

Why it fails: Incorrect. Departments and locations belong in Foundation.

Business applications replace the need for defining business capabilities.

Why it fails: Business capabilities describe what the organisation does; applications are enablers mapped to them, so capabilities remain essential regardless of application count. It is tempting because applications deliver capability outcomes, but CSDM maintains both as distinct, related layers rather than substitutes.

Business capabilities must be created as child records of hardware computer CIs.

Why it fails: Business capabilities are logical, non-physical entities at the business layer; hardware computer CIs sit at the infrastructure layer and cannot parent them. It is tempting because CSDM links layers hierarchically, but capability-to-hardware containment contradicts the model's layering.

A 'Depends on::Used by' relationship between the business service and each application service.

Why it fails: The 'Depends on::Used by' relationship is used for dynamic dependencies between configuration items, such as an application service depending on a database server. It does not model the structural decomposition of a business service into application services. Using it here would misrepresent the service hierarchy and could break impact analysis that expects parent-child containment within the service domain.

A 'Provides::Provided by' relationship from the business service to each application service.

Why it fails: The 'Provides::Provided by' relationship is used to indicate that a service provides something to a user or another service, such as a business service providing value to a customer. It is not the correct relationship for expressing that a business service is composed of application services. Applying it here would create an incorrect semantic link and fail to establish the needed containment.

A 'Uses::Used by' relationship between the business service and each application service.

Why it fails: The 'Uses::Used by' relationship typically links a business service to a business application or an application service to a technical service, indicating consumption rather than composition. It does not define the parent-child containment required to show that application services are components of the business service, so it would not support proper service hierarchy and impact traversal.

Service Delivery domain

Why it fails: The Service Delivery domain encompasses the service catalog, request items, and service level management. It is not intended for physical infrastructure CIs. A database server is a technical component that supports services, but it belongs in the infrastructure domain, not in the domain that manages service requests and delivery commitments.

Design domain

Why it fails: The Design domain in CSDM focuses on the logical design of services and applications, such as business applications and application services. It does not include physical infrastructure CIs like database servers. Placing a database server in the Design domain would misalign it with the framework's intent, which reserves that domain for design-time artifacts rather than runtime infrastructure.

Service Consumption domain

Why it fails: The Service Consumption domain covers the user-facing aspects of services, such as subscriptions, entitlements, and user devices. It does not include backend infrastructure like database servers. Placing a database server here would confuse the consumption layer with the underlying technical foundation, leading to incorrect reporting and relationship mapping.

Human Resources domain

Why it fails: Human Resources is not a CSDM domain. CSDM focuses on services, applications, and infrastructure, not on HR functions. Although HR services might be represented in the service catalog, the CSDM framework does not define an HR domain. Including it would be incorrect as it falls outside the scope of CSDM's defined domains.

Financial Management domain

Why it fails: Financial Management is not a formal CSDM domain. While financial data such as cost and chargeback can be associated with services, CSDM does not define a separate domain for financial management. Instead, financial aspects are handled through other ServiceNow modules like ITFM, which may integrate with CSDM but are not part of its domain structure.

Security Operations domain

Why it fails: Security Operations is not a formal CSDM domain. While security CIs and relationships may be managed in the CMDB, CSDM does not define a separate Security Operations domain. Security-related data is typically integrated through other means, and the CSDM framework's domains are focused on service design, delivery, consumption, and management, not on security operations as a distinct domain.

Service Consumption domain

Why it fails: The Service Consumption domain represents the consumer's view, including subscriptions and entitlements. It does not include business application CIs. Business applications are part of the provider's design and management, not the consumer's consumption. Thus, placing a business application in this domain would be incorrect and would not support proper service modeling.

Service Management domain

Why it fails: The Service Management domain contains technical infrastructure CIs like servers and databases, not business applications. While business applications rely on infrastructure, they are not themselves infrastructure. Therefore, a business application CI should not be placed in the Service Management domain, as it would confuse the logical design layer with the physical runtime layer.

Service Delivery domain

Why it fails: The Service Delivery domain is focused on the delivery of services to consumers, including the service catalog and request management. It does not contain business application CIs. Business applications are design-time artifacts that belong in the Design domain. Placing a business application in the Service Delivery domain would misalign it with its intended purpose and disrupt the logical design layer.

Design

Why it fails: Design covers modelling service and technical architecture, not foundational organisational and user data. It is tempting because Design does hold people and organisational records once services exist, but the stem specifies populating basic data before linking technical infrastructure — that foundational layer belongs to Foundation, not Design.

Sell/Consume

Why it fails: Sell/Consume covers products, services, contracts and consumption data, not the foundational organisational and user records the team wants first. It is tempting because customer and user data feel related, but CSDM places company, business unit and employee data in the Foundation domain, which must be populated before technical infrastructure.

Manage Technical Services

Why it fails: Foundational organisational and user data belongs to the Foundation domain, which holds company, account and user records; Manage Technical Services covers infrastructure like applications and servers. It tempts because technical services are the eventual consumers of that data, but populating them first reverses the intended CSDM crawl-walk-run sequence.