CMDB Integration And Maintenance practice questions

Custom data sources require a new Identification Rule for every CI class.

Why it fails: Identification rules are generally class-agnostic or hierarchical, not per-source.

IRE ignores data sources that are not explicitly defined in the Identification Rules.

Why it fails: IRE processes data from any source that provides a valid payload.

Discovery always has higher priority than manual CMDB updates by default.

Why it fails: Priority is configurable and not always weighted towards Discovery.

Increase the Discovery timeout value

Why it fails: Timeouts address performance, not data mapping issues.

Modify the MID Server cluster configuration

Why it fails: MID clustering is for load balancing, not attribute data flow.

CMDB Health Dashboard

Why it fails: CMDB Health Dashboard reports on data compliance, duplicates and orphan metrics; it does not intercept or block incoming Discovery payloads, so a null serial still overwrites the manual value. It is tempting because health dashboards do surface stale or missing attribute data, and would be the right tool for monitoring such overwrites after the fact.

Discovery Pattern Pre/Post scripts

Why it fails: Pre/post scripts transform or enrich payload fields within a pattern run, but they do not arbitrate whether a discovered null should replace an existing manual value during reconciliation. They are tempting because patterns control what Discovery collects, and scripting is the usual answer for shaping attribute values before they reach the CMDB.

MID Server Capabilities

Why it fails: MID Server capabilities determine which probe and pattern types a MID can execute, such as SSH or WMI, and have no bearing on how attribute values are merged into existing CIs. They are tempting because MID configuration genuinely governs what Discovery can collect, so capability mismatches do cause missing or failed data collection.

Discovery > Properties

Why it fails: While properties exist, they are not the primary mechanism for restricting CI class population.

Discovery Definition > CI Classifications

Why it fails: This defines how to identify devices, not the global restriction of CI creation.

CMDB Health > Dashboard

Why it fails: The dashboard provides monitoring, not configuration of CI creation rules.

Create an ACL for the CMDB Health table.

Why it fails: ACLs control access, not dashboard data inclusion.

Restart the Discovery services.

Why it fails: Restarting services does not update dashboard configurations.

Run a full Discovery of the entire environment.

Why it fails: Discovery does not control dashboard reporting scope.

Discovery Home

Why it fails: Discovery Home is for monitoring status, not business service mapping.

CMDB Health Dashboard

Why it fails: CMDB Health Dashboard reports on data quality — completeness, correctness and compliance — across existing CIs; it creates no relationships and performs no mapping during discovery. It is tempting because it visualises CI and relationship gaps, so it would be the right choice when auditing whether discovered CIs already link to business applications, not for automating that linkage.

Identification and Reconciliation Engine (IRE)

Why it fails: IRE matches discovered CIs against existing records to prevent duplicates, but it does not map CIs to business applications. It is tempting because IRE governs CI identification and reconciliation during discovery, which is genuinely the right choice when the requirement is deduplicating CIs or enforcing identification rules across data sources.

Check the MID server's CPU usage.

Why it fails: MID server health doesn't specifically prevent update timestamps.

Update the Discovery Pattern definition.

Why it fails: Patterns collect data; the framework handles the timestamping.

Verify the network connectivity to the targets.

Why it fails: If the schedule runs successfully, connectivity is likely established.

CI relationship graph

Why it fails: The CI relationship graph shows dependencies between CIs, not which data source last wrote each attribute, so it cannot identify the authoritative source. It is tempting because it visualises CI context, and it would be correct for impact analysis across related configuration items.

Discovery schedule settings

Why it fails: Discovery schedule settings define when and what discovery runs, not per-attribute source precedence, so they cannot reveal which source updated a CI. They are tempting because schedules control discovery behaviour, and they would be correct for adjusting discovery timing or scope.

Discovery log

Why it fails: The Discovery log records discovery run activity and errors, not attribute-level source precedence, so it cannot show which data source owns an attribute. It is tempting because it traces discovery execution, and it would be correct for troubleshooting why a discovery run failed.

Running more frequent discovery scans.

Why it fails: Correctness measures CIs failing validation against class rules, not staleness; scan frequency addresses the Completeness metric instead. It is tempting because frequent discovery feels like better data, but it cannot fix CIs that violate mandatory field or audit rules.

Adding more fields to the CI classes.

Why it fails: Adding fields expands the schema rather than correcting existing CI data, and new fields may themselves fail validation. It is tempting because richer classes seem to improve accuracy, but Correctness requires fixing values that breach class audit and mandatory-field rules.

Create a unique identification rule for every single CI instance.

Why it fails: Identification rules match incoming records to existing CIs; creating one per CI instance defeats that matching and guarantees duplicates. It is tempting because unique identifiers feel rigorous, and per-class identification rules would be correct for distinguishing CI types during reconciliation.

Use the CI's 'Name' field as the primary unique identifier.

Why it fails: Names are not guaranteed unique, so using the Name field as the primary identifier permits duplicate CIs and broken relationships; identification relies on discovery source plus unique keys such as serial number or sys_id. It tempts because names are human-readable and often unique in small datasets, but that is coincidence, not a reliable identification strategy.

Performance

Why it fails: Performance is not a CMDB health metric.

Availability

Why it fails: Availability is an IT Operations metric, not a CMDB Health metric.

MID Server log

Why it fails: This shows connectivity issues, not the data payload content.

CMDB Health Dashboard

Why it fails: This is a reporting tool, not a logging tool.

System Log

Why it fails: System logs show general errors, not payload-level data.

Change the class to 'Internal'.

Why it fails: This is not a functional CMDB configuration.

Remove the attribute from the discovery pattern.

Why it fails: This prevents Discovery from updating it, but doesn't handle the 'Manual' requirement.

Create a business rule that runs after insert/update.

Why it fails: While possible, it is not the standard CMDB-native configuration for attribute authority.

The CI Class is not in the Discovery Schedule.

Why it fails: If the class were missing, Discovery would fail to classify it entirely.

The 'Sync' flag is disabled in the Discovery Schedule.

Why it fails: There is no 'Sync' flag in a Discovery Schedule.

The Discovery Pattern is set to 'Create' mode.

Why it fails: Patterns do not have a 'Create' mode; they simply output data for the IRE.

CMDB Transform Maps

Why it fails: Transform maps convert incoming integration payloads into CMDB records but do not protect manually edited fields from overwrite. They are tempting because they govern how discovery data maps to CI attributes, and they are correct when the requirement is field-level mapping or coalescing during import.

Discovery Access Control Lists (ACLs)

Why it fails: ACLs restrict who can read or write records; they do not stop a discovery source from overwriting manually updated CI attributes. They are tempting because access control sounds protective, and ACLs are correct when the requirement is limiting which users or roles can modify CMDB records.

Data Preserver

Why it fails: Data preservers protect data during system upgrades, not during discovery runs.

MID Server capacity

Why it fails: Capacity issues would cause timeouts, not partial data extraction.

Discovery Schedule timing

Why it fails: Timing does not affect the content of the data payload.

Discovery Error Log

Why it fails: Errors usually show communication issues, not relationship mapping failures.

Business Rule on the CI table

Why it fails: Business rules can do this, but they are not the standard Discovery-to-CMDB configuration method.

Discovery Pattern Step: 'Update only if empty'

Why it fails: Patterns do not have a built-in step for this conditional logic.

Reconciliation Rule Priority

Why it fails: Priority determines which data source wins, not if an update occurs based on field state.

Disable 'Discovery' in the CI Class identification rule.

Why it fails: This would prevent Discovery from updating the CI entirely, not just specific attributes.

Use a Business Rule to intercept the discovery payload.

Why it fails: This is not the recommended way to manage data precedence.

Set the discovery source priority to 100 and the third-party source to 200.

Why it fails: Lower numbers indicate higher priority in ServiceNow reconciliation rules.

Delete the CI record from the database.

Why it fails: Deleting records is bad practice as it destroys historical audit trails.

Clear the 'Last discovered' field.

Why it fails: This does not prevent future discovery.

Change the CI class to 'Archive'.

Why it fails: 'Archive' is not a standard CMDB class type.

Stale CIs

Why it fails: This is a separate category from correctness.

Expired credentials

Why it fails: This is an operational discovery metric, not a CMDB health metric.

Missing critical attributes

Why it fails: This is a 'Completeness' metric.