Scenario practice questions

You are troubleshooting a scenario where Discovery is creating duplicate CIs for the same server. Which table should you inspect to verify the Identification Rule settings for the specific CI class?

Trap 1: discovery_device_history

The discovery_device_history table logs device-level Discovery activity and status, not the identification criteria that decide whether an incoming record matches an existing CI. It is tempting because it is genuinely useful for auditing what Discovery touched and when, which suits tracking failed or skipped devices rather than diagnosing duplicate CI creation.

Trap 2: sys_reconciliation_rule

The sys_reconciliation_rule table stores reconciliation rules that merge duplicate CI records after identification has already matched them, so it cannot explain why two CIs were created instead of one. It is the right place when tuning merge precedence and survivorship between already-identified duplicates.

Trap 3: cmdb_ci_relation

The cmdb_ci_relation table holds relationships between CIs, such as depends-on or runs-on links, and contains no identification criteria, so it cannot reveal why duplicate server records appear. It is the correct table when investigating missing or incorrect relationship mappings rather than duplicate CI creation.

A
cmdb_identifier_entry
The `cmdb_identifier_entry` table stores the identification rules that Discovery applies per CI class, so inspecting it reveals exactly which attribute combinations are being matched. Duplicates arise when those entries are misconfigured or missing, causing the same server to fail matching and create a new CI record instead.
B
discovery_device_history
Why it fails: The discovery_device_history table logs device-level Discovery activity and status, not the identification criteria that decide whether an incoming record matches an existing CI. It is tempting because it is genuinely useful for auditing what Discovery touched and when, which suits tracking failed or skipped devices rather than diagnosing duplicate CI creation.
C
sys_reconciliation_rule
Why it fails: The sys_reconciliation_rule table stores reconciliation rules that merge duplicate CI records after identification has already matched them, so it cannot explain why two CIs were created instead of one. It is the right place when tuning merge precedence and survivorship between already-identified duplicates.
D
cmdb_ci_relation
Why it fails: The cmdb_ci_relation table holds relationships between CIs, such as depends-on or runs-on links, and contains no identification criteria, so it cannot reveal why duplicate server records appear. It is the correct table when investigating missing or incorrect relationship mappings rather than duplicate CI creation.

Question 2mediummultiple choice

Why would you choose to use a 'Discovery Behavior' instead of the default behavior?

Trap 1: To update the CMDB identification rules.

CMDB identification rules are configured globally in the CMDB, independently of any Discovery Behavior, so this does not satisfy the requirement. It tempts because behaviours do control classification and CI creation during discovery, but identification rule precedence is set outside the behaviour itself.

Trap 2: To define the IP range for the discovery.

IP ranges belong to the discovery schedule's MID Server and target configuration, not to a Discovery Behavior, so this fails the scenario. It tempts because behaviours do scope which targets are probed, but the actual IP range is defined on the schedule that triggers discovery.

Trap 3: To change the schedule of the discovery.

Scheduling is configured on the discovery schedule record, not through a Discovery Behavior, so this fails the scenario. It tempts because behaviours and schedules are both edited from the same discovery configuration area, yet a behaviour governs which probes and credentials run against a target, not when the run occurs.

A
To update the CMDB identification rules.
Why it fails: CMDB identification rules are configured globally in the CMDB, independently of any Discovery Behavior, so this does not satisfy the requirement. It tempts because behaviours do control classification and CI creation during discovery, but identification rule precedence is set outside the behaviour itself.
B
To define the IP range for the discovery.
Why it fails: IP ranges belong to the discovery schedule's MID Server and target configuration, not to a Discovery Behavior, so this fails the scenario. It tempts because behaviours do scope which targets are probed, but the actual IP range is defined on the schedule that triggers discovery.
C
To limit or extend the probes used for specific discovery scenarios.
Discovery Behaviors let you attach a custom set of probes to a discovery schedule, overriding the default probe selection. This satisfies the stem's need to limit or extend probes for particular scenarios, such as excluding slow patterns or adding targeted ones.
D
To change the schedule of the discovery.
Why it fails: Scheduling is configured on the discovery schedule record, not through a Discovery Behavior, so this fails the scenario. It tempts because behaviours and schedules are both edited from the same discovery configuration area, yet a behaviour governs which probes and credentials run against a target, not when the run occurs.

Question 3hardmulti select

You are a ServiceNow Discovery administrator. You have been asked to ensure that the CMDB remains accurate and up-to-date when CIs are retired or decommissioned. Which two actions should you perform to maintain CMDB integrity in this scenario? (Choose two.)

Trap 1: Create a new CI with the same name but a different serial number to…

Creating a new CI with the same name but a different serial number is not a decommissioning action; it is for adding a new CI. This could lead to confusion if the name is not unique. For decommissioning, you should update the existing CI's status rather than create a new one. This option does not address the retirement of the old CI.

Trap 2: Run a discovery schedule to update the CI's attributes to reflect…

Running discovery on a decommissioned CI is not appropriate because the CI may no longer be accessible. Discovery would likely fail and could potentially mark the CI as missing or create errors. Decommissioning is a manual lifecycle action, not something discovery handles. Therefore, this is not a recommended action for maintaining CMDB integrity.

Trap 3: Delete the CI record from the CMDB to prevent it from appearing in…

Deleting a CI record is not recommended because it removes historical data and can break relationships with other CIs, leading to data integrity issues. It also makes it difficult to audit past configurations. Instead, retiring the CI is the preferred method. Deletion should be reserved for CIs created in error, and even then, careful consideration is needed.

A
Create a new CI with the same name but a different serial number to represent the replacement.
Why it fails: Creating a new CI with the same name but a different serial number is not a decommissioning action; it is for adding a new CI. This could lead to confusion if the name is not unique. For decommissioning, you should update the existing CI's status rather than create a new one. This option does not address the retirement of the old CI.
B
Use the CMDB CI Lifecycle Management to transition the CI to a retired state.
Using the CMDB CI Lifecycle Management to transition the CI to a retired state is a structured approach to decommissioning. It ensures that the CI goes through the proper lifecycle stages, updating its status and potentially triggering workflows. This maintains data integrity by keeping a record of the CI's lifecycle and ensuring that it is no longer considered active. It is a recommended practice.
C
Run a discovery schedule to update the CI's attributes to reflect its decommissioned state.
Why it fails: Running discovery on a decommissioned CI is not appropriate because the CI may no longer be accessible. Discovery would likely fail and could potentially mark the CI as missing or create errors. Decommissioning is a manual lifecycle action, not something discovery handles. Therefore, this is not a recommended action for maintaining CMDB integrity.
D
Set the CI's install status to 'Retired' and update the 'Retired' date.
Setting the install status to 'Retired' and updating the retired date is a best practice for decommissioned CIs. It indicates that the CI is no longer in use while preserving its historical data and relationships. This helps maintain CMDB integrity by preventing the CI from being considered active, while still allowing for auditing and reporting. It is a standard action for lifecycle management.
E
Delete the CI record from the CMDB to prevent it from appearing in reports.
Why it fails: Deleting a CI record is not recommended because it removes historical data and can break relationships with other CIs, leading to data integrity issues. It also makes it difficult to audit past configurations. Instead, retiring the CI is the preferred method. Deletion should be reserved for CIs created in error, and even then, careful consideration is needed.

Question 4mediummultiple choice

You are designing a Discovery pattern that runs a command on a Linux host and then parses the output to populate the 'CPU core count' field on the CI. The command's output contains multiple lines, and the relevant number appears on the same line as the label 'CPU(s):'. Which Pattern Designer step configuration should you use to reliably extract the numeric value?

Trap 1: Use a 'Get Next' step to iterate through lines until one contains…

Get Next advances through output records but returns the whole record, not a substring. Writing the entire line to a numeric field would fail validation or store non-numeric text. Iteration alone does not extract the digits; you still need a parsing step such as Parse Variable with a regex capture group after locating the line.

Trap 2: Use a 'Parse Table' step configured with the column header…

Parse Table expects delimited or column-aligned output such as CSV or fixed-width tables. The command output here is a label-value line, not a table with a header row and data rows, so Parse Table would produce empty or misaligned results. It is the wrong parser for extracting a single labeled scalar.

Trap 3: Use a 'Set Parameter' step with a static value of 'CPU(s):' and…

Set Parameter assigns a fixed or computed value to a pattern variable; it does not parse command output or accept a line index. It cannot extract the dynamic numeric value from the command's stdout, so the CI attribute would never receive the actual core count. This step type is for storing constants or concatenated strings, not for text extraction.

A
Use a 'Get Next' step to iterate through lines until one contains 'CPU(s):' and then write that entire line to the CI.
Why it fails: Get Next advances through output records but returns the whole record, not a substring. Writing the entire line to a numeric field would fail validation or store non-numeric text. Iteration alone does not extract the digits; you still need a parsing step such as Parse Variable with a regex capture group after locating the line.
B
Use a 'Parse Variable' step with a regular expression that captures the digits after 'CPU(s):'.
A Parse Variable step applies a regex to the prior command output, and the capture group isolates the numeric value regardless of surrounding text. This is the standard, robust approach when the value is embedded in a line with a stable label, and it avoids brittle line-position assumptions that break when output formatting changes across OS versions.
C
Use a 'Parse Table' step configured with the column header 'CPU(s):' and a single row.
Why it fails: Parse Table expects delimited or column-aligned output such as CSV or fixed-width tables. The command output here is a label-value line, not a table with a header row and data rows, so Parse Table would produce empty or misaligned results. It is the wrong parser for extracting a single labeled scalar.
D
Use a 'Set Parameter' step with a static value of 'CPU(s):' and reference the line index.
Why it fails: Set Parameter assigns a fixed or computed value to a pattern variable; it does not parse command output or accept a line index. It cannot extract the dynamic numeric value from the command's stdout, so the CI attribute would never receive the actual core count. This step type is for storing constants or concatenated strings, not for text extraction.

Question 5mediummultiple choice

A MID Server is configured with the IP range 10.0.0.0/24 in its MID Server IP range record. During a Discovery run, the MID Server attempts to scan a device with IP 10.0.1.5, which is outside that range. What is the outcome?

Trap 1: The MID Server will process the device only if it has the…

While the Discovery capability is required to perform discovery, it does not override the IP range restriction. The IP range is a separate access control mechanism. Even with Discovery capability, the MID Server will not scan devices outside its allowed IP range.

Trap 2: The MID Server will process the device but log a warning in the ECC…

The MID Server does not process devices outside its IP range, so no warning about processing is generated. The ECC queue is used for communication between the instance and MID Server, but it does not log such warnings for out-of-range devices. The device is simply skipped.

Trap 3: The MID Server will process the device if the device is in the same…

The MID Server IP range is explicitly configured and does not automatically include the MID Server's own subnet. The range defines the allowed scanning scope, and 10.0.1.5 is outside the configured /24 range, so it will not be scanned regardless of subnet relationships.

A
The MID Server will process the device only if it has the 'Discovery' capability enabled.
Why it fails: While the Discovery capability is required to perform discovery, it does not override the IP range restriction. The IP range is a separate access control mechanism. Even with Discovery capability, the MID Server will not scan devices outside its allowed IP range.
B
The MID Server will process the device but log a warning in the ECC queue.
Why it fails: The MID Server does not process devices outside its IP range, so no warning about processing is generated. The ECC queue is used for communication between the instance and MID Server, but it does not log such warnings for out-of-range devices. The device is simply skipped.
C
The MID Server will process the device if the device is in the same subnet as the MID Server.
Why it fails: The MID Server IP range is explicitly configured and does not automatically include the MID Server's own subnet. The range defines the allowed scanning scope, and 10.0.1.5 is outside the configured /24 range, so it will not be scanned regardless of subnet relationships.
D
The MID Server will not process the device because it is outside its configured IP range.
The MID Server IP range restricts which devices the MID Server is allowed to scan. If a device's IP falls outside the configured range, the MID Server will not process it, preventing unauthorized scanning. This ensures that Discovery is scoped to the intended network segments and avoids unnecessary traffic.