CMDB practice questions

Access Control Lists (ACLs)

Why it fails: ACLs secure table and field access for user roles, not automated data source priority hierarchies in the IRE.

CI Class Manager Identification Rules

Why it fails: Identification rules handle matching and CI creation, whereas reconciliation rules handle attribute-level update permissions.

Data Source Precedence Rules

Why it fails: Data Source Precedence is not a standalone ServiceNow feature name; Reconciliation Definitions is the correct mechanism.

Discovery Definition > Network Classifications

Why it fails: Discovery Definition is used for probes, sensors, and patterns, not class-level identification hierarchy.

CMDB Properties

Why it fails: CMDB Properties controls global system settings for the CMDB, not specific table-level classification rules.

CI Identifier Rules module

Why it fails: The CI Identifier Rules module manages identification rules for deduplication, not the initial classification mapping.

Create a custom CMDB Data Manager policy to merge duplicates automatically.

Why it fails: CMDB Data Manager handles lifecycle operations like archiving and attestation, not real-time IRE payload deduplication based on case sensitivity.

Set the Reconciliation Rule to discard updates from the secondary data source.

Why it fails: Reconciliation rules control attribute-level updates, not duplicate prevention caused by case discrepancies.

Modify the Identification Rule weight to a higher number.

Why it fails: Rule weight determines which rule takes precedence when multiple rules match, not how attribute values are compared.

It flags the payload in the IRE Error Dashboard as an identification conflict requiring manual resolution.

Why it fails: Attribute updates to non-key fields do not trigger an identification conflict error unless strict uniqueness fails.

It creates a new CI record because the IP address attribute does not match the historical value.

Why it fails: Creating a new record would defeat the purpose of identification rules, which are designed to update existing matching instances.

It deletes the existing CI and inserts a new one with the updated attributes.

Why it fails: Deleting and re-inserting breaks related incident and change history linked to the CI sys_id.

Table Builder on cmdb_ci_linux_server

Why it fails: While Table Builder works, CI Class Manager is the recommended best practice framework for CMDB class customizations.

System Definition > Custom Fields

Why it fails: There is no standard 'Custom Fields' module under System Definition for CMDB class attributes.

Dictionary Editor on cmdb_ci

Why it fails: The Dictionary Editor on cmdb_ci adds the column to the parent class, so every child CI inherits it, including Windows and network devices. Targeting cmdb_ci_linux_server scopes the attribute correctly to Linux servers alone, matching the requirement.

Setting the Reconciliation Rule action to 'Cascade Delete'.

Why it fails: Reconciliation rules govern attribute updates, not payload-driven deletions.

Enabling 'Auto-Delete' on the Data Source transform map properties.

Why it fails: Transform maps do not have an 'Auto-Delete' property specifically designed for IRE payload processing.

Configuring the CI Class Manager to purge orphans automatically.

Why it fails: Orphan purging handles relationship gaps, not direct deletions from an external source payload.

The IRE averages the weights and creates a new CI if the combined score is below 75.

Why it fails: Weights determine rule precedence when multiple rules exist, not algorithmic scoring of entries within a single rule.

The IRE rejects the payload because conflicting matching criteria are defined within the same rule.

Why it fails: Multiple entries in an identification rule are fully supported to handle different hardware matching scenarios.

Dependency View Auto-Heal Business Rule

Why it fails: There is no out-of-the-box 'Auto-Heal Business Rule' for dependency views.

Dynamic CI Group query rules

Why it fails: Dynamic CI Groups populate service members based on query criteria, but do not automatically rewrite custom manual relationships.

CMDB Data Manager relationship synchronizer

Why it fails: CMDB Data Manager handles lifecycle policies, not real-time network or application relationship mapping.

Security

Why it fails: Security vulnerabilities are tracked via Vulnerability Response, not CMDB health pillars.

Availability

Why it fails: Availability is an ITSM/ITOM metric tracked via service health dashboards, not a CMDB health pillar.

Performance

Why it fails: Performance is an infrastructure monitoring metric, not a CMDB Health pillar.

sys_user

Why it fails: sys_user is part of User Administration, not the CMDB.

incident

Why it fails: incident is part of Task management, not the CMDB.

ast_contract

Why it fails: ast_contract is part of Asset Management financial contracts.

Staleness

Why it fails: Staleness is categorized under the Compliance pillar, not Correctness.

Required fields populated

Why it fails: Required fields populated is a Completeness metric.

Run the 'Merge Duplicate CIs' scheduled job from the CMDB module.

Why it fails: There is no standard scheduled job named 'Merge Duplicate CIs' in the CMDB module. Duplicate remediation is typically performed through the CMDB Health Dashboard's duplicate metrics or by using the Identification and Reconciliation Engine's merge capability. Relying on a non-existent job would not fix the duplicates.

Use the CMDB Duplicate CI Remediator to merge the duplicate CIs into the correct ones.

Why it fails: The CMDB Duplicate CI Remediator is a feature that helps identify and remediate duplicate CIs, but it is not a standard tool in ServiceNow. The correct approach is to use the CMDB Health Dashboard's duplicate remediation or the Identification and Reconciliation Engine's merge functionality. Using a non-existent tool would not resolve the issue.

Manually delete the duplicate CIs and update the relationships on the correct CIs.

Why it fails: Manually deleting duplicates and updating relationships is time-consuming and error-prone. It does not leverage the automated capabilities of IRE, which can merge records while preserving relationships and history. This approach risks data loss and inconsistency, and it is not the recommended practice for duplicate remediation.

Service Mapping

Why it fails: Service Mapping is used to discover and map application services and their underlying CIs. While it creates relationships, it does not automatically populate affected CIs on incidents. It provides the data that can be used for impact analysis, but the automatic population of affected CIs is handled by other features.

CMDB Health Dashboard

Why it fails: The CMDB Health Dashboard monitors the health of CMDB data but does not automate the population of affected CIs on incidents. It provides metrics and KPIs, not operational automation for task records. Therefore, it is not the correct feature for this scenario.

CI Relationship Editor

Why it fails: The CI Relationship Editor is a tool for manually creating and editing relationships between CIs. It does not automate the population of affected CIs on incident records. Its purpose is to maintain the relationship data, not to drive incident fields.

Depends on::Used by

Why it fails: Depends on::Used by is a relationship type used to indicate that one CI depends on another for its operation, such as an application depending on a server. However, in this scenario, the load balancer does not depend on the web servers; it routes traffic to them. The relationship is more about connectivity or membership, so this type is not the most accurate representation.

Runs on::Runs

Why it fails: Runs on::Runs is used when an application or service runs on a server or operating system. The load balancer is not running on the web servers; it is a separate device that distributes traffic. This relationship would misrepresent the dependency, as it implies the load balancer is hosted on the web servers, which is not the case.

Contains::Contained by

Why it fails: Contains::Contained by indicates a containment relationship, such as a server containing an application or a rack containing servers. The load balancer does not contain the web servers; they are separate entities. Using this relationship would incorrectly imply a hierarchical structure that does not exist, leading to inaccurate impact analysis.

Orphans (Correctness metric)

Why it fails: Orphans measure CIs lacking a required relationship to another CI, not elapsed time since update or verification. The metric tracking staleness is CMDB Health's Audit/Completeness age-based measure. Orphans would be the right metric when the concern is disconnected CIs with no parent or dependency link.

Audit (Completeness metric)

Why it fails: Audit completeness checks whether required CI attributes are populated, not whether records were recently updated or verified. It is tempting because both are CMDB Health completeness metrics, but staleness over 90 days is measured by the Audit metric for recency of updates and verification.

Duplicate CIs (Correctness metric)

Why it fails: Duplicate CIs measure multiple records representing the same real-world item, a data-integrity problem, not elapsed time since last update or verification. The 90-day staleness requirement is addressed by the Audit metric. Duplicates would be correct when reconciling overlapping discovery sources creating redundant CI records.

Relationship Builder

Why it fails: Relationship Builder creates and edits individual CI relationships; it does not display the full graphical hierarchy of a Business Service and its servers. It is tempting because it concerns relationships, but the read-only dependency view is the CI Relationship Map, which Builder feeds rather than replaces.

CMDB Dashboard

Why it fails: The CMDB Dashboard presents aggregate health, metrics and compliance counts across the CMDB, not the dependency tree of one CI. It is tempting because it visualises CMDB data, but viewing a Business Service's graphical relationship hierarchy requires the CI Relationship Map on the record itself.

CI Class Manager

Why it fails: CI Class Manager defines class schemas, attributes and identifiers; it does not render a service's dependency tree. It is tempting because it governs CI structure, but the graphical hierarchy of a Business Service and its servers is displayed by the CI Relationship Map opened from the CI record.

It causes ServiceNow to automatically reject all incoming records due to missing UI policies.

Why it fails: Direct inserts bypass IRE, so duplicate or orphaned CIs accumulate and reconciliation never runs; ServiceNow does not reject records for missing UI policies, which apply to forms, not table inserts. The option tempts by invoking a real ServiceNow concept, but UI policies are irrelevant to scripted inserts.

It prevents the CIs from ever being viewed in the Dependency View.

Why it fails: Bypassing the IRE means duplicate CIs accumulate, since the engine's identification rules and reconciliation are what merge and de-duplicate incoming records. Dependency View rendering is unrelated to insertion method; it simply maps existing relationships. This option would be correct if the script created CIs correctly but omitted relationship records, leaving the map empty.

It triggers an infinite loop in the Discovery pattern engine.

Why it fails: Bypassing IRE leaves duplicate CIs unreconciled; the pattern engine is not involved in direct table inserts, so no loop occurs. Discovery patterns populate CIs through IRE, where recursion safeguards exist. This option would fit a scenario describing circular pattern dependencies during scheduled discovery runs.

Dependency View Configurator

Why it fails: Dependency View Configurator controls how existing dependency maps are displayed in the Dependency Views interface, not the creation of relationship type records. It tempts because it concerns dependencies visually, yet defining a new hardware-to-business-application relationship type happens in the CI Class Manager's Relationship Type module.

CI Relationship Rules

Why it fails: CI Relationship Rules govern which relationships are suggested or permitted between CI classes; they reference existing relationship types rather than creating new ones. It tempts because rules shape CI dependencies, but the new hardware-to-business-application relationship type itself must be defined in the CI Class Manager.

CMDB Groups

Why it fails: CMDB Groups organise CIs into logical collections for filtering and reporting; they do not define relationship type records between classes. It tempts as a way to group hardware and business application CIs together, but creating a new dependency type requires the Relationship Type module in the CI Class Manager.

CI Class Manager > Overview

Why it fails: CI Class Manager shows class-specific configurations rather than global CMDB health scores.

System Definition > Health Log

Why it fails: System Definition does not contain CMDB health dashboards.

Discovery > Health Metrics

Why it fails: Discovery has its own status dashboards, but CMDB Health is housed under the Configuration application.

A CI that has not been updated by any discovery source or manual import in over 90 days.

Why it fails: Orphan CIs are defined by missing relationships, not by staleness of updates; the 90-day criterion belongs to the Staleness metric. Age-based checks would be correct when assessing whether discovery is keeping CI attributes current, not when measuring correctness.

A CI record that shares the exact same serial number and name as another active CI record.

Why it fails: Duplicate serial number and name describes a duplicate CI, not an orphan. An orphan CI is one with no relationship to any other CI, so it sits isolated in the CMDB. Duplicate detection is a separate Correctness metric, making this tempting when reviewing data-integrity scores.

A CI whose assigned support group or managed-by user no longer exists in the sys_user table.

Why it fails: A missing support group or managed-by user is a data-integrity issue counted under the Correctness metric's invalid references, not orphan status. Orphan CIs lack required relationships to other CIs; this option would be correct when detecting broken user or group references.