Select Two (Multi-Select) Questions

Set all transform maps to coalesce on the sys_id field.

Why it fails: Coalescing on sys_id prevents Discovery from matching existing CIs, because sys_ids differ per record and are never present in probe payloads; Discovery coalesces on identification attributes such as serial number, name, or IP. sys_id coalescing suits importing records exported from the same instance.

Create custom Business Rules on cmdb_ci to simulate Service Mapping.

Why it fails: Business Rules on cmdb_ci do not perform Service Mapping's topology discovery; Service Mapping uses patterns and traffic-based connections, not scripted simulation. Discovery ingestion needs MID Server, credentials, and schedules. Custom Business Rules suit enforcing field validation or defaults, not replicating mapping engines.

Disable the Identification and Reconciliation Engine globally to speed up server creation.

Why it fails: Disabling IRE removes identification and reconciliation, so discovered servers duplicate or fail to merge with existing CIs, breaking CMDB accuracy. IRE must stay enabled for Discovery ingestion. Disabling it suits isolated test instances where deduplication is deliberately unwanted, never production discovery.

It represents internal technical infrastructure server CIs.

Why it fails: Foundation covers conceptual entities shared across the enterprise — business capabilities, services, and application models — not infrastructure server CIs. Server CIs belong in the Infrastructure domain, which extends Foundation with technical components. Selecting this confuses the domain boundary between conceptual shared entities and deployed technical infrastructure.

It represents consumer-facing catalog offerings.

Why it fails: Consumer-facing catalog offerings sit in the Sell/Consume domain, which models products, offerings, and catalog items presented to customers. Foundation instead holds conceptual entities reused across domains, such as business capabilities and service models. This option mistakes commercial catalog content for the enterprise-wide conceptual layer.

It represents deployable runtime software instances.

Why it fails: Deployable runtime software instances belong in the Infrastructure domain, which captures technical components and deployed artefacts. Foundation holds conceptual entities like business capabilities and application models that other domains reference. Choosing this misplaces runtime deployment detail into the conceptual shared layer.

Disable CMDB Health audits globally before creating the class table.

Why it fails: CMDB Health audits run independently of class table creation and disabling them globally removes governance without aiding the new hierarchy. It tempts as a way to avoid audit noise during rollout, but best practice is defining the class hierarchy correctly, not switching off health checks.

Always extend the root cmdb table directly to maximize attribute availability.

Why it fails: Extending the root cmdb table directly forces every custom class to inherit all base attributes, bloating tables and breaking scoped hierarchy design. It tempts because the root offers maximum attribute availability, but best practice extends an existing appropriate class or creates a scoped hierarchy beneath it.

Create custom relationships directly on the cmdb table dictionary.

Why it fails: Custom relationships belong on the relationship table, not the cmdb table dictionary, which stores class attributes rather than relationship definitions. It tempts because the cmdb table underpins CI storage, but relationship types are created separately and applied to the relevant classes.

Deploy

Why it fails: CSDM's recognised lifecycle phases are Crawl, Walk, Run and Fly; Deploy is not one of them. Deploy is tempting because it is a common ITSM or DevOps stage name, but CSDM maturity describes data-model adoption progression, not release or deployment activity.

Sprint

Why it fails: Sprint is an agile delivery cadence, not a CSDM maturity phase; the recognised phases are Crawl, Walk, Run and Fly. It is tempting because maturity work is often delivered iteratively in sprints, but the framework names data-model adoption stages, not project ceremonies.

Managing user authentication sessions for inbound REST API calls.

Why it fails: RTE transforms and reconciles inbound CMDB data during import; it does not manage authentication sessions for REST API calls, which the REST API and authentication mechanisms handle. It is tempting because RTE does process inbound data feeds, and would be correct if the requirement concerned mapping, coalescing or normalising source records.

Replacing the underlying relational database management system with an in-memory graph store.

Why it fails: RTE transforms and normalises inbound CMDB data through scripted mapping and merge logic; it does not swap the platform's persistence layer. The underlying database remains unchanged. This option describes replacing the relational store with an in-memory graph engine, which is a deployment architecture decision, not an RTE ingestion capability.

Automatically generating ITSM Change Requests for every ingested CI.

Why it fails: RTE transforms inbound CMDB data through mapping, coalesce and scripted logic; it holds no integration with ITSM change workflows, so it cannot raise Change Requests. It tempts because automated change creation is a genuine requirement in many CMDB programmes, but that is delivered by IntegrationHub spokes or Flow Designer, not by the transform engine.

Directly modify core IRE Identification Rules for hardware classes

Why it fails: The dashboard surfaces health scores, drill-down lists and remediation tasks; it does not expose IRE identification rule configuration. Identification rules are edited in the IRE configuration module, which is the right place when tuning how CIs are matched and merged.

Permanently delete all duplicate CIs across the entire enterprise with a single click

Why it fails: The dashboard offers no bulk enterprise-wide deletion; duplicate remediation runs through de-duplication tasks with review. Single-click mass deletion would bypass the reconciliation safeguards that prevent removal of CIs with relationships, so it is reserved for controlled de-duplication workflows.

Modify MID Server cluster configurations

Why it fails: MID Server cluster settings live in the MID Server and ECC Queue configuration, not the CMDB Health Dashboard, which reports data quality rather than infrastructure. Cluster tuning is correct when addressing discovery throughput or failover, not when investigating health metrics.

CMDB Health Dashboard compliance staleness scorecards

Why it fails: Staleness scorecards belong to the CMDB Health Dashboard, which reports data completeness, correctness and compliance. It is tempting because Service Mapping also feeds CMDB data quality, but its visualisation and insights concern discovered application service topology and dependency mapping, not health scorecards.

Automated CMDB duplicate CI merging wizards

Why it fails: Duplicate CI merging is a CMDB data-hygiene function performed through Identification and Reconciliation Engine rules, not Service Mapping. It is tempting because Service Mapping populates the CMDB with CIs, yet its visualisation and insights deliver dependency maps and impact views, not deduplication wizards.

CMDB Baseline configuration diff snapshots

Why it fails: Baseline configuration diff snapshots are a Configuration Management Database change-tracking feature, unrelated to Service Mapping. It is tempting because both concern CI configuration data, yet Service Mapping visualisation and insights produce service dependency maps and traffic-based topology, not baseline comparisons.

Automated merging of duplicate hardware records

Why it fails: Duplicate merging is handled by the CMDB Duplicate Remediation wizard, not Query Builder.

Real-time execution of Service Mapping patterns on demand

Why it fails: Service Mapping executes patterns, not Query Builder.

Creating custom database views across unrelated application tables.

Why it fails: CI Class Manager governs class hierarchy, attributes, identifiers and reconciliation, not database view creation across unrelated tables. It is tempting because the tool does expose class schema, yet custom views belong to database view configuration, which would be correct when building cross-table reporting joins.

Writing custom JavaScript business logic to execute during Discovery credential checks.

Why it fails: CI Class Manager configures class hierarchy, attributes and reconciliation rules; it does not host Discovery credential-check scripts. It is tempting because class behaviours are edited there, but JavaScript credential logic belongs to Discovery credentials and probes, correct when customising credential validation during horizontal discovery.

CMDB Data Manager archival policy execution logs

Why it fails: CMDB Data Manager archival policy execution logs record when stale CIs were retired or archived, and never appear as indicators on a Service Mapping map. It is tempting because both features concern CMDB data lifecycle, but archival logs would be the right place to audit retention-policy runs, not to view map statuses.

Individual user session password expiration alerts

Why it fails: Password expiration alerts for individual user sessions belong to identity and credential management, and are not rendered on a Service Mapping map. It is tempting because authentication failures can break discovery and mapping, but such alerts would be the correct source when troubleshooting a user's login, not map indicators.

Financial asset depreciation schedules and contract end dates

Why it fails: Service Mapping maps application service topology, showing CI relationships, connection statuses and traffic-based dependencies; it does not surface financial depreciation or contract data, which belong to asset and contract management records. It is tempting because those fields exist on CIs, but they are never rendered on a service map.

Data Source Precedence only applies to data ingested via legacy Import Sets without Transform Maps.

Why it fails: Data Source Precedence applies to all data sources feeding the CMDB, including IRE and Transform Map ingests, not only legacy Import Sets without Transform Maps. It is tempting because legacy Import Sets are a genuine data source type, but the statement wrongly narrows the feature's scope.

Data Source Precedence automatically deletes CIs that have not been updated by a high-priority source within 30 days.

Why it fails: Data Source Precedence only ranks which source wins when reconciling a CI's attribute values; it never deletes stale records. Age-based retirement is handled by CMDB Data Manager policies or scheduled cleanup jobs, which is the tempting overlap that makes this option look plausible.

Data Source Precedence rules replace the need for Identification Rules in the IRE.

Why it fails: Precedence rules resolve attribute conflicts after the IRE has already identified and merged CIs; Identification Rules determine which records represent the same CI in the first place. Both run in sequence, so precedence cannot substitute for identification — a tempting conflation because both are configured on the same CI class.

Editing ACL rules on the cmdb_ci table

Why it fails: ACLs on cmdb_ci control record read, write and delete access, not data ownership assignment; ownership is set via CI ownership fields or ownership lookup rules. It is tempting because ACLs govern who can modify CIs, so they would be the right choice for restricting access rather than assigning accountable owners.

Modifying Discovery behavior patterns to inject custom firewall rules

Why it fails: Discovery behaviour patterns inject custom firewall rules during horizontal discovery, affecting what CIs and attributes are found, not who owns them. It is tempting because Discovery populates the CMDB, so it would be correct for controlling discovery traffic and probe behaviour rather than assigning data ownership.

Adjusting Discovery schedule probe frequency

Why it fails: Discovery schedule frequency controls how often probes run and has no bearing on ownership fields; ownership is assigned through CI class owner attributes or CMDB groups. It is tempting because Discovery populates CIs, but scheduling governs refresh cadence, not accountability data.

Using the Identification and Reconciliation Engine for all automated imports.

Why it fails: IRE's reconciliation logic can overwrite recently updated records with older source data, but it does not itself create staleness; staleness arises from ingestion frequency, not reconciliation. It is tempting because IRE is the correct choice for deduplicating and merging records across discovery sources, where conflicting CI attributes must be resolved.

Ingesting data exclusively through certified Service Graph Connectors.

Why it fails: Certified Service Graph Connectors are the recommended, supported ingestion method and generally improve data quality and freshness rather than causing staleness. It is tempting to suspect them because they are third-party integrations, but staleness typically stems from manual imports, infrequent scheduled jobs or unreconciled source data.

Configuring robust Data Source Precedence rules for all attributes.

Why it fails: Data Source Precedence rules determine which source's value wins for an attribute; they do not control record refresh timing, so they neither cause nor reduce staleness. It is tempting because precedence governs data quality, and it would be correct if the question asked how to resolve conflicting attribute values from multiple discovery sources.

It is used to configure CSDM technical service offerings and portfolios.

Why it fails: Dependency Views visualise CMDB relationship maps; they do not configure CSDM technical service offerings or portfolios, which are defined through the CSDM framework's service portfolio records. The option tempts because Dependency Views do surface CSDM-aligned service data, but configuration happens in ServiceNow's CSDM tables, not the visualisation itself.

It automatically executes network ping commands on every node during map rendering.

Why it fails: Dependency Views renders topology from discovered configuration and relationship data held in the CMDB; it performs no active network probing such as ping during rendering. Ping sweeps belong to discovery or network-mapping tools that actively scan subnets, which would be the right choice when live reachability data is required.

Service Mapping horizontal pattern criteria.

Why it fails: Service Mapping horizontal pattern criteria govern discovery of application services, not REST ingestion into the CMDB. The IRE requires identification and reconciliation rules configured on the target table, plus a data source, so pattern criteria satisfy neither component. It would be correct when defining how Service Mapping discovers and maps application services across the estate.

Discovery schedule IP ranges matching the REST server IP.

Why it fails: Discovery schedules and IP ranges drive agentless horizontal discovery, not REST ingestion. The IntegrationHub REST step needs a REST message with endpoint and authentication, plus the IRE payload mapping to identify and reconcile CIs. IP ranges would be the right configuration when scanning network segments for discovered devices instead.

Legacy Transform Map record definitions linked to the REST endpoint.

Why it fails: IntegrationHub IRE payloads operate independently of legacy transform maps.

Creating a relationship automatically deletes both CIs if one is updated.

Why it fails: Relationships are independent records linking two CIs; updating or deleting one CI does not cascade-delete the other. It tempts because cascade behaviour exists elsewhere, but relationship records are the correct mechanism when you need to model dependencies without altering either CI's lifecycle.

A CI can only participate in a single relationship across the entire CMDB.

Why it fails: A CI participates in many relationships simultaneously — a server hosts applications, connects to switches, and depends on databases — so a single-relationship limit contradicts the CMDB's dependency-mapping purpose. The statement is tempting because relationship records are individually unique, but that uniqueness applies per pair, not per CI.

Relationships and reference fields (like 'Assigned to') function in the exact same manner.

Why it fails: Relationships are separate records with their own table and types, while reference fields store a direct pointer on the CI record itself. It tempts because both link CIs, but reference fields are correct when you need a single owning value, whereas relationships model many-to-many dependencies.

Configure Service Level Agreements (SLAs) for incident resolution

Why it fails: SLAs are configured in SLA Management and applied to incident, problem or change workflows, not within CI Class Manager, which governs class attributes, identifiers and reconciliation rules. It is tempting because SLAs reference CIs, but they are service-management records, not class definitions.

Schedule and execute Discovery network scans

Why it fails: Discovery scans are scheduled and run from the Discovery module or scan scheduler, not CI Class Manager, which defines class hierarchies, attributes and identification rules. It is tempting because Discovery populates the CMDB with CIs, but scan configuration lives outside class definition.

Build graphical multi-table CMDB queries

Why it fails: Graphical multi-table queries are built in the Query Builder or CMDB reporting tools, not CI Class Manager, which defines class schema, attributes and identification rules. It is tempting because both operate on CMDB data, but query construction is a separate reporting function.

The CI is automatically retired from the database immediately

Why it fails: Certification tasks gather verification; they do not automatically retire CIs unless specified by custom workflow actions.

A high-priority incident is automatically created for the IT service desk

Why it fails: A Data Certification task routes findings to the CI owner for attestation; it does not raise an incident, because certification is a governance workflow, not ITSM alerting. Incident creation belongs to Event Management, where an alert rule on a CI triggers one — the correct choice here is the certification task itself.

Availability

Why it fails: Availability is not tracked out-of-the-box by the CMDB Health Dashboard, whose metrics address data quality rather than service uptime. It is tempting because availability underpins service management reporting, and it would be the right metric within service-level or event management dashboards.

Performance

Why it fails: Performance is not one of the out-of-the-box CMDB Health Dashboard metrics, which cover completeness, correctness, compliance, and duplicates rather than runtime behaviour. It is tempting because performance monitoring matters operationally, and it would be tracked in service-level or application-performance tooling instead.

Bandwidth

Why it fails: Bandwidth measures network throughput, not configuration item health, so it cannot appear on the CMDB Health Dashboard, which scores completeness, correctness, compliance and duplicate metrics against CI records. It is tempting because bandwidth is a genuine infrastructure metric, but it belongs in performance monitoring tools, not CMDB data-quality scoring.

Security

Why it fails: Security is not one of the three CMDB Health Dashboard components (Completeness, Correctness, Compliance, plus relationship and duplicate metrics). It is tempting because security posture matters in configuration management, but security is assessed through separate compliance and audit tooling, not the health dashboard's data-quality KPIs.

Performance

Why it fails: Performance is not a CMDB Health Dashboard component; the framework scores Completeness, Correctness and Compliance of configuration data. Performance monitoring belongs to APM and infrastructure tools. It tempts because service performance is operationally vital, yet the dashboard evaluates record quality, not runtime behaviour.