CIS-ITSM Change Management — 20 Questions

Question 1

A user attempts to create a Normal Change request, but notices that the Conflict Detection engine is not automatically running upon save. Which Business Rule or scheduled job typically triggers conflict detection asynchronously?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Run Conflict Detection on Insert/Update Business Rule. Conflict detection in Change Management is typically triggered asynchronously by a Business Rule named 'Run Conflict Detection on Insert/Update' (or similar). This business rule runs on the Change Request table and schedules the conflict detection job when a change is inserted or updated, ensuring that conflicts are identified without blocking the save operation.

Answer

Risk Assessment Scheduled Job

Answer

Change Management Scheduled Import

Answer

CAB Workbench Scheduled Job

Question 2

During a CAB meeting using the CAB Workbench, the Change Manager wants to add an ad-hoc change request to the agenda. How is this accomplished?

Accepted Answer

Using the 'Add Agenda Item' button within the CAB Workbench meeting interface. In the CAB Workbench, the Change Manager can add an ad-hoc change request to the current meeting agenda using the 'Add Agenda Item' button within the meeting interface. This action inserts the selected change request into the meeting's agenda (wm_task or related agenda records) without altering the base CAB definition's filter criteria. It allows real-time agenda adjustments during the CAB meeting.

Answer

By modifying the base CAB definition filter criteria

Answer

By changing the state of the change request to 'Assess'

Answer

By running a background script to insert records into wm_task

Question 3

An administrator is configuring a new Normal Change workflow and needs to ensure that tasks are generated based on change model configurations. Which ServiceNow table is the primary table for defining Change Models?

Accepted Answer

change_model. The change_model table is the primary table for defining Change Models in ServiceNow. Change Models allow administrators to define the workflow, tasks, and approvals for different types of changes. The change_model table stores the configuration for these models, including the associated workflow and task templates.

Answer

sys_ui_policy

Answer

task_sla

Answer

sn_chg_rest_model

Question 4

A change manager wants to automatically populate the Risk Assessment result on a Normal Change request based on user answers. Where is this automated risk calculation primarily configured?

Accepted Answer

Risk Conditions table (risk_conditions). The Risk Conditions table (risk_conditions) is where the automated risk calculation for changes is configured. It defines the conditions based on change attributes (including answers to risk assessment questions) that determine the risk level. When a change is created or updated, the system evaluates these conditions to set the risk assessment result.

Answer

Change Properties module

Answer

Data Policies

Answer

Workflow Designer

Question 5

An enterprise requires that conflict detection checks not only direct CI matches but also upstream and downstream dependent CIs. Which property or configuration enables this extended conflict checking behavior?

Accepted Answer

Enabling 'Check related CIs' in Change Properties. ServiceNow Change Management provides a property that enables conflict detection to check not only the directly affected CIs but also related CIs (upstream and downstream dependencies). Enabling 'Check related CIs' in Change Properties extends the conflict detection scope to include dependent CIs, which is exactly what the enterprise requires.

Answer

Setting the system property glide.ui.cmdb.cascade_deletes

Answer

Modifying the cmdb_ci_rel table dictionary

Answer

Configuring CI Class Manager inheritance rules

Question 6

Which role is typically required to authorize Standard Change proposals?

Accepted Answer

sn_chg_global_admin or change_manager. The Standard Change Catalog is managed and authorized by users with specific roles such as u_standard_change_catalog_admin or change_manager.

Answer

itil

Answer

sn_problem_read

Answer

sn_chg_coordinator

Question 7

An organization has multiple business units, each requiring its own separate CAB meeting with distinct membership and criteria. How should an administrator configure this in ServiceNow?

Accepted Answer

Create multiple records in the CAB Definition table with distinct filters and member lists. The CAB Definition [cab_definition] table allows administrators to create multiple CAB records, each with its own filter conditions (for example, on business unit or change category) and its own member list. When a change matches a CAB Definition's filter, that CAB is attached to the change and its members are used for approval. This is the native, supported way to run parallel CABs for different business units without custom code.

Answer

Use system properties to split the single global CAB meeting

Answer

Configure separate Workflows for each business unit's CAB approval

Answer

Modify the baseline CAB meeting definition to include dynamic group routing

Question 8

Which state does a Normal Change typically enter immediately after submission, prior to risk assessment and planning?

Accepted Answer

New. In ServiceNow Change Management, a Normal Change is created in the New state immediately after submission, before it moves to Assess (risk assessment) and then Authorize, Plan, and Implement. The New state represents the initial draft/registration phase prior to any evaluation or planning.

Answer

Review

Answer

Implementation

Answer

Closed

Question 9

An administrator wants to ensure that a change request cannot move to the 'Implement' state unless all associated change tasks are closed. Where is this validation typically enforced in modern ServiceNow ITSM instances?

Accepted Answer

Change Management State Model configuration. In modern ServiceNow ITSM, the Change Management State Model configuration is the central place where state transitions and their associated validation rules are defined. This configuration allows administrators to specify conditions that must be met before a change request can move to a particular state, such as 'Implement'. By setting a condition that all associated change tasks must be closed, the system enforces this requirement automatically. This approach is declarative and aligns with ServiceNow best practices for state management.

Answer

Service Catalog client scripts

Answer

Network firewall settings

Answer

System dictionary attributes only

Question 10

An administrator needs to disable automatic conflict detection for a specific integration account that bulk-imports changes. What is the recommended way to prevent conflict detection from running during this specific import?

Accepted Answer

Deactivating the business rule that triggers conflict detection and checking session or import set context. The recommended way to prevent conflict detection during a specific bulk import is to deactivate the business rule that triggers conflict detection and ensure the import runs in a session or import set context that bypasses it. This is the correct answer because it directly addresses the mechanism (business rule) and the context (session/import set) that controls execution.

Answer

Modifying the CMDB sync engine properties

Answer

Changing the integration user's role to 'itil'

Answer

Deleting the ConflictFinderSNC script include

Question 11

An administrator needs to configure conflict detection to ignore overlapping changes if they belong to the same parent project. How can this exclusion be implemented?

Accepted Answer

Modifying the ConflictFinderSNC script include to filter out changes with matching parent projects. Conflict detection in ServiceNow is driven by the ConflictFinderSNC script include, so excluding changes that share a parent project requires modifying that script include to filter out changes with matching parent project values. There is no out-of-box 'Ignore Project Conflicts' property, and conflict detection cannot be selectively disabled per CI or via a Data Policy. The correct approach is a script-level customization that adds the parent project comparison to the conflict query.

Answer

Checking 'Ignore Project Conflicts' in Change Properties

Answer

Disabling conflict detection for all project-related CIs

Answer

Setting a Data Policy on the Project table

Question 12

When a change request moves to the 'Review' state, what is the primary objective of this phase?

Accepted Answer

Conducting a Post Implementation Review (PIR) to verify success and capture lessons learned. In ServiceNow Change Management, the Review state is the post-implementation phase where the change is evaluated for success, the Post Implementation Review (PIR) is conducted, and lessons learned are captured before the change is closed. This is distinct from planning and approval activities that occur earlier in the lifecycle.

Answer

Assigning implementation tasks to resolver groups

Answer

Performing initial conflict detection

Answer

Running automated risk assessments

Question 13

An administrator needs to review how conflict detection evaluates maintenance windows. Which script include contains the core logic for conflict detection in ServiceNow?

Accepted Answer

ConflictFinderSNC. ConflictFinderSNC is the script include that contains the core logic for conflict detection in ServiceNow Change Management. It evaluates schedule overlaps, blackout schedules, maintenance windows, and other conflict types against a change request's planned window and target CIs. Administrators and developers reference this script include when troubleshooting or extending conflict detection behavior.

Answer

CABWorkbenchSNC

Answer

RiskAssessmentSNC

Answer

ChangeManagementUtils

Question 14

During a CAB meeting, a change request is rejected by the board. What happens to the change request state in an out-of-the-box configuration?

Accepted Answer

It moves to Canceled or Closed - Rejected. In ServiceNow's out-of-the-box Change Management configuration, when the CAB rejects a change request during the Authorize state, the change transitions to 'Closed' with a state value of 'Closed - Rejected' (or 'Canceled' depending on the rejection path). The change does not return to New or convert to another type; it is terminated with a rejection outcome recorded for audit.

Answer

It automatically reverts to the 'New' state for resubmission

Answer

It converts into an emergency change request

Answer

It remains in the Authorize state indefinitely

Question 15

What is the primary purpose of the 'Conflict' related list on a Change Request form?

Accepted Answer

To display any schedule overlaps or blackout conflicts detected for the change. The Conflict related list on a Change Request displays schedule overlaps or blackout conflicts detected for the change — for example, two changes touching the same CI in the same maintenance window, or a change scheduled during a defined blackout period. It is populated by the conflict detection engine (ConflictFinderSNC) and helps change managers reschedule or coordinate before approval. It is specifically about scheduling and CI overlap, not CMDB relationships or user roles.

Answer

To display conflicting CMDB relationships

Answer

To show conflicting incident tickets assigned to the same user

Answer

To list conflicting user security roles

Question 16

A change practitioner is scheduling a change and needs to verify if any 'Blackout Schedules' apply. Where are Blackout Schedules created and managed in ServiceNow?

Accepted Answer

Schedules module (cmn_schedule table). Blackout Schedules in ServiceNow are built on the platform's core scheduling engine, which stores all schedule records in the cmn_schedule table. They are created and managed through the Schedules module (System Scheduler > Schedules), where a schedule can be flagged as a blackout schedule by setting the 'Type' field to 'Blackout'. Change Management then references these schedules via the 'Blackout' related list on the Change Schedule, and the Change Management blackout logic checks against the cmn_schedule records.

Answer

Data Policies table

Answer

CI Class Manager

Answer

Change Properties > Blackout tab

Question 17

An administrator is configuring conflict detection to include upstream dependent CIs. If CI A depends on CI B, and a change is scheduled on CI B, how does conflict detection evaluate CI A?

Accepted Answer

It flags a conflict on CI A because of its relationship to the changing CI B. When conflict detection is configured to include upstream dependent CIs, it evaluates the relationships between CIs. If CI A depends on CI B (i.e., CI A is upstream and depends on CI B), and a change is scheduled on CI B, the conflict detection will flag a conflict on CI A because CI A is dependent on CI B and may be affected by the change. This is because changes to a downstream CI can impact upstream CIs that rely on it.

Answer

It rejects the change automatically without generating a conflict record

Answer

It ignores CI A unless CI A is also explicitly selected in the change request

Answer

It automatically creates an incident for CI A

Question 18

An administrator needs to write a custom script to evaluate change conflicts programmatically. Which script include method is commonly called to execute conflict checks for a given change sys_id?

Accepted Answer

ConflictFinderSNC().hasConflict() or equivalent engine methods. ServiceNow exposes conflict-checking logic through scriptable engine classes such as ConflictFinderSNC (or equivalent conflict engine methods) that accept a change sys_id and return conflict results, which is what a custom script would call to evaluate conflicts programmatically. These engine methods encapsulate the same logic the UI uses for conflict detection.

Answer

ChangeEngine().runConflicts()

Answer

CABWorkbench().getConflicts()

Answer

RiskCalculator().calculate()

Question 19

Which TWO change types are recognized out-of-the-box in ServiceNow Change Management? (Choose two.)

Accepted Answer

Normal Change. Option B, Normal Change, is correct because ServiceNow Change Management ships with three OOB change models: Normal, Standard, and Emergency, and Normal is the default type used for changes that require full assessment, approval, and scheduling through the change lifecycle. Option C, Emergency Change, is also correct because it is one of the three baseline change types, designed for urgent changes that must be implemented immediately, often with expedited or post-implementation approval via the CAB. The unmarked options do not belong: Temporary Change (A) is not an OOB change type but rather a change attribute/field indicating a change will be rolled back, Routine Change (D) is not a baseline type (Standard Change is the OOB type for pre-approved, low-risk, repeatable changes), and Scheduled Change (E) is not a change type but describes a change state/scheduling condition.

Answer

Temporary Change

Answer

Routine Change

Answer

Scheduled Change

Question 20

Which TWO mechanisms are used in ServiceNow to automate risk assessment scoring for a Normal Change? (Choose two.)

Accepted Answer

Risk Conditions (risk_conditions table) that map assessment scores to risk values. Option A is correct because the Risk Conditions mechanism (stored in the risk_conditions table) defines the rules that map assessment scores or change attributes to a calculated risk value, which is exactly how ServiceNow automates risk scoring for a Normal Change. Option B is correct because assessment metric categories and their associated questionnaires, completed during the assess phase of the change lifecycle, generate the underlying scores that feed into the risk calculation. Option C is incorrect because incident priority matrices apply to incident management (impact/urgency to priority) and have no role in change risk scoring. Option D is incorrect because Service Catalog workflow variables drive catalog item fulfillment, not change risk assessment. Option E is incorrect because automated email replies are notifications and do not perform any risk scoring computation.

Answer

Incident priority matrices

Answer

Service Catalog workflow variables

Answer

Automated email replies sent to the service desk