CCNA Change Management Questions

Soft conflicts flag overlapping changes as advisory warnings, letting the coordinator proceed, while hard conflicts enforce a stop by blocking the change workflow. This distinction matches the stem's scenario where the coordinator observes a soft conflict and needs to understand its non-blocking behaviour.

CAB Definitions (wm_definition) store the meeting configuration records that the CAB Workbench uses to generate and manage meetings. Defining them is a prerequisite component, satisfying the stem's requirement for configurations involved in setting up CAB meetings.

The planned end date marks when a change releases its affected configuration items, so overlapping end times with another change reveal a scheduling conflict. It satisfies the stem's requirement for a field used to detect conflicts.

The Change Schedule calendar workspace renders planned changes, maintenance windows and blackouts on a shared timeline, so a change manager can visually spot overlapping entries. This directly satisfies the stem's requirement for a graphical representation to identify potential scheduling conflicts, rather than relying on lists or reports.

The Change Model Flow defines the states and the transitions between them, including any conditions or automation governing movement from 'New' to 'Assess'. Configuring the transition logic there ensures the state change triggers automatically rather than requiring manual intervention.

Publishing the proposal promotes the approved change proposal into the Standard Change Catalog, satisfying the requirement that the template becomes selectable for future standard changes. Without this publication step, the proposal remains a draft and never appears in the catalog, so the template cannot be used.

Agenda management lists the change requests queued for review during a CAB Workbench meeting, giving the meeting its structured order of business. This is a core component of the meeting structure the stem asks about.

Votes cast in the CAB Workbench are persisted in the wm_decision table, which records each attendee's decision against the change request, with related CAB meeting tables holding the agenda and attendee context. This satisfies the stem's requirement for the exact database location where CAB Workbench votes are stored.

A before business rule on the Change Request table can query related Change Tasks and abort the state transition to Review if any remain open. This enforces the gate at the data layer regardless of how the transition is triggered, including list edits and workflow. It is the correct server-side control for preventing the transition until all tasks are closed complete.

The CAB Definition drives agenda creation: the workbench reads its configuration and automatically generates the meeting agenda from the changes and items it specifies. No manual agenda assembly is required, satisfying the stem's question about how the agenda is produced.

A Business Rule runs server-side on every record write, including those triggered by a Mass Update, so it can recalculate the risk assessment fields for each affected Change Request. This satisfies the stem's requirement that every record's assessment is refreshed, not just the first.

A Standard Change proposal begins in Draft or Submitted state, before any approval workflow runs. It only advances to Assessed or Approved once the change authority reviews it, so this initial state precedes authorisation and scheduling.

Change Models decouple change types from a single rigid workflow, letting each type define its own states, approvals, and rules. This satisfies the need to tailor process behaviour per change type rather than forcing one flow across all changes.

Change Models let you attach approval definitions that override the standard CAB flow for a specific change type, so emergency changes route to the Incident Commander group instead. This satisfies the bypass-without-custom-code constraint, since the model's approval definition is declarative configuration rather than a business rule.

Business rules and state validation on the change_task table enforce conditional logic, blocking closure of Implementation tasks unless the parent change request sits in the Implement state. This server-side validation guarantees the dependency regardless of client-side UI behaviour.

The Review state confirms the change achieved its intended outcome and captures lessons learned for future improvements. Verifying success and documenting findings closes the change record, distinguishing Review from the authorisation and implementation stages of the normal change lifecycle.

Change Models define the workflow, approval steps and required tasks for a change type, so an emergency model can omit multi-tier CAB approval while mandating a post-implementation review task. This natively satisfies the bypass-and-review requirement without custom scripting.

During the Authorize state, the Change Advisory Board or delegated Change Authority reviews risk and schedule impact, then grants final approval for Normal changes. This body holds the authorisation mandate that the Change Manager alone does not, satisfying the stem's requirement for the entity giving final approval.

An Emergency change request documents the urgent issue and remediation plan, satisfying the stem's requirement by creating the formal record before implementation. This enables retrospective review and provides the audit trail that emergency changes still demand despite compressed approval timelines.

CAB Workbench is the out-of-the-box ServiceNow tool that directly satisfies the requirement to manage and conduct Change Advisory Board meetings. It provides a dedicated agenda view, meeting scheduling, attendee management and change record review, letting CAB members assess and approve changes within a single interface rather than through standard change lists.

Approval Definitions are reusable records that specify who must approve, and they attach to change categories or models. The authorisation engine consults the definition linked to the change's category or model to determine the required approvers, satisfying the stem's authorisation-rule requirement.

The std_change_proposal table holds draft Standard Change proposals, including their template, category and approval state, until they are approved and published to the std_change_record table. It is therefore the staging table the question asks for.

The Configuration item field records which specific CI the change modifies, linking the request to the affected asset. This directly answers what identifies the configuration item being modified, distinguishing it from fields such as description or category.

The sn_change_cab.cab_manager role grants access to the CAB Workbench module, which is scoped to the Change Management CAB application. Without it, the technician cannot see the module, satisfying the stem's requirement for the specific role needed.

The Configuration item field explicitly records the CI that the change primarily affects, linking the change record to the affected asset in the CMDB. This satisfies the stem's requirement for designating the primary configuration item, unlike fields such as Assignment group or Short description.

Emergency Changes exist to restore service or avert imminent harm when normal change control timescales cannot be met, so this option satisfies the stem's "urgent disruption" constraint. The Emergency Change Advisory Board reviews such changes retrospectively, prioritising speed of remediation over full pre-approval, which is precisely the immediate-remediation purpose described.

Ticking 'CAB Required' forces the change through the CAB approval process, ensuring the Change Advisory Board must review and approve before the change can proceed. This satisfies the stem's requirement by mandating CAB approval rather than leaving it optional.

The Risk field captures the evaluated potential danger or impact of failure for the change, informing approval routing and CAB review. It satisfies the need to quantify exposure, distinguishing high-risk changes requiring stricter scrutiny from routine low-risk ones.

Standard Change templates act as blueprints only at creation time; the resulting change records copy the template's values and are then independent. Updating the template therefore cannot retroactively alter active changes, which retain the field values captured when each was created.

The 'Run Conflict' UI action on the change request form lets users trigger conflict detection on demand, satisfying the manual initiation method. It complements automatic detection by scanning the change against schedules and CI relationships when clicked.

Standard changes are pre-authorised, low-risk and routine, so they follow a documented procedure without individual CAB review. Their high frequency makes per-change approval impractical, and the pre-authorisation satisfies the low-risk, repeatable nature described in the stem.

Schedule Overlap detection compares the change's Planned start date and Planned end date against the same fields on other change records. Any intersection of those intervals flags a conflict, so these two fields define the window ServiceNow evaluates.

A High risk value triggers the workflow's risk-based routing, inserting a mandatory CAB approval gate before the change can be authorised. This satisfies the stem's requirement that high-risk Normal Changes receive additional scrutiny rather than standard approval.

Emergency Changes are designed for urgent situations where implementation cannot wait for a scheduled CAB meeting. They use an expedited approval path, often involving the Emergency Change Advisory Board or a designated approver, and are reviewed after implementation. This matches the agent's need to restore email service immediately while still capturing the change for post-implementation review.

Risk Conditions evaluate change attributes, including affected business service, and assign a calculated risk score when matched. Configuring one against the mission-critical service satisfies the stem's requirement, automatically scoring any change affecting it as High.

The conflict engine traverses the CMDB relationship graph, specifically the cmdb_rel_ci table, walking upstream and downstream dependencies from each affected CI. Because both CIs resolve to the same parent business service through those relationship records, the engine detects the shared dependency and flags the overlap, satisfying the stem's cross-CI conflict requirement.

Maintenance schedules define permitted change windows, whereas blackout schedules block changes during critical periods such as financial close or peak trading. This directly satisfies the stem's requirement to distinguish the two: one authorises approved execution windows, the other prohibits activity, ensuring changes avoid high-risk intervals.

The conflict engine compares each change's affected CIs and planned start/end times, flagging records where the same CI appears in two changes whose windows overlap. This directly satisfies the stem's requirement for automatic CI-and-time conflict detection.

The ITIL role encompasses managing the change lifecycle, assessing risk and authorising changes, while participating practitioners raise and implement change records. This satisfies the stem's requirement for roles that both manage and participate in Change Management processes within the CIS-ITSM framework.

Maintenance schedules define windows when changes are allowed to proceed, so work outside them is effectively blocked during critical business hours. This satisfies the stem's requirement to prevent changes by restricting execution to approved maintenance periods.

Attaching the detailed rollback procedure provides the full step-by-step documentation that may be too long for the Backout plan field. Attachments are visible to approvers and implementers and are retained with the change record for audit. This complements the Backout plan field and ensures the rollback guidance is available during implementation.

The CAB Workbench provides a dedicated interface for scheduling, running, and recording Change Advisory Board meetings, including agendas, attendees, and decisions. It centralises governance of change requests, directly fulfilling the stem's requirement to manage, track, and conduct CAB meetings efficiently.

CI relationship type definitions in cmdb_rel_type carry the parent/child and upstream/downstream semantics that conflict detection traverses, so custom types must be defined there before evaluation occurs. Without these directional definitions, the engine cannot resolve how custom relationships connect CIs, leaving them unevaluated during conflict detection.

The Standard Change Catalog presents pre-approved templates for low-risk, repeatable changes, letting users raise a change request without full assessment or CAB review. This directly satisfies the stem's requirement for quick creation from available templates, as standard changes carry pre-authorised approval by definition.

Standard Changes are pre-approved, low-risk, well-understood changes with a documented procedure, so they bypass the full change advisory board review. Low risk is a defining characteristic, distinguishing them from Normal Changes requiring assessment and authorisation.

A Blackout Schedule defines windows in which changes are barred for a given CI or service, so this conflict flags that the planned change falls inside a prohibited period. Conflict detection surfaces it because the schedule constraint is violated, requiring rescheduling or an approved exemption before the change can proceed.

Change Authorities define who may approve each change type, and Approval Definitions map those authorities to specific approval records. Configuring both restricts Emergency Change approval to nominated individuals, satisfying the requirement to control who can approve them.

Planned end date marks when the change window closes, bounding the execution period alongside its start. Together with planned start date, it defines the interval during which the change may be implemented, satisfying the requirement to specify the change request's execution window.

The Change Calendar renders scheduled changes in a calendar view, letting the practitioner see everything falling inside a specific maintenance window. It draws directly on change schedule records, so no manual filtering or reporting workaround is needed to visualise that window.

Risk Assessment Conditions let you define question-and-answer thresholds that force the risk rating to High when matched, overriding the calculated score. This satisfies the stem's requirement for specific answers to escalate risk instantly, regardless of other questionnaire scoring.

Agenda column settings live on the CAB Definition record, under CAB Workbench settings, where the Change Manager defines which fields appear in the agenda view. This satisfies the stem's constraint: customising displayed columns for the CAB Workbench agenda specifically, rather than global list layouts or personal user preferences.

Blackout windows are native Change Management records that block change scheduling in defined periods. By attaching a recurring monthly schedule to the blackout window, the Change Manager enforces the freeze automatically for the last two business days, and conflict detection flags any change that violates it. This is exactly the intended use of blackout windows on the Change schedule.

The Change Schedule provides a consolidated calendar view of all planned changes across the infrastructure, satisfying the requirement to see every scheduled change in one place. Unlike individual change records or the CAB workbench, it aggregates approved and upcoming changes by planned start and end dates, giving users the complete forward-looking picture.

The change_task table stores the individual task records that decompose a change request, including Implementation and Post-Implementation Testing tasks. Each row references its parent change request, so querying change_task returns exactly the associated tasks the stem describes.

Standard Change templates deliver repeatable, pre-approved execution for low-risk changes, eliminating the need for individual Change Advisory Board review each time. This directly satisfies the stem's requirement for a primary purpose: streamlining routine changes through a defined, authorised procedure that maintains control whilst reducing administrative overhead and approval delays.

Standard Change is a pre-approved Change Model for low-risk, routine changes, so it bypasses the full approval workflow. This matches the requirement for minimal approval on a frequent change, unlike Normal Change, which requires assessment and authorisation.

Conflict detection evaluates change requests against defined schedules, so cmn_schedule records must be referenceable by that engine. Linking a blackout schedule to conflict detection lets the system flag or block changes falling inside prohibited windows, which is precisely the enforcement behaviour the scenario requires.

Conflict detection only fires when the update touches the schedule-related fields the rule inspects, so REST API changes altering other fields bypass it. This condition directly explains why detection does not run during those API calls.

Rescheduling the change to a non-overlapping window directly resolves the conflict. This preserves the change record and its details while ensuring the maintenance activities do not collide with other changes on the same CI. It is the most straightforward and policy-compliant resolution.

Emergency changes address unplanned outages or severe incidents and follow an expedited approval path rather than the standard change model. ServiceNow recognises emergency as a distinct change type alongside normal and standard, satisfying the question's requirement for a common change category.

A business rule can enforce that the change cannot be closed until the associated post-implementation review task is complete. This ensures the review is not skipped. By applying it to high-risk changes, the manager meets the requirement for future changes.

Custom change states must be defined on Change State Model records together with state transition rules, because that framework governs which states exist and the permitted transitions between them. Defining states elsewhere leaves the model unaware of them, breaking lifecycle enforcement.

Assessment trigger rules fire automatically when a Normal Change enters the 'Assess' state, dispatching the risk questionnaire to the assignee without custom scripting. Configured against the assessment metric type, they satisfy the stem's out-of-the-box requirement for state-driven, assignee-targeted assessment delivery.

Defining CAB Members populates the roster from which attendees are drawn, so only the appropriate stakeholders receive meeting invitations. Without this list, the CAB Definition cannot determine who should attend, directly satisfying the stem's requirement to invite the right people.

Filter conditions on the CAB definition record drive the agenda query, so only changes matching the High-risk criterion are pulled in automatically. This satisfies the stem's requirement for automatic inclusion without manual triage, since the filter is evaluated each time the meeting agenda is generated.

The close code records the Post Implementation Review outcome, distinguishing successful, successful with issues, and unsuccessful. It is the field that captures the review verdict, satisfying the stem's requirement for indicating change success after implementation.

The CAB Workbench is accessed through the Change application menu, which groups change management tooling including the CAB Workbench module. This satisfies the stem's requirement for the application menu providing access, as the Workbench sits under Change rather than Incident, Problem or Service Catalog.

Approvals on a Change model can be made conditional by using a condition builder that evaluates fields like Production. This ensures the Database CAB approval is generated only when the change affects production, satisfying the requirement without impacting non-production changes.

The Approval History related list records each approval decision with timestamps and approver identity, while the Activity Stream captures state transitions and field changes. Together they provide the complete audit trail the change manager needs.

Assessment Designer (survey_designer) is the module for building assessments with conditional branching, letting administrators define question-level logic that routes based on prior answers. It satisfies the requirement for custom branching logic in the Risk Assessment questionnaire.

Duration defines how long the CAB meeting is scheduled to run, setting the session's planned length in the meeting definition. It does not control attendee lists, agenda items or approval thresholds, so it directly satisfies the stem's requirement to specify the meeting's scheduled time span.

Planned start and end dates define when each change executes, so overlapping schedules are detected as conflicts. This satisfies the detection criterion by comparing time ranges, catching changes that would run concurrently on shared resources.

The Change Conflict Definition [change_conflict_definition] table stores the criteria records that Conflict Detection evaluates to determine whether changes overlap. Configuring entries there defines which change fields and conditions trigger a conflict warning, preventing overlapping outages.

Conflict detection relies on active properties and business rules to compare change schedules; if these are disabled, overlaps pass unflagged. Verifying they are enabled directly satisfies the stem's requirement to investigate why detection failed, since inactive configuration is a primary cause of missed conflicts in the change management workflow.

Standard changes are routine and repeatable with a known track record.